Time to First Byte (TTFB)

תמיכה בדפדפן

  • 43
  • 12
  • 31
  • 11

מקור

מה זה TTFB?

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

תצוגה חזותית של תזמוני בקשות ברשת. התזמונים משמאל לימין הם הפניה אוטומטית, Service Worker Init, אירוע שליפה של Service Worker, מטמון HTTP, DNS, TCP, בקשה, רמזים מוקדמים (103), תגובה (שחופפת עם Prompt for Unload), עיבוד וטעינה. התזמונים המשויכים הם referralStart ו-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 הסופית נבדקת בדרך כלל ולרוב מבטלים שוב ושוב את השינויים שנשמרו במטמון. כדי להבהיר את המידע הזה, ייתכן שכלי Lab אחרים לא יוכלו להבין מה זה מידע, אבל בעזרת נתונים של Lighthouse ידווח זמן התגובה של השרת.

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

מדד ה-TTDFB קודם למדדים שמתמקדים במשתמשים כמו הצגת התוכן הראשון (FCP) והמהירות שבה נטען רכיב התוכן הכי גדול (LCP), ולכן מומלץ שהשרת יגיב לבקשות ניווט מהר מספיק כדי שהאחוזון ה-75 של המשתמשים יבחין ב-FCP בטווח של סף 'טוב'. ככלל, רוב האתרים צריכים לשאוף לכך שערך ה-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).