אופטימיזציה של הזמן עד לבייט הראשון

כאן מוסבר איך לבצע אופטימיזציה למדד המהירות שבה מגיע בייט התגובה הראשון (TTFB).

Barry Pollard

Jeremy Wagner

פורסם: 19 בינואר 2023, עדכון אחרון: 28 בנובמבר 2025

הזמן עד לקבלת הבייט הראשון (TTFB) הוא מדד בסיסי לביצועי אתרים, שקודם לכל מדד משמעותי אחר של חוויית משתמש, כמו הצגת תוכן ראשוני (FCP) והמהירות שבה נטען רכיב התוכן הכי גדול (LCP). כלומר, ערכי TTFB גבוהים מוסיפים זמן למדדים שמופיעים אחריו.

מומלץ שהשרת יגיב לבקשות ניווט מספיק מהר כדי שהאחוזון ה-75 של המשתמשים יחוו FCP בתוך סף ה'טוב'. ככלל, רוב האתרים צריכים לשאוף ל-TTFB של 0.8 שניות או פחות.

איך מודדים את TTFB

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

אחת הדרכים לקבל מידע מהשטח וממעבדה לגבי אתרים ציבוריים שזמינים בדוח לגבי חוויית המשתמש ב-Chrome היא באמצעות PageSpeed Insights.

הזמן עד הבייט הראשון (TTFB) של משתמשים בפועל מוצג בקטע העליון רוצה נתונים על החוויה של המשתמשים באתר בפועל?:

בנתוני המעבדה, בעיות שקשורות ל-TTFB מוצגות בתובנה זמן האחזור של בקשת מסמך:

כדי לקבל מידע נוסף על דרכים למדידת TTFB בשטח ובמעבדה, אפשר לעיין בדף המדד TTFB.

הסבר על ההבדלים בין TTFB בשטח לבין TTFB במעבדה

יכולים להיות הבדלים בין נתוני TTFB במעבדה לבין נתוני TTFB בשטח, ומסיבות שונות. כשמזהים הבדלים כאלה, חשוב להבין למה הם קורים כדי להשתמש ביעילות בנתוני המעבדה לשיפור חוויית המשתמש.

• אם ערך ה-TTFB במעבדה גבוה בהרבה מערך ה-TTFB בשטח, זה מצביע על כך שסביבת המעבדה מוגבלת יותר מהסביבות שבהן חווים המשתמשים את האתר בדרך כלל. זו לא בהכרח בעיה, כי התוצאות וההמלצות של המעבדה עדיין תקפות, אבל יכול להיות שהן יגזימו בהשפעה ובשיפור.

• אם ערך ה-TTFB בשדה גבוה בהרבה מערך ה-TTFB במעבדה, זה מצביע על בעיות שלא ברורות מהרצת המעבדה, כמו שימוש במטמון בצד השרת, הפניות או הבדלים ברשת. במקרה כזה, יכול להיות שהתוצאות וההמלצות של ה-Lab יהיו פחות שימושיות, כי הן לא יתייחסו לאחת מהבעיות העיקריות.

  כדי לבדוק אם שמירת נתונים במטמון בצד השרת משפיעה על TTFB במעבדה, נסו לבדוק דפים פחות נפוצים או להשתמש בפרמטרים שונים של כתובות URL כדי לקבל תוכן שלא נשמר במטמון. כך תוכלו לראות אם ה-TTFB תואם יותר ל-TTFB בשטח. יכול להיות שיהיה לכם שימושי גם לעקוף את השמירה במטמון בצד השרת באמצעות פרמטר מסוים של כתובת URL. אפשר לעיין בקטע בנושא תוכן שנשמר במטמון.

  במקרה של הפניות אוטומטיות והבדלים ברשת, ניתוח של התנועה שמגיעה לאתר שלנו ושל המקורות שלה יכול לעזור באבחון אם אלה בעיות פוטנציאליות.

ניפוי באגים של TTFB גבוה בשטח באמצעות Server-Timing

