Time to First Byte (TTFB)

Jeremy Wagner
Barry Pollard

תמיכה בדפדפן

  • Chrome: 43.
  • קצה: 12.
  • Firefox: 35.
  • Safari: 11.

מקור

מה זה TTFB?

TTFB הוא מדד שמודד את הזמן שחולף מהבקשה למשאב ועד שהבייט הראשון של תשובה מתחיל להגיע.

תצוגה חזותית של תזמוני בקשות ברשת. התזמונים משמאל לימין הם הפניה אוטומטית, Service Worker Init, אירוע שליפה של Service Worker, מטמון HTTP, DNS, TCP, בקשה, רמזים מוקדמים (103), תגובה (שחופפת עם Prompt for Unload), עיבוד וטעינה. התזמונים המשויכים הםredirectStart ו-RedirectEnd, pullStart, domainLookupStart, domainLookupEnd, connectStart, SecureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domLoadedEventStart, ו- loadEventEnd.
תרשים של שלבי בקשת רשת והתזמונים המשויכים להם. TTFB מודד את הזמן שחלף בין startTime לבין responseStart.

TicketFB הוא הסכום של שלבי הבקשה הבאים:

  • זמן ההפניה לכתובת URL אחרת
  • זמן ההפעלה של Service Worker (אם רלוונטי)
  • חיפוש DNS
  • משא ומתן של חיבור ו-TLS
  • בקשה, עד לנקודה שבה הגיע הבייט הראשון של התשובה

קיצור זמן האחזור בזמן הגדרת החיבור ובקצה העורפי עלול לקצר את זמן האחזור.

הגדרות אחרות של TTFB

ההגדרה הקודמת היא ההגדרה הקונבנציונלית, אך בשילוב עם רמזים מוקדמים, מה שנחשב ל'בייט ראשון'. נתון לדיון. firstInterimResponseStart היא רשומת תזמון חדשה נוספת ל-responseStart כדי להבחין ביניהם, אבל היא נתמכת רק ב-Chrome ובדפדפנים המבוססים על Chromium. לכן, חלק מהדפדפנים והכלים (כולל CrUX) מודדים עד לקבלת הבייטים הראשונים, כולל רמזים מוקדמים.

רמזים מוקדמים הם רק דוגמה חדשה לתגובה בשלב מוקדם. שרתים מסוימים מאפשרים שטיפה של תגובת המסמך תתבצע לפני שהגוף הראשי זמין – באמצעות כותרות ה-HTTP בלבד או באמצעות הרכיב <head>. אפשר להתייחס לשניהם באופן דומה לפעולה של רמזים מוקדמים, ולכן הם גם בענן את ההגדרה של מה שמודדים מה-TTDFB.

כמדד למקרים שבהם 'הבייטים הראשונים' של מידע פרקטי לגבי המסמך יתקבלו בדפדפן, כל ההגדרות האלה יכולות להיחשב כחוקיות. יש ערך ממשי בשליחת נתונים בחזרה מוקדם יותר, אם נדרש זמן רב יותר לתגובה המלאה. הדבר החשוב ביותר הוא להבין איזה מדידות הכלי שבו אתם משתמשים מודדים ואיך הוא מושפע מהפלטפורמה שנמדדת. לכן קשה להשוות בין 'דברים שאפשר לעשות' (TTDFB) בפלטפורמות או בטכנולוגיות שונות, בהתאם לתכונות שבהן הם משתמשים, ולאופן ההשפעה של המדד הזה על מדידת ה-TTDFB שנעשה בו שימוש.

בדרך כלל, המידע הזה מוצג גם כאינדיקטור של זמן התגובה של השרת או המארח. עם זאת, הוא יושפע מגורמים מחוץ לשליטה הישירה הזו, כמו זמן ההפניה האוטומטית, אם הוא מוצג מהמטמון שהתקבל על ידי CDN או אם התהליך ארוך יותר בחזרה לשרת המקור. זה ניכר במיוחד בנתוני שטח – בדיקות מעבדה בדרך כלל מושפעות פחות מהגורמים האלה, כי כתובת ה-URL הסופית נבדקת בדרך כלל ולרוב מבטלים שוב ושוב את השינויים שנשמרו במטמון. כדי להבין טוב יותר את המידע הזה, ב-Lighthouse מדווחים על זמן התגובה של השרת ולא על זמן התגובה של שרת (TTFB), אבל יכול להיות שכלי Lab אחרים לא.

מהו ציון טוב של TTFB?

מדד ה-TTDFB קודם למדדים שמתמקדים במשתמשים כמו הצגת התוכן הראשוני (FCP) ו-LCP . ככלל, רוב האתרים צריכים לשאוף לכך שערך ה-TTDFB יהיה 0.8 שניות או פחות.

ערכים טובים של TTFB הם 0.8 שניות או פחות, ערכים נמוכים הם גדולים מ-1.8 שניות וכל מה שביניהם צריך לשפר
ערכים טובים של TTFB הם 0.8 שניות לכל היותר, וערכים נמוכים הם גדולים מ-1.8 שניות.

איך מודדים את טופס ה-TTDFB

אפשר למדוד את אובייקט ה-TTDFB בשיעור ה-Lab או בשדה בדרכים הבאות.

כלים לשטח

כלים לשיעור Lab

מדידת TTFB ב-JavaScript

אפשר למדוד את ה-TTDFB של בקשות ניווט בדפדפן באמצעות Navigation Timing API. בדוגמה הבאה אפשר לראות איך ליצור PerformanceObserver שמאזינים לרשומה של navigation ומרשום אותה למסוף:

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

גם בספריית ה-JavaScript של web-vitals אפשר למדוד את מדד ה-TTFB בדפדפן בצורה פשוטה יותר:

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

מדידה של בקשות למשאבים

טבלת ה-TTDFB חלה על כל הבקשות, לא רק על בקשות ניווט. באופן ספציפי, משאבים שמתארחים בשרתים ממקורות שונים יכולים להאריך את זמן האחזור בגלל הצורך להגדיר חיבורים לשרתים האלה. כדי למדוד את מדד ה-TTDFB של משאבים בשדה, צריך להשתמש ב-Resource Timing API בתוך PerformanceObserver:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

קטע הקוד הקודם דומה לקטע הקוד ששימש למדידת ה-TTDFB של בקשת ניווט, אבל במקום לשלוח שאילתה על רשומות 'navigation', נשלחת שאילתה לרשומות 'resource'. הוא גם מביא בחשבון את העובדה שחלק מהמשאבים שנטענים מהמקור הראשי עשויים להחזיר את הערך 0, כי החיבור כבר פתוח או שמשאב מאוחזר מהמטמון באופן מיידי.

איך לשפר את טופס ה-TTDFB

לקבלת הדרכה לשיפור השדה 'דברים שאפשר לעשות' (TTFB) באתר, אפשר לעיין במדריך המעמיק שלנו לאופטימיזציה של חשבון 'דברים שאפשר לעשות' (TTDFB).