איך לבצע אופטימיזציה של המדד "המהירות שבה מגיע בייט התגובה הראשון".
תאריך פרסום: 19 בינואר 2023, תאריך עדכון אחרון: 28 בנובמבר 2025
המהירות שבה מגיע בייט התגובה הראשון (TTFB) היא מדד בסיסי לביצועי אתרים, שקודם לכל מדד משמעותי אחר של חוויית המשתמש, כמו הצגת תוכן ראשוני (FCP) והמהירות שבה נטען רכיב התוכן הכי גדול (LCP). כלומר, ערכי TTFB גבוהים מוסיפים זמן למדדים שבאים אחריו.
מומלץ שהשרת יגיב לבקשות ניווט במהירות מספקת, כך שהאחוזון ה-75 של המשתמשים יחוו FCP בטווח של הסף "טוב". באופן כללי, ברוב האתרים כדאי לשאוף ל-TTFB של 0.8 שניות או פחות.
איך מודדים את ה-TTFB
לפני שתוכלו לבצע אופטימיזציה של TTFB, תצטרכו לבדוק איך הוא משפיע על המשתמשים באתר. כדאי להסתמך על נתוני שדה כמקור העיקרי לבדיקת TTFB, כי הם מושפעים מהפניות אוטומטיות, ואילו כלים מבוססי-מעבדה נמדדים לעיתים קרובות באמצעות כתובת ה-URL הסופית, ולכן לא כוללים את העיכוב הנוסף הזה.
PageSpeed Insights היא דרך אחת לקבל מידע מהשטח ומהמעבדה לגבי אתרים ציבוריים שזמינים בדוח על חוויית המשתמש ב-Chrome.
ה-TTFB של משתמשים אמיתיים מוצג בקטע העליון רוצה נתונים על החוויה של המשתמשים בפועל?:
בנתוני מעבדה, בעיות ב-TTFB מוצגות בתובנה זמן האחזור של בקשת מסמך:
כדי לגלות דרכים נוספות למדידת TTFB גם בשטח וגם במעבדה, עיינו בדף המדד של TTFB.
ההבדלים בין TTFB בשטח לבין TTFB במעבדה
יכולים להיות הבדלים בין ערכי ה-TTFB במעבדה ובשטח. במקרים כאלה, חשוב להבין למה יש הבדלים כדי שתוכלו להשתמש ביעילות בנתוני המעבדה לשיפור חוויית המשתמש.
אם ה-TTFB בסביבת הבדיקה גדול בהרבה מה-TTFB בסביבת המשתמשים, זה מצביע על כך שסביבת הבדיקה מוגבלת יותר מהסביבה שבה המשתמשים בדרך כלל חווים את האתר. זו לא בהכרח בעיה, כי התוצאות וההמלצות של המעבדה עדיין תקפות, אבל יכול להיות שהן מגזימות בהערכת ההשפעה והשיפור.
כשה-TTFB בשטח גדול בהרבה מה-TTFB במעבדה, זה מצביע על בעיות שלא נראות בהרצה במעבדה, כמו שימוש במטמון בצד השרת, הפניות או הבדלים ברשת. במקרה כזה, יכול להיות שתוצאות הבדיקה וההמלצות יהיו פחות שימושיות, כי הן לא יתייחסו לאחת מהבעיות העיקריות.
כדי לבדוק אם השמירה במטמון בצד השרת משפיעה על ה-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, המחסניות של הקצה העורפי יכולות להשתנות באופן משמעותי. יש הרבה סטאקים של קצה עורפי ומוצרי מסדי נתונים, ולכל אחד מהם יש טכניקות אופטימיזציה משלו. לכן, המדריך הזה מתמקד במה שרלוונטי לרוב הארכיטקטורות, ולא רק בהנחיות ספציפיות ל-stack.
הנחיות ספציפיות לפלטפורמה
הפלטפורמה שבה אתם משתמשים באתר יכולה להשפיע מאוד על ה-TTFB. לדוגמה, הביצועים של WordPress מושפעים מהמספר והאיכות של הפלאגינים, או מהעיצובים שבהם משתמשים. פלטפורמות אחרות מושפעות באופן דומה כשהפלטפורמה מותאמת אישית. כדאי לעיין במסמכי התיעוד של הפלטפורמה שלכם כדי לקבל עצות ספציפיות לספק, בנוסף לעצות הכלליות יותר לגבי ביצועים שמופיעות בפוסט הזה. התובנה של Lighthouse כוללת גם הנחיות מוגבלות ספציפיות למקבץ.
אירוח, אירוח, אירוח
לפני שאתם שוקלים גישות אחרות לאופטימיזציה, כדאי לבדוק קודם את האירוח. אין הרבה הנחיות ספציפיות שאפשר להציע כאן, אבל כלל אצבע כללי הוא לוודא שהמארח של האתר שלכם מסוגל לטפל בתנועה שאתם שולחים אליו.
אירוח משותף בדרך כלל איטי יותר. אם אתם מפעילים אתר אישי קטן שמציג בעיקר קבצים סטטיים, כנראה שזה בסדר. כדי לצמצם את ה-TTFB ככל האפשר, כדאי להשתמש בחלק מטכניקות האופטימיזציה הבאות.
עם זאת, אם אתם מפעילים אפליקציה גדולה יותר עם הרבה משתמשים, שכוללת התאמה אישית, שאילתות במסד נתונים ופעולות אינטנסיביות אחרות בצד השרת, בחירת האירוח הופכת להיות קריטית להפחתת ה-TTFB בשטח.
כשבוחרים ספק אירוח, כדאי לשים לב לדברים הבאים:
- כמה זיכרון מוקצה למכונה של האפליקציה? אם אין מספיק זיכרון באפליקציה, היא תתקשה להציג דפים במהירות האפשרית.
- האם ספק האירוח שלכם מעדכן את ה-backend stack? ככל שמתפרסמות גרסאות חדשות של שפות לקצה העורפי של האפליקציה, של הטמעות 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 מספקים תכונה שנקראת בדרך כלל "עובד קצה", שמשתמשת ב-API שדומה ל-Service Worker API כדי ליירט בקשות, לנהל באופן פרוגרמטי תגובות בשמירה במטמון קצה או לשכתב תגובות לחלוטין.
- ספקי CDN טובים מאוד באופטימיזציה של דחיסה. קשה לבצע דחיסה בצורה נכונה באופן עצמאי, והיא עלולה להוביל לזמני תגובה איטיים יותר במקרים מסוימים עם תגי עיצוב שנוצרים באופן דינמי, שצריך לדחוס אותם תוך כדי תנועה.
- בנוסף, ספקי CDN שומרים באופן אוטומטי במטמון תשובות דחוסות למשאבים סטטיים, וכך נוצר השילוב הטוב ביותר בין יחס הדחיסה לזמן התגובה.
המאמץ הכרוך בהטמעת CDN משתנה, ויכול להיות קל או משמעותי. עם זאת, אם האתר שלכם עדיין לא משתמש ב-CDN, כדאי לתת עדיפות גבוהה להטמעה שלו כדי לשפר את ה-TTFB.
שימוש בתוכן שנשמר במטמון כשאפשר
רשתות CDN מאפשרות לשמור תוכן במטמון בשרתי קצה שממוקמים פיזית קרוב יותר למבקרים, בתנאי שהתוכן מוגדר עם Cache-Control כותרות HTTP מתאימות. אמנם זה לא מתאים לתוכן מותאם אישית, אבל הדרישה לחזור כל הדרך חזרה למקור יכולה לבטל חלק גדול מהערך של CDN.
באתרים שמעדכנים את התוכן שלהם לעיתים קרובות, אפילו זמן שמירה קצר במטמון יכול לשפר את הביצועים של אתרים עמוסים, כי רק המבקר הראשון בזמן הזה חווה את זמן האחזור המלא בחזרה לשרת המקור, בעוד שכל המבקרים האחרים יכולים לעשות שימוש חוזר במשאב שנשמר במטמון משרת הקצה. חלק מרשתות ה-CDN מאפשרות לנקות את המטמון כשמשיקים אתר, וכך ליהנות משני העולמות – זמני מטמון ארוכים, אבל עדכונים מיידיים כשצריך.
גם אם השמירה במטמון מוגדרת בצורה נכונה, אפשר להתעלם ממנה באמצעות פרמטרים ייחודיים של מחרוזת שאילתה למדידת ניתוח נתונים. יכול להיות שהתוכן ייראה שונה ל-CDN למרות שהוא זהה, ולכן לא ייעשה שימוש בגרסה שנשמרה במטמון.
יכול להיות שגם תוכן ישן יותר או תוכן שמגיעים אליו פחות מבקרים לא יישמר במטמון, וכתוצאה מכך ערכי ה-TTFB בדפים מסוימים יהיו גבוהים יותר מאשר בדפים אחרים. הגדלת זמני השמירה במטמון יכולה להפחית את ההשפעה של זה, אבל חשוב לזכור שככל שזמני השמירה במטמון ארוכים יותר, כך גדל הסיכוי להצגת תוכן מיושן (stale).
ההשפעה של תוכן שנשמר במטמון לא משפיעה רק על מי שמשתמש ב-CDN. יכול להיות שתשתית השרת תצטרך ליצור תוכן מחיפושים יקרים במסד הנתונים כשאי אפשר לעשות שימוש חוזר בתוכן שנשמר במטמון. נתונים שניגשים אליהם לעיתים קרובות יותר או דפים שנשמרו מראש במטמון יכולים לפעמים להניב ביצועים טובים יותר.
הימנעות מהפניות מרובות לדפים
אחד הגורמים הנפוצים ל-TTFB גבוה הוא הפניות אוטומטיות. הפניות אוטומטיות מתרחשות כשבקשת ניווט למסמך מקבלת תגובה שמודיעה לדפדפן שהמשאב קיים במיקום אחר. הפניה אוטומטית אחת בהחלט יכולה להוסיף זמן אחזור לא רצוי לבקשת ניווט, אבל המצב יכול להחמיר אם ההפניה האוטומטית הזו מפנה למשאב אחר שמוביל להפניה אוטומטית נוספת – וכן הלאה. הבעיה הזו יכולה להשפיע במיוחד על אתרים שמקבלים נפח גבוה של מבקרים ממודעות או מניוזלטרים, כי לעיתים קרובות הם מפנים דרך שירותי ניתוח נתונים למטרות מדידה. ביטול הפניות אוטומטיות שנמצאות בשליטתכם הישירה יכול לעזור לכם להשיג TTFB טוב.
יש שני סוגים של הפניות אוטומטיות:
- הפניות אוטומטיות מאותו מקור, שבהן ההפניה האוטומטית מתרחשת כולה באתר שלכם.
- הפניות אוטומטיות ממקורות שונים, שבהן ההפניה האוטומטית מתרחשת בהתחלה במקור אחר – למשל, משירות קיצור של כתובת URL ברשתות החברתיות – לפני שהיא מגיעה לאתר שלכם.
התמקדו בהסרת הפניות אוטומטיות מאותו מקור, כי זה משהו שיש לכם שליטה ישירה עליו. כדי לעשות את זה, צריך לבדוק את הקישורים באתר ולראות אם אחד מהם מחזיר קוד תגובה 302 או 301. לרוב, זה קורה כי לא כללתם את הסכימה https:// (כך שהדפדפנים משתמשים בברירת המחדל http:// ואז מפנים לכתובת אחרת) או כי לא כללתם או החרגתם לוכסנים נגררים בכתובת ה-URL.
הפניות ממקורות שונים הן מסובכות יותר, כי לעיתים קרובות הן לא בשליטתכם, אבל נסו להימנע מהפניות מרובות ככל האפשר – לדוגמה, על ידי שימוש בכמה כלים לקיצור קישורים כשאתם משתפים קישורים. ודאו שכתובת ה-URL שאתם מספקים למפרסמים או לניוזלטרים היא כתובת ה-URL הסופית הנכונה, כדי לא להוסיף עוד הפניה אוטומטית לאלה שבהן השירותים האלה משתמשים.
מקור חשוב נוסף לזמן הפניה אוטומטית יכול להיות הפניות אוטומטיות מ-HTTP ל-HTTPS. אחת מהדרכים לעקוף את הבעיה הזו היא להשתמש בכותרת Strict-Transport-Security (HSTS), שאוכפת את השימוש ב-HTTPS בביקור הראשון במקור, ואז מורה לדפדפן לגשת מיד למקור באמצעות סכימת HTTPS בביקורים הבאים.
אחרי שמגדירים מדיניות HSTS טובה, אפשר לזרז את הדברים בביקור הראשון במקור על ידי הוספת האתר לרשימת הטעינה מראש של HSTS.
העברת תגי עיצוב לדפדפן
הדפדפנים עוברים אופטימיזציה כדי לעבד את תגי העיצוב ביעילות כשהם מועברים בסטרימינג. כלומר, תגי העיצוב מטופלים בחלקים כשהם מגיעים מהשרת. זה קריטי כשמדובר במטען ייעודי (payload) גדול של תגי עיצוב, כי זה אומר שהדפדפן יכול לנתח את מקטעי תגי העיצוב באופן מצטבר, במקום להמתין עד שכל התגובה תגיע לפני שיוכל להתחיל בניתוח.
למרות שדפדפנים מטפלים היטב בתגי עיצוב בסטרימינג, חשוב לעשות כל מה שאפשר כדי לשמור על זרימת הנתונים, כך שהחלקים הראשונים של תגי העיצוב יגיעו כמה שיותר מהר. אם ה-backend מעכב את הדברים, זו בעיה. יש הרבה סטאקים של קצה עורפי, ולכן לא נסקור במדריך הזה כל סטאק בנפרד ואת הבעיות שיכולות לצוץ בכל אחד מהם.
לדוגמה, React ומסגרות אחרות שיכולות לעבד תגי עיצוב על פי דרישה בשרת משתמשות בגישה סינכרונית לעיבוד בצד השרת. עם זאת, בגרסאות חדשות יותר של React הוטמעו שיטות שרת להעברת תגי עיצוב בסטרימינג בזמן העיבוד שלהם. זה אומר שאתם לא צריכים לחכות ששיטת API של שרת React תעבד את כל התגובה לפני שהיא נשלחת.
דרך נוספת לוודא שתגי העיצוב מועברים לדפדפן במהירות היא להסתמך על עיבוד סטטי, שיוצר קובצי HTML במהלך זמן ה-build. כשהקובץ המלא זמין באופן מיידי, שרתי אינטרנט יכולים להתחיל לשלוח את הקובץ באופן מיידי, והאופי המובנה של HTTP מוביל לתגי עיצוב בסטרימינג. הגישה הזו לא מתאימה לכל דף בכל אתר, למשל דפים שדורשים תגובה דינמית כחלק מחוויית המשתמש, אבל היא יכולה להועיל בדפים שלא דורשים התאמה אישית של תגי העיצוב למשתמש ספציפי.
שימוש בקובץ שירות (service worker)
ל-Service Worker API יכולה להיות השפעה משמעותית על ה-TTFB של המסמכים ושל המשאבים שהם טוענים. הסיבה לכך היא ש-Service Worker פועל כשרת proxy בין הדפדפן לשרת, אבל ההשפעה על ה-TTFB של האתר תלויה באופן שבו הגדרתם את ה-Service Worker, ואם ההגדרה הזו תואמת לדרישות של האפליקציה.
- השתמשו באסטרטגיית stale-while-revalidate לנכסים. אם נכס נמצא במטמון של קובץ השירות (service worker), בין אם מדובר במסמך או במשאב שהמסמך דורש, אסטרטגיית stale-while-revalidate מציגה את המשאב הזה מהמטמון קודם, ואז מורידה את הנכס הזה ברקע ומציגה אותו מהמטמון לאינטראקציות עתידיות.
- אם יש לכם משאבי מסמכים שלא משתנים לעיתים קרובות, שימוש באסטרטגיית stale-while-revalidate יכול להפוך את ה-TTFB של הדף לכמעט מיידי. עם זאת, השיטה הזו לא פועלת היטב אם האתר שלכם שולח תגי עיצוב שנוצרים באופן דינמי, כמו תגי עיצוב שמשתנים בהתאם לאימות המשתמש. במקרים כאלה, תמיד כדאי לפנות לרשת קודם, כדי שהמסמך יהיה עדכני ככל האפשר.
- אם המסמך טוען משאבים לא קריטיים שמשתנים בתדירות מסוימת, אבל אחזור המשאב הישן לא ישפיע באופן משמעותי על חוויית המשתמש – כמו תמונות נבחרות או משאבים אחרים שהם לא קריטיים – אפשר להפחית באופן משמעותי את ה-TTFB של המשאבים האלה באמצעות אסטרטגיית stale-while-revalidate.
- השתמשו במודל מעטפת האפליקציה לאפליקציות שעוברות רינדור בצד הלקוח. המודל הזה מתאים במיוחד לאפליקציות SPA שבהן אפשר להעביר את "מעטפת" הדף באופן מיידי מהמטמון של קובץ השירות (service worker), והתוכן הדינמי של הדף מאוכלס ומעובד בשלב מאוחר יותר במחזור החיים של הדף.
שימוש ב-103 Early Hints למשאבים קריטיים לעיבוד
לא משנה עד כמה ה-backend של האפליקציה שלכם עבר אופטימיזציה, עדיין יכול להיות שהשרת יצטרך לבצע כמות משמעותית של עבודה כדי להכין תגובה, כולל עבודה יקרה (אך הכרחית) על מסד הנתונים שמעכבת את ההגעה של תגובת הניווט במהירות האפשרית. ההשפעה הפוטנציאלית של זה היא שחלק מהמשאבים הקריטיים לעיבוד שמופיעים בהמשך עלולים להתעכב, כמו CSS או, במקרים מסוימים, JavaScript שמעבד תגי עיצוב אצל הלקוח.
103 Early Hints header הוא קוד תגובה מוקדם שהשרת יכול לשלוח לדפדפן בזמן שה-backend עסוק בהכנת תגי עיצוב. אפשר להשתמש בכותרת הזו כדי לרמוז לדפדפן שיש משאבים קריטיים לעיבוד שהדף צריך להתחיל להוריד בזמן הכנת תגי העיצוב. בדפדפנים נתמכים, ההשפעה יכולה להיות עיבוד מהיר יותר של מסמכים (CSS) וטעינת דפים מהירה יותר.
חיסרון אחד של 103 Early Hints הוא שכמו שמירה במטמון, הם יכולים להסתיר את ה-TTFB "האמיתי" של האתר. אם תשתית השרת איטית (בגלל שהיא חלשה מדי או שהקוד זקוק לאופטימיזציה), יכול להיות שזה יהיה פחות ברור כשמשתמשים ב-103 Early Hints כי נראה שה-TTFB מהיר. באתרים שמשתמשים ב-103 Early Hints, כדאי למדוד את זמן השרת בפועל (באמצעות Server-Timing או finalResponseHeadersStart של PerformanceNavigationTiming API).
סיכום
יש כל כך הרבה שילובים של מחסניות אפליקציות בקצה העורפי, ולכן אין מאמר אחד שיכול להכיל את כל מה שאפשר לעשות כדי להפחית את ה-TTFB של האתר. עם זאת, יש כמה אפשרויות שאפשר לבדוק כדי לנסות לזרז קצת את העניינים בצד השרת.
כמו באופטימיזציה של כל מדד, הגישה דומה במידה רבה: מודדים את ה-TTFB בשטח, משתמשים בכלים של מעבדה כדי להבין לעומק את הסיבות, ואז מבצעים אופטימיזציה כשאפשר. יכול להיות שחלק מהשיטות לא יתאימו למצב שלכם, אבל סביר להניח שחלק כן. כמו תמיד, תצטרכו לעקוב מקרוב אחרי נתוני השדה ולבצע שינויים לפי הצורך כדי להבטיח חוויית משתמש מהירה ככל האפשר.