אפשר להשתמש בכותרת התגובה Server-Timing בקצה העורפי של האפליקציה כדי למדוד תהליכים שונים בקצה העורפי שיכולים לתרום לזמן אחזור גבוה. המבנה של ערך הכותרת גמיש, והוא מקבל לפחות את הכינוי שאתם מגדירים. ערכים אופציונליים כוללים ערך משך (באמצעות dur), וגם תיאור אופציונלי שקריא לאנשים (באמצעות desc).

אפשר להשתמש ב-Serving-Timing כדי למדוד הרבה תהליכים בעורף האפליקציה, אבל יש כמה תהליכים שכדאי לשים לב אליהם במיוחד:

• שאילתות של מסד נתונים
• זמן הרינדור בצד השרת, אם רלוונטי
• חיפושים בדיסק
• פגיעות במטמון של שרת קצה או החמצות (אם משתמשים ב-CDN)

כל החלקים של רשומה Server-Timing מופרדים באמצעות נקודתיים, ואפשר להפריד בין כמה רשומות באמצעות פסיק:

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

אפשר להגדיר את הכותרת באמצעות השפה הרצויה של העורף של האפליקציה. לדוגמה, ב-PHP אפשר להגדיר את הכותרת כך:

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

כשמגדירים את הכותרת הזו, המידע שמופיע בה יכול לשמש אתכם גם במעבדה וגם בשטח.

בשדה הזה, כל דף עם כותרת תגובה Server-Timing מוגדר מאכלס את המאפיין serverTiming ב-Navigation Timing API:

// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
  // Log the server timing data:
  console.log(entry.name, entry.description, entry.duration);
});

במעבדה, נתונים מכותרת התגובה Server-Timing מוצגים באופן חזותי בחלונית Timings בכרטיסייה Network בכלי הפיתוח ל-Chrome:

כאן, Server-Timing משמש למדידה של בקשה למשאב שפגעה במטמון של ה-CDN, וכמה זמן לוקח לבקשה לפגוע בשרת הקצה של ה-CDN ואז במקור.

התזמונים של השרת מוצגים גם במסלול Network בחלונית Performance בכלי הפיתוח ל-Chrome:

אחרי שתנתחו את הנתונים הזמינים ותגיעו למסקנה שיש לכם בעיה של TTFB, תוכלו לעבור לפתרון הבעיה.

דרכים לבצע אופטימיזציה של TTFB

האתגר הגדול ביותר באופטימיזציה של TTFB הוא שבעוד שסט הכלים של הקצה הקדמי של האתר תמיד מבוסס על HTML,‏ CSS ו-JavaScript, סטאק הבק-אנד יכול להשתנות באופן משמעותי. יש הרבה סוגים של מחסני נתונים ומוצרי מסדי נתונים, ולכל אחד מהם יש טכניקות אופטימיזציה משלו. לכן, המדריך הזה מתמקד במה שרלוונטי לרוב הארכיטקטורות, ולא רק בהנחיות ספציפיות למערך טכנולוגיות מסוים.

הנחיות ספציפיות לפלטפורמה

הפלטפורמה שבה אתם משתמשים לאתר יכולה להשפיע מאוד על TTFB. לדוגמה, הביצועים של WordPress מושפעים מהמספר ומהאיכות של הפלאגינים, או מהעיצובים שבהם נעשה שימוש. גם פלטפורמות אחרות מושפעות באופן דומה כשהפלטפורמה מותאמת אישית. כדאי לעיין במסמכי התיעוד של הפלטפורמה שלכם כדי לקבל עצות ספציפיות לספקים, בנוסף לעצות הכלליות יותר לשיפור הביצועים שמופיעות במאמר הזה. תובנת Lighthouse כוללת גם הנחיות ספציפיות לסטאק.

אירוח, אירוח, אירוח

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

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

עם זאת, אם אתם מפעילים אפליקציה גדולה עם הרבה משתמשים שכוללת התאמה אישית, שאילתות במסד נתונים ופעולות אינטנסיביות אחרות בצד השרת, בחירת האירוח הופכת לקריטית כדי להקטין את TTFB בשטח.

כשבוחרים ספק אירוח, כדאי לשים לב לנקודות הבאות:

