הסבר על אופטימיזציה למדד 'זמן עד בייט ראשון' (Time to First Byte)
זמן עד בייט ראשון (TTFB) הוא מדד בסיסי של ביצועים באינטרנט שקודם לכל מדד משמעותי אחר של חוויית משתמש, כמו First Contentful Paint (FCP) וLCP). המשמעות היא שערכים גבוהים של 'TTDFB' מוסיפים זמן למדדים שאחריו.
מומלץ שהשרת יגיב לבקשות ניווט מהר מספיק, כך שהאחוזון ה-75 של המשתמשים יצפה ב-FCP בתוך הסף 'טוב'. להנחיה גסה, רוב האתרים צריכים לשאוף לכך שערך ה-TTDFB יהיה 0.8 שניות או פחות.
איך מודדים את מדד ה-TTDFB
לפני שתוכלו לבצע אופטימיזציה של 'דברים שאפשר לעשות', צריך לבדוק איך היא משפיעה על משתמשי האתר. כדאי להסתמך על נתוני השטח כמקור עיקרי לתצפית על אובייקט ה-TTDFB כפי שהוא מושפע מהפניות אוטומטיות. לעומת זאת, כלים מבוססי-מעבדה נמדדים לעיתים קרובות באמצעות כתובת ה-URL הסופית, ולכן חסר עיכוב נוסף זה.
PageSpeed Insights הוא אחת מהדרכים לקבל מידע גם על שטח וגם על שיעור Lab עבור אתרים ציבוריים שזמינים בדוח על חוויית המשתמש ב-Chrome.
המידע שמוצג למשתמשים אמיתיים מוצג בחלק העליון של הדף לגלות מה המשתמשים האמיתיים חווים:
קבוצת משנה של TTFB מוצגת בבדיקה של זמן התגובה של השרת:
לדרכים נוספות למדוד את מדד 'דברים שאפשר לעשות' (TTDFB) גם בשדה וגם בשיעור ה-Lab, אפשר לעיין בדף המדדים של TTFB.
ניפוי באגים ערך 'LTFB' גבוה בשדה עם 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 - $dbReadStarTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
כשהכותרת הזו מוגדרת, היא תציג מידע שאפשר להשתמש בו גם בשיעור ה-Lab וגם בשדה.
בשדה, כל דף עם כותרת תגובה 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);
});
בשיעור ה-Lab, הנתונים מכותרת התשובה Server-Timing יוצגו באופן חזותי בחלונית התזמונים של הכרטיסייה רשת בכלי הפיתוח ל-Chrome:
כותרות תגובה של Server-Timing מוצגות בכרטיסייה 'רשת' של כלי הפיתוח ל-Chrome. כאן, המדיניות Server-Timing משמשת כדי לבדוק אם בקשה למשאב הגיעה למטמון ה-CDN, וכמה זמן עובר עד שהבקשה מגיעה לשרת הקצה של ה-CDN ואז למקור.
לאחר שתזהו שיש לכם בעיה שקשורה ל-TTDFB על ידי ניתוח הנתונים הזמינים, תוכלו לעבור לפתרון הבעיה.
דרכים לביצוע אופטימיזציה של 'דברים שאפשר לעשות' (TTFB)
ההיבט המאתגר ביותר בביצוע אופטימיזציה ל-TTFB הוא שבעוד שסטאק הקצה של האינטרנט תמיד יהיה HTML , CSS ו-JavaScript, ערימות הקצה העורפי יכולות להשתנות באופן משמעותי. יש מספר רב של סטאקים של קצה עורפי ומוצרים של מסדי נתונים, ולכל אחד מהם יש טכניקות אופטימיזציה משלו. לכן, המדריך הזה יתמקד במה שרלוונטי לרוב הארכיטקטורות, ולא יתמקד רק בהנחיות ספציפיות לסטאק.
הנחיות ספציפיות לפלטפורמה
לפלטפורמה שבה אתם משתמשים באתר יכולה להיות השפעה משמעותית על שירות 'דברים שאפשר לעשות' (TTFB). לדוגמה, הביצועים של WordPress מושפעים מהמספר והאיכות של יישומי הפלאגין, או מהעיצובים שבהם נעשה שימוש. פלטפורמות אחרות מושפעות באופן דומה כשהפלטפורמה מותאמת אישית. עליכם לעיין בתיעוד של הפלטפורמה כדי לקבל ייעוץ ספציפי לספק, בנוסף לייעוץ הכללי יותר לגבי ביצועים בפוסט הזה. הבדיקה של Lighthouse לצמצום זמני התגובה של השרת כוללת גם כמה הנחיות מוגבלות שספציפיות למקבצים.
אירוח, אירוח, אירוח
לפני שתשקול גישות אחרות לאופטימיזציה, הדבר הראשון שצריך לקחת בחשבון הוא אירוח. אין כאן הרבה הנחיות ספציפיות, אך כלל אצבע טוב הוא לוודא שמארח האתר יכול לטפל בתנועה שאתם שולחים אליו.
אירוח משותף יהיה בדרך כלל איטי יותר. אם אתם מפעילים אתר אישי קטן שמציג בעיקר קבצים סטטיים, סביר להניח שזה בסדר, וחלק מטכניקות האופטימיזציה הבאות יעזרו לכם לצמצם ככל האפשר את שיעור ה-TTD.
עם זאת, אם אתם מריצים אפליקציה גדולה יותר עם משתמשים רבים שכוללת התאמה אישית, שאילתות מסדי נתונים ופעולות אינטנסיביות אחרות בצד השרת, בחירת האירוח הופכת להיות חיונית להפחתת ה-TTFB בשדה.
כשבוחרים ספק אירוח, חשוב לשים לב לנקודות הבאות:
- כמה זיכרון מוקצה למכונה של האפליקציה? אם לאפליקציה אין מספיק זיכרון, היא תתקשה לטפל בדפים מהר ככל האפשר.
- האם ספק האירוח מעדכן את סטאק הקצה העורפי שלכם? ככל שמתפרסמות גרסאות חדשות של שפות הקצה העורפי של האפליקציות, הטמעות HTTP ותוכנות של מסדי נתונים, הביצועים של התוכנה הזו ישתפרו עם הזמן. חשוב לעבוד עם ספק אירוח שנותן עדיפות לתחזוקה חיונית מהסוג הזה.
- אם יש לכם דרישות ספציפיות מאוד לאפליקציה ואתם רוצים לקבל גישה ברמה הנמוכה ביותר לקובצי תצורת שרת, שאלו אם הגיוני להתאים אישית את הקצה העורפי של המכונה שלכם.
יש הרבה ספקי אירוח שיטפלו בדברים האלה בשבילכם, אבל אם תתחילו לראות ערכים ארוכים של 'טורף', גם אצל ספקי אירוח ייעודיים, ייתכן שתצטרכו להעריך מחדש את היכולות של ספק האירוח הנוכחי שלכם כדי שתוכלו לספק חוויית משתמש טובה ככל האפשר.
שימוש ברשת להעברת תוכן (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 כרוך במאמצים שונים, משינויים טריוויאליים למשמעותיים, אבל חשוב לבצע אופטימיזציה של ה-TTFB אם עדיין לא נעשה בו שימוש.
שימוש בתוכן שנשמר במטמון כשזה היה אפשרי
רשתות CDN מאפשרות שמירה במטמון של תוכן בשרתי קצה שממוקמים פיזית בקרב המבקרים, בתנאי שהתוכן מוגדר עם Cache-Control כותרות HTTP מתאימות. הפעולה הזו לא מתאימה לתוכן מותאם אישית, אבל דרישה לנסיעה חוזרת עד המקור יכולה לשלול חלק גדול מהערך של CDN.
באתרים שמעדכנים את התוכן שלהם לעיתים קרובות, גם שמירה לזמן קצר במטמון יכולה להוביל לשיפורים משמעותיים בביצועים של אתרים עמוסים, כי רק המבקר הראשון באותו זמן חווים את זמן האחזור המלא בחזרה לשרת המקור, ואילו כל שאר המבקרים יכולים להשתמש שוב במשאב שנשמר במטמון משרת הקצה. רשתות CDN מסוימות מאפשרות ביטול תוקף של מטמון בגרסאות אתרים וכך אפשר ליהנות משני העולמות – זמני מטמון ארוכים אבל עדכונים מיידיים במקרה הצורך.
גם אם השמירה במטמון מוגדרת בצורה נכונה, אפשר להתעלם מההנחיה הזו אם משתמשים בפרמטרים ייחודיים של מחרוזת שאילתה לצורך מדידה של ניתוח נתונים. ייתכן שהשמות האלה ייראו כמו תוכן שונה ב-CDN למרות שהם זהים, ולכן לא ייעשה שימוש בגרסת המטמון.
בנוסף, יכול להיות שתוכן ישן או פחות מבקרים לא יישמר במטמון, וזה עלול להוביל לערך גבוה יותר של ערך 'TTDFB' בדפים מסוימים בהשוואה לדפים אחרים. הגדלת זמני השמירה במטמון יכולה לצמצם את ההשפעה של זה, אבל חשוב לדעת שככל שמאריכים את זמני השמירה במטמון, כדאי להציג תוכן שעשוי להיות מיושן.
ההשפעה של תוכן שנשמר במטמון לא משפיעה רק על אנשים שמשתמשים ברשתות CDN. יכול להיות שבתשתית השרת יהיה צורך ליצור תוכן מחיפושים יקרים במסד הנתונים כשאי אפשר לעשות שימוש חוזר בתוכן שנשמר במטמון. בדרך כלל, הביצועים של נתונים שניגשים אליהם לעיתים קרובות יותר או של דפים שנשמרו במטמון מראש עשויים להיות טובים יותר.
נמנעים מהפניות מרובות של דפים
אחד הגורמים הנפוצים ביותר לשינוי ערך ה-TTDFB הוא הפניות אוטומטיות. הפניות אוטומטיות מתרחשות כשבקשת ניווט למסמך מקבלת תשובה שמיידעת את הדפדפן שהמשאב קיים במיקום אחר. הפניה לכתובת אחרת אחת בהחלט יכולה להוסיף זמן אחזור לא רצוי לבקשת ניווט, אבל זה בהחלט עלול להחמיר אם היא מפנה למשאב אחר שמוביל להפניה אחרת – וכן הלאה. הדבר עלול להשפיע במיוחד על אתרים שמקבלים כמויות גדולות של מבקרים מפרסומות או מניוזלטרים, מפני שבמקרים רבים הם מפנים מחדש דרך שירותי ניתוח נתונים למטרות מדידה. ביטול כתובות האתר להפניה מחדש תחת השליטה הישירה שלכם יכול לעזור לכם להשיג ערך טראפיק מוצלח.
קיימים שני סוגים של הפניות אוטומטיות:
- הפניות אוטומטיות מאותו מקור – שבהן ההפניה האוטומטית מתרחשת רק באתר שלכם.
- הפניות ממקורות שונים, שבהן ההפניה האוטומטית מתרחשת בהתחלה במקור אחר – למשל, משירות קיצור כתובות URL של רשת חברתית, לפני ההגעה לאתר.
מומלץ להתמקד בביטול הפניות אוטומטיות מאותו מקור, מכיוון שתוכלו לשלוט באופן ישיר על האפשרות הזו. לשם כך, צריך לבדוק קישורים באתר כדי לראות אם אחד מהם מוביל לקוד תגובה 302 או 301. לעיתים קרובות זו יכולה להיות תוצאה של אי-הכללה של הסכימה https:// (כך שברירת המחדל של דפדפנים היא http://, ואז מתבצעת הפניה אוטומטית) או כי לוכסנים בסוף לא נכללים או מוחרגים כמו שצריך בכתובת ה-URL.
הפניות אוטומטיות ממקורות שונים הן מורכבות יותר כי לעיתים קרובות הן לא בשליטתכם, אבל כדאי להימנע מהפניות מרובות כשאפשר. לדוגמה, שימוש בכמה מקצרי קישורים כשמשתפים קישורים. צריך לוודא שכתובת ה-URL שסיפקתם למפרסמים או לניוזלטרים היא כתובת ה-URL הסופית הנכונה, כדי לא להוסיף עוד הפניה לכתובות אחרות שהשירותים האלה משתמשים בהן.
מקור חשוב נוסף של זמן הפניה אוטומטית יכול להגיע מהפניות אוטומטיות מסוג HTTP אל HTTPS. דרך אחת לעקוף את הבעיה היא להשתמש בכותרת Strict-Transport-Security (HSTS). הכותרת הזו תאכף HTTPS בביקור הראשון אל מקור, ואז תאמר לדפדפן לגשת מיד למקור דרך סכימת HTTPS בביקורים עתידיים.
לאחר שתיצרו מדיניות HSTS טובה, תוכלו לזרז את התהליך בביקור הראשון אל מקור על ידי הוספת האתר שלכם לרשימת הטעינה מראש של HSTS.
סטרימינג של תגי עיצוב לדפדפן
דפדפנים עוברים אופטימיזציה לעיבוד יעיל של תגי עיצוב בזמן הסטרימינג שלהם. כלומר, תגי עיצוב מעובדים במקטעים כשהם מגיעים מהשרת. זה חשוב מאוד כאשר מדובר במטענים ייעודיים (payloads) גדולים של תגי עיצוב, כי הדפדפן יכול לנתח את מקטעי תגי העיצוב באופן מצטבר, במקום להמתין עד שהתגובה כולה תגיע לפני שהניתוח יכול להתחיל.
אומנם דפדפנים טובים בטיפול בתגי עיצוב בסטרימינג, אבל חשוב לעשות את כל מה שאפשר כדי שסטרימינג ימשיך לזרום כדי שקטעי העיצוב הראשוניים יגיעו לדרכם בהקדם האפשרי. אם הקצה העורפי מעכב את התהליך, זו בעיה. מכיוון שיש הרבה סטאקים של קצה עורפי, המדריך הזה לא כולל כל סטאק ובעיות בכל אחת מהן.
לדוגמה, תגובות ומסגרות אחרות שיכולות לעבד תגי עיצוב בשרת לפי דרישה – השתמשו בגישה סינכרונית לעיבוד בצד השרת. עם זאת, בגרסאות חדשות יותר של React הוטמעו שיטות שרת לתגי עיצוב בסטרימינג בזמן העיבוד. כלומר, אין צורך להמתין עד ששיטת ה-API של שרת ה-React תעבד את כל התגובה לפני שהיא נשלחת.
דרך נוספת להבטיח שתגי העיצוב יועברו בסטרימינג לדפדפן במהירות היא להסתמך על רינדור סטטי, שיוצר קובצי HTML במהלך זמן ה-build. כשהקובץ המלא זמין באופן מיידי, שרתי אינטרנט יכולים להתחיל לשלוח את הקובץ באופן מיידי, והאופי של HTTP יגרום לתגי עיצוב בסטרימינג. הגישה הזו לא מתאימה לכל דף בכל אתר – למשל, דפים שדורשים תגובה דינמית כחלק מחוויית המשתמש – אבל היא יכולה להועיל לדפים שלא דורשים התאמה אישית של תגי עיצוב למשתמש מסוים.
שימוש ב-Service Worker
ל-Service Worker API יכולה להיות השפעה משמעותית על 'דברים שאפשר לעשות' – גם במסמכים וגם במשאבים שהם טוענים. הסיבה לכך היא ש-Service Worker משמש כשרת Proxy בין הדפדפן לשרת – אבל ההשפעה על ה-TTDFB של האתר תלויה באופן שבו אתם מגדירים את ה-Service Worker ואם ההגדרה הזו תואמת לדרישות האפליקציה שלכם.
- משתמשים באסטרטגיה לא פעילה בזמן אימות מחדש לנכסים. אם נכס נמצא במטמון של קובץ השירות (service worker) – למשל מסמך או משאב שנדרש למסמך – האסטרטגיה לא פעילה בזמן האימות מחדש תשרת את המשאב הזה מהמטמון קודם, היא תוריד את הנכס הזה ברקע ותציג אותו מהמטמון לצורך אינטראקציות עתידיות.
- אם יש לכם משאבי מסמכים שלא משתנים לעיתים קרובות, שימוש באסטרטגיה לא פעיל בזמן אימות מחדש יכול להפוך את דף המידע ל'מצביע' באופן כמעט מיידי. עם זאת, השיטה הזו לא תהיה מועילה אם האתר שלכם שולח תגי עיצוב שנוצרו באופן דינמי, כמו תגי עיצוב שמשתנים בהתאם לאימות המשתמש. במקרים כאלה, כדאי תמיד להתחבר לרשת קודם, כדי שהמסמך יהיה עדכני ככל האפשר.
- אם המסמך טוען משאבים לא קריטיים שמשתנים בתדירות מסוימת, אבל אחזור המשאב הלא פעיל לא ישפיע באופן משמעותי על חוויית המשתמש, כמו בחירת תמונות או משאבים אחרים שאינם קריטיים, ניתן לצמצם משמעותית את ה-TTFB עבור המשאבים האלה באמצעות אסטרטגיה לא פעילה בזמן האימות מחדש.
- משתמשים במודל מעטפת האפליקציה לאפליקציות שמעובדות על ידי לקוח. המודל הזה הכי מתאים לניידים עם רשתות SPA שבהן ניתן להעביר את ה "מעטפת" של הדף באופן מיידי מהמטמון של Service Worker, והתוכן הדינמי של הדף מאוכלס ומעובד בשלב מאוחר יותר במחזור החיים של הדף.
שימוש ב-103 Early Hints למשאבים קריטיים לעיבוד מידע
גם אם הקצה העורפי של האפליקציה עבר אופטימיזציה, ייתכן שעדיין יש כמות משמעותית של עבודה שהשרת צריך לבצע כדי להכין תגובה, כולל עבודה יקרה (עדיין נדרשת) במסד הנתונים שתעכב את קבלת תגובת הניווט במהירות האפשרית. לכך תהיה השפעה אפשרית על חלק מהמשאבים הקריטיים לעיבוד מידע, כמו CSS, או במקרים מסוימים - JavaScript שמעבד תגי עיצוב בלקוח.
הכותרת 103 Early Hints היא קוד תגובה מוקדמת שהשרת יכול לשלוח לדפדפן בזמן שהקצה העורפי עסוק בהכנת תגי העיצוב. ניתן להשתמש בכותרת הזו כדי לרמוז לדפדפן שיש משאבים חיוניים לעיבוד שהדף צריך להתחיל להוריד בזמן שתגי העיצוב מתכוננים להכנה. בתמיכה בדפדפנים, ההשפעה יכולה להיות עיבוד מסמכים מהיר יותר (CSS) וזמינות מהירה יותר של פונקציונליות הליבה של הדף (JavaScript).
סיכום
מכיוון שיש כל כך הרבה שילובים של מקבצים של אפליקציות בקצה עורפי, אין מאמר אחד שיכול להכיל כל מה שאפשר לעשות כדי להוריד את מדד ה-TTDFB של האתר. עם זאת, הנה כמה אפשרויות שתוכלו לנסות כדי להתחיל לעבוד קצת יותר מהר בצד השרת.
בדומה לאופטימיזציה של כל מדד, הגישה דומה ברובה: מודדים את ה-TTDFB בשטח, משתמשים בכלים לשיעור ה-Lab כדי להציג פירוט של הסיבות, ולאחר מכן מבצעים אופטימיזציות ככל האפשר. לא כל השיטות כאן מתאימות למצב שלכם, אבל חלקן יהיו שימושיות. כמו תמיד, צריך לעקוב מקרוב אחרי נתוני השטח ולבצע שינויים לפי הצורך כדי להבטיח חוויית משתמש מהירה ככל האפשר.
תמונה ראשית (Hero) מאת Taylor Vick, שמקורה ב-Un פעילות.