• כמה זיכרון מוקצה למופע של האפליקציה? אם אין מספיק זיכרון באפליקציה, היא תבצע החלפה אינטנסיבית של דפים בזיכרון הווירטואלי ותתקשה להציג דפים במהירות האפשרית.
• האם ספק האירוח שלכם דואג לעדכן את חבילת התוכנה של ה-Backend? ככל שיוצאות גרסאות חדשות של שפות עורפיות של אפליקציות, הטמעות HTTP ותוכנות מסדי נתונים, הביצועים של התוכנה הזו משתפרים עם הזמן. חשוב לעבוד עם ספק אירוח שנותן עדיפות לתחזוקה חיונית כזו.
• אם יש לכם דרישות ספציפיות מאוד לגבי האפליקציה ואתם רוצים את רמת הגישה הנמוכה ביותר לקובצי התצורה של השרת, כדאי לשאול אם יש טעם להתאים אישית את העורף של מופע האפליקציה שלכם.

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

שימוש ברשת להעברת תוכן (CDN)

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

רשתות CDN פותרות את הבעיה של המרחק בין המשתמשים לבין שרת המקור, באמצעות רשת מבוזרת של שרתים ששומרים במטמון משאבים בשרתים שנמצאים קרוב יותר פיזית למשתמשים. השרתים האלה נקראים שרתי קצה.

ספקי CDN עשויים להציע גם יתרונות נוספים מעבר לשרתי קצה:

• ספקי CDN מציעים בדרך כלל זמני פענוח DNS מהירים במיוחד.
• סביר להניח שרשת CDN תציג את התוכן שלכם משרתי קצה באמצעות פרוטוקולים מודרניים כמו HTTP/2 או HTTP/3.
• פרוטוקול HTTP/3 פותר את בעיית החסימה של ראש התור שקיימת ב-TCP (שפרוטוקול HTTP/2 מסתמך עליו) באמצעות פרוטוקול UDP.
• סביר להניח שרשת CDN מספקת גרסאות מודרניות של TLS, מה שמקצר את זמן השהייה שקשור לזמן המשא ומתן של TLS. TLS 1.3, בפרט, מתוכנן כך שמשא ומתן בפרוטוקול TLS יהיה קצר ככל האפשר.
• חלק מספקי ה-CDN מספקים תכונה שלרוב נקראת 'edge worker', שמשתמשת ב-API שדומה ל-API של Service Worker כדי ליירט בקשות, לנהל תשובות באופן פרוגרמטי במטמון של שרתים קרובים או לשכתב תשובות לחלוטין.
• ספקי CDN מצטיינים באופטימיזציה של דחיסה. קשה לבצע דחיסה בצורה נכונה לבד, ובמקרים מסוימים היא עלולה להוביל לזמני תגובה איטיים יותר עם סימון שנוצר באופן דינמי, שצריך לדחוס אותו תוך כדי התהליך.
• בנוסף, ספקי CDN שומרים במטמון באופן אוטומטי תגובות דחוסות למשאבים סטטיים, וכך מתקבל השילוב הטוב ביותר של יחס דחיסה וזמן תגובה.

ההשקעה הנדרשת להטמעת CDN משתנה, אבל אם האתר שלכם עדיין לא משתמש ב-CDN, כדאי לתת לזה עדיפות גבוהה כדי לשפר את TTFB.

שימוש בתוכן שנשמר במטמון כשזה אפשרי

רשתות CDN מאפשרות לשמור תוכן במטמון בשרתי קצה שנמצאים פיזית קרוב יותר למבקרים, בתנאי שהתוכן מוגדר עם Cache-Control כותרות HTTP מתאימות. הגישה הזו לא מתאימה לתוכן בהתאמה אישית, אבל אם נדרשת חזרה למקור, הרבה מהערך של CDN מתבטל.

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

גם אם הגדרתם את השמירה במטמון בצורה נכונה, אפשר להתעלם ממנה באמצעות שימוש בפרמטרים ייחודיים של מחרוזת שאילתה למדידה ב-Analytics. יכול להיות שהתוכן ייראה שונה ל-CDN למרות שהוא זהה, ולכן לא תהיה אפשרות להשתמש בגרסה שבמטמון.

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

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

לא להשתמש בהפניות אוטומטיות מכמה דפים

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

יש שני סוגים של הפניות אוטומטיות:

• הפניות אוטומטיות מאותו מקור, שבהן ההפניה האוטומטית מתרחשת באתר שלכם.
• הפניות ממקורות שונים, שבהן ההפניה מתרחשת בהתחלה ממקור אחר – למשל משירות לקיצור כתובות URL ברשתות חברתיות – לפני שהמשתמש מגיע לאתר שלכם.

מומלץ להתמקד בהסרת הפניות חזרה לכתובת האתר המקורית, כי זה משהו שיש לכם שליטה ישירה בו. כדי לעשות זאת, צריך לבדוק את הקישורים באתר ולראות אם אחד מהם מוביל לקוד תגובה 302 או 301. לרוב, הבעיה הזו נגרמת בגלל שלא כוללים את הסכימה https:// (לכן הדפדפנים עוברים לסכימה http:// ואז מתבצעת הפניה אוטומטית), או בגלל שלא כוללים או לא מוציאים את הקו הנטוי בסוף כתובת ה-URL.

הפניות לכתובות אחרות ממקורות שונים הן מסובכות יותר, כי לרוב אין לכם שליטה בהן. עם זאת, כדאי לנסות להימנע מהפניות מרובות לכתובות אחרות ככל האפשר. למשל, לא להשתמש בכמה כלי קיצור קישורים כשמשתפים קישורים. חשוב לוודא שכתובת ה-URL שאתם מספקים למפרסמים או לניוזלטר היא כתובת ה-URL הסופית הנכונה, כדי שלא תתווסף עוד הפניה אוטומטית להפניות האוטומטיות שבהן נעשה שימוש בשירותים האלה.

מקור חשוב נוסף לזמן ההפניה האוטומטית יכול להיות הפניות אוטומטיות מ-HTTP ל-HTTPS. אחת הדרכים לעקוף את הבעיה היא להשתמש בכותרת Strict-Transport-Security (HSTS), שמחייבת שימוש ב-HTTPS בביקור הראשון במקור, ואז מורה לדפדפן לגשת למקור באופן מיידי דרך סכמת ה-HTTPS בביקורים הבאים.

אחרי שמגדירים מדיניות HSTS טובה, אפשר להאיץ את התהליך בביקור הראשון במקור על ידי הוספת האתר לרשימת הטעינה מראש של HSTS.

העברת נתוני סטרימינג לדפדפן

הדפדפנים מותאמים לעיבוד יעיל של תגי עיצוב כשהם מועברים בסטרימינג, כלומר תגי העיצוב מטופלים בחלקים כשהם מגיעים מהשרת. זה קריטי כשמדובר במטען ייעודי גדול של תגי עיצוב, כי המשמעות היא שהדפדפן יכול לנתח את חלקי תגי העיצוב באופן מצטבר, במקום לחכות להגעת התגובה כולה לפני שמתחיל הניתוח.

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

לדוגמה, ב-React ובמסגרות אחרות שיכולות לעבד סימון לפי דרישה בשרת, נעשה שימוש בגישה סינכרונית לעיבוד בצד השרת. עם זאת, בגרסאות חדשות יותר של React הוטמעו שיטות שרת להזרמת תגי עיצוב בזמן העיבוד. כלומר, אתם לא צריכים לחכות עד ששיטת React server API תעבד את כל התגובה לפני שהיא נשלחת.

דרך נוספת לוודא שתגי העיצוב מועברים לדפדפן במהירות היא להסתמך על עיבוד סטטי שיוצר קובצי HTML במהלך משך זמן של תהליך build. הקובץ המלא זמין באופן מיידי, כך ששרתי האינטרנט יכולים להתחיל לשלוח את הקובץ באופן מיידי, והמהות של HTTP גורמת לסימון של הסטרימינג. הגישה הזו לא מתאימה לכל דף בכל אתר – למשל, לדפים שדורשים תגובה דינמית כחלק מחוויית המשתמש – אבל היא יכולה להיות מועילה לדפים שלא דורשים התאמה אישית של התגי עיצוב למשתמש ספציפי.

שימוש בקובץ שירות (service worker)

ל-Service Worker API יכולה להיות השפעה משמעותית על TTFB גם במסמכים וגם במשאבים שהם טוענים. הסיבה לכך היא ש-Service Worker פועל כ-proxy בין הדפדפן לבין השרת. עם זאת, ההשפעה על TTFB של האתר תלויה באופן ההגדרה של Service Worker, והאם ההגדרה הזו תואמת לדרישות של האפליקציה.

• משתמשים באסטרטגיית אימות מחדש של נכסים. אם נכס נמצא במטמון של קובץ השירות (service worker), בין אם מדובר במסמך או במשאב שהמסמך דורש, האסטרטגיה stale-while-revalidate מציגה את המשאב הזה מהמטמון קודם, ואז מורידה את הנכס הזה ברקע ומציגה אותו מהמטמון לאינטראקציות עתידיות.
  • אם יש לכם משאבי מסמכים שלא משתנים לעיתים קרובות, שימוש באסטרטגיית אימות מחדש בזמן שהנתונים לא עדכניים יכול להפוך את TTFB של דף לכמעט מיידי. עם זאת, השיטה הזו לא מתאימה אם האתר שלכם שולח תגי עיצוב שנוצרים באופן דינמי – למשל, תגי עיצוב שמשתנים בהתאם לשאלה אם המשתמש מאומת. במקרים כאלה, תמיד כדאי לפנות קודם לרשת, כדי שהמסמך יהיה עדכני ככל האפשר.
  • אם המסמך טוען משאבים לא קריטיים שמשתנים בתדירות מסוימת, אבל אחזור של משאב לא עדכני לא ישפיע באופן משמעותי על חוויית המשתמש – כמו תמונות נבחרות או משאבים אחרים שלא קריטיים – אפשר לצמצם באופן משמעותי את TTFB של המשאבים האלה באמצעות אסטרטגיית stale-while-revalidate.
• שימוש במודל מעטפת האפליקציה עבור אפליקציות שעברו עיבוד בצד הלקוח. המודל הזה מתאים במיוחד לאפליקציות SPA שבהן אפשר להציג את ה'מעטפת' של הדף באופן מיידי מהמטמון של קובץ השירות (service worker), והתוכן הדינמי של הדף מאוכלס ומוצג בשלב מאוחר יותר במחזור החיים של הדף.

שימוש במשתנה 103 Early Hints למשאבים קריטיים לעיבוד

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

הכותרת 103 Early Hints היא קוד תגובה מוקדם שהשרת יכול לשלוח לדפדפן בזמן שהקצה העורפי עסוק בהכנת תגי עיצוב. אפשר להשתמש בכותרת הזו כדי לרמוז לדפדפן שיש משאבים קריטיים לעיבוד שהדף צריך להתחיל להוריד בזמן שה-markup מוכן. בדפדפנים תומכים, ההשפעה יכולה להיות עיבוד מהיר יותר של מסמכים (CSS) וטעינה מהירה יותר של דפים.

חיסרון אחד של 103 Early Hints הוא שכמו שמנגנון ה-caching יכול להסתיר את ה-TTFB האמיתי של אתר, כך גם הם יכולים להסתיר אותו. אם תשתית השרת איטית (בגלל שהיא חלשה מדי או שהקוד צריך אופטימיזציה), יכול להיות שזה לא יהיה ברור כשמשתמשים ב-103 Early Hints כי נראה ש-TTFB מהיר. באתרים שמשתמשים ב-103 Early Hints, כדאי למדוד את זמן השרת בפועל (באמצעות Server-Timing או finalResponseHeadersStart של PerformanceNavigationTiming API).

סיכום

יש כל כך הרבה שילובים של מחסניות אפליקציות בקצה העורפי, ולכן אין מאמר אחד שיכול להקיף את כל הפעולות שאפשר לבצע כדי לקצר את זמן ההמתנה עד לבית הראשון באתר. עם זאת, יש כמה אפשרויות שתוכלו לנסות כדי לזרז קצת את התהליכים בצד השרת.

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