תוכלו ללמוד איך לבצע אופטימיזציה למדד 'זמן עד בייט ראשון'.
Time to First Byte (TTFB) הוא מדד בסיסי של ביצועי האתר שקודם לכל מדד משמעותי אחר של חוויית המשתמש, כמו הצגת התוכן הראשוני (FCP) ו-LCP (המהירות שבה נטען רכיב התוכן הכי גדול (LCP))). המשמעות היא שערכי TTFB גבוהים מוסיפים זמן למדדים עוקבים אחריו.
מומלץ שהשרת יגיב לבקשות ניווט מהר מספיק כדי שהאחוזון ה-75 של המשתמשים יחווה FCP בסף 'טוב'. ככלל, רוב האתרים צריכים לשאוף לכך שערך TTFB יהיה באורך 0.8 שניות לכל היותר.
איך מודדים TTFB
לפני שתוכלו לבצע אופטימיזציה של TTFB, עליכם לבדוק כיצד הוא משפיע על משתמשי האתר. עליכם להסתמך על נתוני שדות כמקור עיקרי למעקב אחר תקנות TTFB, כמו הפניות אוטומטיות. לעומת זאת, כלים מבוססי מעבדה נמדדים בדרך כלל באמצעות כתובת ה-URL הסופית, ולכן העיכוב הנוסף הזה חסר.
PageSpeed Insights הוא דרך פשוטה לקבל מידע גם על השדות וגם על שיעורי ה-Lab, לגבי אתרים ציבוריים שזמינים בדוח חוויית המשתמש ב-Chrome.
TTFB לגבי משתמשים אמיתיים מוצג בקטע מה המשתמשים האמיתיים חווים בחלק העליון של הדף:
קבוצת משנה של TTFB מוצגת בביקורת של זמן התגובה של השרת:
כדי לגלות דרכים נוספות למדידת TTFB בשדה וגם בשיעור ה-Lab, אתם יכולים לעיין בדף המדדים של TTFB.
הבנת ערך גבוה של 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 - $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 יוצגו באופן חזותי בחלונית התזמונים בכרטיסייה Network בכלי הפיתוח ל-Chrome:
כותרות התגובות של Server-Timing מוצגות בכרטיסיית הרשת בכלי הפיתוח ל-Chrome. כאן, Server-Timing משמש כדי למדוד אם בקשה למשאב הגיעה למטמון ה-CDN, וכמה זמן עובר עד שהבקשה מגיעה לשרת הקצה של ה-CDN ואז למקור.
לאחר שווידאת שיש לך TTFB בעייתי על ידי ניתוח הנתונים הזמינים, תוכל להמשיך לתיקון הבעיה.
דרכים לביצוע אופטימיזציה של TTFB
ההיבט המאתגר ביותר באופטימיזציה של TTFB הוא, שבעוד שערימת הקצה של האינטרנט תהיה תמיד HTML, CSS ו-JavaScript, ערימות הקצה העורפי עשויות להשתנות באופן משמעותי. יש אינספור מוצרי קצה עורפי ומוצרי מסדי נתונים שלכל אחד מהם יש טכניקות אופטימיזציה משלו. לכן המדריך הזה יתמקד במה שרלוונטי לרוב הארכיטקטורות, ולא יתמקד רק בהנחיות ספציפיות לסטאק.
הנחיות ספציפיות לפלטפורמה
לפלטפורמה שבה אתם משתמשים באתר שלכם יכולה להיות השפעה משמעותית על TTFB. לדוגמה, הביצועים ב-WordPress מושפעים ממספר יישומי הפלאגין והאיכות שלהם, או מהעיצובים שבהם נעשה שימוש. פלטפורמות אחרות מושפעות באופן דומה כשהפלטפורמה מותאמת אישית. מומלץ לעיין במסמכי התיעוד של הפלטפורמה שלכם לקבלת ייעוץ ספציפי לספק, בנוסף לעצות הכלליות בנושא ביצועים שמופיעות בפוסט הזה. הביקורת של Lighthouse לצמצום זמני התגובה של השרת כוללת גם הנחיות ספציפיות לסטאק מוגבל.
אירוח, אירוח, אירוח
לפני שתשקלו גישות אחרות של אופטימיזציה, אירוח חייב להיות הדבר הראשון שאתם שוקלים. אין הרבה דרך להדרכה ספציפית שאפשר להציע כאן, אבל כלל אצבע כללי הוא לוודא שמארח האתר שלכם מסוגל לטפל בתנועה שאתם שולחים אליו.
אירוח משותף יהיה בדרך כלל איטי יותר. אם אתם מפעילים אתר אישי קטן שמציג בעיקר קבצים סטטיים, סביר להניח שזה בסדר, וכמה מטכניקות האופטימיזציה הבאות יעזרו לכם להפחית את TTFB עד כמה שאפשר.
עם זאת, אם אתם מפעילים אפליקציה גדולה יותר עם משתמשים רבים, שכוללת התאמה אישית, שאילתות במסד הנתונים ופעולות אינטנסיביות אחרות בצד השרת, בחירת האירוח שלכם תהפוך לקריטית כדי לצמצם את מספר ה-TTDFB בתחום.
הנה כמה דברים שכדאי לשים לב לספק כאשר בוחרים ספק אירוח:
- כמה זיכרון מוקצה למופע האפליקציה שלך? אם לאפליקציה אין מספיק זיכרון, היא תיתאץ ותתקשה להציג דפים במהירות האפשרית.
- האם ספק האירוח שלכם מעדכן את סטאק הקצה העורפי שלכם? עם ההפצה של גרסאות חדשות של שפות קצה עורפי של אפליקציות, יישומי HTTP ותוכנות מסדי נתונים, הביצועים של התוכנה הזו ישתפרו עם הזמן. חשוב לעבוד עם ספק שירותי אירוח שנותן עדיפות לתחזוקה חיונית מהסוג הזה.
- אם יש לך דרישות ספציפיות מאוד לאפליקציות וברצונך לקבל את הגישה ברמה הנמוכה ביותר לקובצי תצורה של שרת, כדאי לשאול אם הגיוני להתאים אישית את הקצה העורפי של מכונת האפליקציה שלך.
יש ספקי אירוח רבים שיטפלו בדברים האלה במקומכם, אבל אם תתחילו לראות ערכי TTFB ארוכים גם אצל ספקי אירוח ייעודיים, ייתכן שתצטרכו להעריך מחדש את היכולות של ספק האירוח הנוכחי כדי לספק לכם את חוויית המשתמש הטובה ביותר.
שימוש ברשת להעברת תוכן (CDN)
הנושא שימוש ב-CDN הוא נושא לבוש היטב, אבל מסיבה טובה: יכול להיות שקצה העורפי של האפליקציות עבר אופטימיזציה טובה, אבל משתמשים שנמצאים הרחק משרת המקור שלך עדיין עשויים לחוות צפיה גבוהה ב-TTDFB בשדה.
רשתות CDN פותרים את הבעיה של קרבת משתמשים משרת המקור באמצעות רשת מבוזרת של שרתים ששומרת משאבים במטמון בשרתים קרובים יותר באופן פיזי למשתמשים. השרתים האלה נקראים שרתי קצה.
ספקי CDN עשויים גם להציע יתרונות מעבר לשרתי קצה:
- ספקי CDN מציעים בדרך כלל זמני פענוח DNS מהירים במיוחד.
- סביר להניח ש-CDN יציג את התוכן שלכם משרתי קצה באמצעות פרוטוקולים מודרניים כמו HTTP/2 או HTTP/3.
- באמצעות פרוטוקול UDP, פרוטוקול HTTP/3 פותר את בעיית החסימה של החלק העליון (head-of-line) ב-TCP (על ידי HTTP/2).
- סביר להניח ש-CDN תספק גם גרסאות מודרניות של TLS, שיקצרו את זמן האחזור שכרוך בזמן משא ומתן ב-TLS. TLS 1.3 במיוחד מיועד לדאוג שהמשא ומתן ב-TLS יהיה קצר ככל האפשר.
- חלק מספקי CDN מספקים תכונה שנקראת לעיתים קרובות 'עובד קצה', שמשתמשת ב-API שדומה לזה של Service Worker API כדי ליירט בקשות, לנהל תגובות במטמון קצה או לשכתב תגובות לגמרי.
- ספקי CDN טובים מאוד בביצוע אופטימיזציה לדחיסה. קשה לבצע את הדחיסה באופן עצמאי, ובמקרים מסוימים היא עלולה להאט את זמני התגובה, כשמשתמשים בתגי עיצוב שנוצרים באופן דינמי, וצריך לדחוס אותם במהירות.
- ספקי CDN גם ישמרו באופן אוטומטי תגובות דחוסות למשאבים סטטיים, וכך תשיגו את השילוב הטוב ביותר של יחס דחיסה וזמן תגובה.
אמנם אימוץ CDN כרוך במאמצים שונים, מטריוויאליים למשמעותיים, אך בעדיפות גבוהה לבצע אופטימיזציה של TTFB אם האתר שלך עדיין לא משתמש ב-TTD.
נעשה שימוש בתוכן שנשמר במטמון, במידת האפשר
CDN מאפשרים שמירה של תוכן במטמון של שרתי קצה שנמצאים פיזית קרוב יותר למבקרים, בתנאי שהתוכן מוגדר עם כותרות HTTP Cache-Control מתאימות. אמנם שיטה זו לא מתאימה לתוכן מותאם אישית, אבל דרישה לנסוע כל הדרך בחזרה למקור עלולה לפגוע בהרבה מהערך של CDN.
באתרים שמעדכנים את התוכן שלהם לעיתים קרובות, גם זמן קצר לשמירה במטמון יכול להניב שיפור משמעותי בביצועים של אתרים עמוסים, כי רק המבקר הראשון בפרק זמן זה חווה את זמן האחזור המלא בחזרה לשרת המקור, ואילו שאר המבקרים יכולים להשתמש שוב במשאב ששמור במטמון משרת הקצה. סוגים מסוימים של CDN מאפשרים ביטול תוקף של מטמון בגרסאות אתרים, כך שאפשר ליהנות משני העולמות – זמני מטמון ארוכים, אבל עדכונים מיידיים במקרה הצורך.
גם אם השמירה במטמון מוגדרת בצורה נכונה, אפשר להתעלם מהתופעה הזו באמצעות פרמטרים ייחודיים למחרוזות שאילתה לצורך מדידה של ניתוח נתונים. קבצים אלה עשויים להיראות כמו תוכן שונה ב-CDN למרות שהם זהים, ולכן לא ייעשה שימוש בגרסת המטמון.
ייתכן גם שתוכן ישן יותר או פחות שביקרו בו לא יישמר במטמון. כתוצאה מכך, בדפים מסוימים יש ערכי TTFB גבוהים יותר מאשר בדפים אחרים. הארכת משך הזמן לשמירה במטמון עשויה לצמצם את ההשפעה, אבל חשוב לזכור שככל שזמן השמירה במטמון ארוך יותר, כך גובר הסיכוי להצגת תוכן שעשוי להיות מיושן.
ההשפעה של תוכן שנשמר במטמון לא משפיעה רק על אלה שמשתמשים ב-CDN. במקרים שבהם לא ניתן לעשות שימוש חוזר בתוכן שנשמר במטמון, יכול להיות שתשתית השרת תצטרך ליצור תוכן מחיפושים יקרים של מסדי נתונים. לרוב, הביצועים של נתונים שניגשים אליהם לעיתים קרובות או דפים שנשמרו מראש יהיו טובים יותר.
יש להימנע מהפניות אוטומטיות מרובות
אחד הגורמים הנפוצים ל-TTFB גבוה הוא הפניות אוטומטיות. הפניות אוטומטיות מתרחשות כשבקשת ניווט למסמך מקבלת תגובה שמודיעה לדפדפן שהמשאב קיים במיקום אחר. הפניה אוטומטית אחת בהחלט יכולה להוסיף זמן אחזור לא רצוי לבקשת ניווט, אבל היא בהחלט יכולה להחמיר אם ההפניה האוטומטית מפנה למשאב אחר שמובילה להפניה אחרת — וכן הלאה. התופעה הזו יכולה להשפיע במיוחד על אתרים שמקבלים נפח גבוה של מבקרים מפרסומות או מניוזלטרים, מפני שבמקרים רבים הם מפנים אוטומטית דרך שירותי ניתוח נתונים למטרות מדידה. ביטול הפניות אוטומטיות שנמצא בשליטתכם הישירה יכול לעזור לכם להשיג TTFB טוב.
קיימים שני סוגים של הפניות אוטומטיות:
- הפניות אוטומטיות מאותו מקור, שבהן ההפניה האוטומטית מתרחשת רק באתר שלכם.
- הפניות ממקורות שונים, שבהן ההפניה האוטומטית מתרחשת בהתחלה של מקור אחר – למשל, משירות קיצור של כתובות URL של רשת חברתית – לפני שמגיעים לאתר שלכם.
עליך להתמקד בביטול הפניות מחדש מאותו מקור, מכיוון שזה משהו שתהיה לך שליטה ישירה עליו. לשם כך, יש לבדוק את הקישורים באתר כדי לראות אם הם מובילים לקוד תגובה מסוג 302 או 301. פעמים רבות הסיבה לכך עשויה להיות אי-הכללה של הסכמה https:// (לכן הדפדפנים מוגדרים כברירת מחדל ל-http://, שמפנה לכתובת אתר אחרת) או שקו נטוי בסוף לא נכלל או לא נכלל בכתובת ה-URL כראוי.
הפניות ממקורות שונים חשובים יותר כי הן בדרך כלל לא בשליטתכם. עם זאת, כדאי להימנע ככל האפשר מהפניות אוטומטיות מרובות, לדוגמה, על ידי שימוש במספר מקצרי קישורים בעת שיתוף קישורים. ודאו שכתובת ה-URL שסיפקתם למפרסמים או לניוזלטרים היא כתובת ה-URL הסופית הנכונה, כדי לא להוסיף עוד הפניות לכתובות אחרות שבהן נעשה שימוש בשירותים האלה.
מקור חשוב נוסף לזמן ההפניה יכול להגיע מהפניות אוטומטיות מסוג HTTP ל-HTTPS. דרך אחת לעקוף את הבעיה היא להשתמש בכותרת Strict-Transport-Security (HSTS). הכותרת הזו אוכפת HTTPS בביקור הראשון במקור, ואז מורה לדפדפן לגשת מיד למקור דרך סכמת HTTPS בביקורים עתידיים.
אחרי שמגדירים מדיניות HSTS טובה, אפשר לזרז את התהליך בביקור הראשון במקור. לשם כך, צריך להוסיף את האתר לרשימת הטעינה מראש של HSTS.
העברת תגי עיצוב לדפדפן
דפדפנים עוברים אופטימיזציה כדי לעבד סימון ביעילות כאשר הוא מועבר בסטרימינג. כלומר, תגי העיצוב מטופלים במקטעים כשהם מגיעים מהשרת. הדבר חיוני למקרים של מטענים ייעודיים (payloads) גדולים של תגי עיצוב. המשמעות היא שהדפדפן יכול לנתח את מקטעי תגי העיצוב בהדרגה, במקום להמתין עד שכל התגובה תגיע לפני שהניתוח יתחיל.
אף על פי שדפדפנים הם כלי מעולה לטיפול בתגי עיצוב בסטרימינג, חשוב מאוד לעשות את כל מה שאפשר כדי שהסטרימינג ימשיך לזרום, כך שתגי העיצוב הראשוניים האלה ישלחו אותם בהקדם האפשרי. אם הקצה העורפי מחזיק דברים, זו בעיה. מכיוון שיש הרבה ערימות קצה עורפי, המדריך הזה לא יכול לכלול מידע על כל מקבץ ועל הבעיות שעשויות לצוץ בכל אחת.
לדוגמה, פלטפורמות אחרות שיכולות לעבד תגי עיצוב על פי דרישה בשרת – השתמשו בגישה סינכרונית לעיבוד בצד השרת. עם זאת, בגרסאות חדשות יותר של React הטמיעו שיטות שרת לתגי עיצוב לסטרימינג בזמן העיבוד. כלומר, אין צורך להמתין עד ששיטת React Server API תעבד את התגובה במלואה לפני שהיא תישלח.
דרך נוספת להבטיח שתגי העיצוב יועברו בסטרימינג במהירות לדפדפן, היא להשתמש ברינדור סטטי שיוצר קובצי HTML במהלך ה-build. כאשר הקובץ המלא זמין באופן מיידי, שרתי אינטרנט יכולים להתחיל לשלוח את הקובץ באופן מיידי, והאופי הפנימי של HTTP יגרום לתגי עיצוב של סטרימינג. גישה זו לא מתאימה לכל דף בכל אתר — למשל, כזו שדורשת תגובה דינמית כחלק מחוויית המשתמש. היא יכולה להועיל לדפים שבהם אין צורך בהתאמה אישית של תגי עיצוב למשתמש מסוים.
שימוש בקובץ שירות (service worker)
ל-Service Worker API יכולה להיות השפעה משמעותית על ה-TTFB גם במסמכים וגם במשאבים שהם טוענים. הסיבה לכך היא שה-Service Worker פועל כשרת proxy בין הדפדפן לשרת - אבל ההשפעה על ה-TTDFB של האתר תלויה באופן שבו מגדירים את ה-Service Worker ובתנאי ההגדרה הזו תואמת לדרישות האפליקציה שלכם.
- משתמשים באסטרטגיה של 'לא פעיל בזמן אימות מחדש' לנכסים. אם נכס נמצא במטמון של קובץ השירות (service worker) – בין אם מדובר במסמך או במשאב שנדרש למסמך – האסטרטגיה 'לא פעיל בזמן אימות מחדש' תטפל במשאב הזה מהמטמון תחילה, ואז תוריד את הנכס הזה ברקע ותציג אותו מהמטמון לאינטראקציות עתידיות.
- אם יש לכם משאבי מסמכים שלא משתנים לעיתים קרובות, השימוש באסטרטגיית אימות מחדש לא פעיל עשוי להפוך את ה-TTDFB של דף לכמעט מיידי. עם זאת, אפשרות זו לא תהיה יעילה כל כך אם האתר שלך שולח סימון שנוצר באופן דינמי, כגון סימון שמשתנה בהתאם לאימות המשתמש. במקרים כאלה, תמיד כדאי להגיע לרשת קודם, כך שהמסמך יהיה עדכני ככל האפשר.
- אם במסמך שלכם נטען משאבים לא קריטיים שמשתנים בתדירות מסוימת, אבל אחזור המשאב המיושן לא ישפיע במידה רבה על חוויית המשתמש, כמו למשל תמונות נבחרות או משאבים אחרים שאינם קריטיים – ניתן לצמצם משמעותית את יעד ה-TTDFB של המשאבים האלה באמצעות אסטרטגיה של חוסר פעילות בזמן אימות מחדש.
- אם אפשר, כדאי להשתמש בארכיטקטורת קובץ שירות (service worker) של סטרימינג. הארכיטקטורה של קובץ השירות (service worker) מבוססת על גישה שבה חלקים ממשאב מסמך מאוחסנים במטמון של ה-Service Worker, ומשולבים עם חלקי תוכן במהלך בקשת הניווט. התוצאה של שימוש בדפוס Service Worker זה היא שהניווט יהיה מהיר למדי, בעוד שמטענים ייעודיים (payloads) קטנים יותר של HTML יורדים מהרשת. דפוס זה של קובץ שירות (service worker) לא פועל בכל אתר, אבל זמני TTFB למשאבי מסמכים יכולים להיות כמעט מיידיים באתרים שיכולים להשתמש בו.
- שימוש במודל מעטפת האפליקציה לאפליקציות בעיבוד לקוח. המודל הזה מתאים בצורה הטובה ביותר ל-SPA, שבהם ניתן לשלוח את "המעטפת" של הדף באופן מיידי מהמטמון של ה-Service Worker, והתוכן הדינמי של הדף מאוכלס ומעובד בשלב מאוחר יותר במחזור החיים של הדף.
שימוש ב-103 Early Hints למשאבים קריטיים לעיבוד
גם אם הקצה העורפי של האפליקציה עבר אופטימיזציה, עדיין תיתכן עבודה רבה בשרת כדי להכין תגובה, כולל עבודה יקרה (שעדיין נדרשת) במסד הנתונים, שמעכבת את ההגעה של תגובת הניווט במהירות האפשרית. ההשפעה האפשרית של מצב זה היא שיתעכבו חלק מהמשאבים הקריטיים לעיבוד נתונים עתידיים, כגון CSS, או במקרים מסוימים - JavaScript אשר מעבד תגי עיצוב בלקוח.
הכותרת 103 Early Hints היא קוד תגובה מוקדם שהשרת יכול לשלוח לדפדפן בזמן שהקצה העורפי עסוק בהכנת תגי העיצוב. ניתן להשתמש בכותרת זו כדי לרמוז לדפדפן שיש משאבים קריטיים לעיבוד הדף צריך להתחיל להוריד במהלך הכנת תגי העיצוב. בדפדפנים תומכים, התוצאה יכולה להיות עיבוד מסמכים מהיר יותר (CSS) וזמינות מהירה יותר של הפונקציונליות העיקרית של הדף (JavaScript).
סיכום
יש כל כך הרבה שילובים של מקבצים של אפליקציות לקצה העורפי, ולכן אין מאמר אחד שיכול לכלול מידע על כל מה שאפשר לעשות כדי לשפר את יכולת השימוש ב-TTFB באתר שלכם. עם זאת, אלה כמה אפשרויות שתוכלו לבדוק כדי לנסות לעבוד קצת יותר מהר בצד של השרת.
כמו באופטימיזציה של כל מדד, הגישה דומה במידה רבה: עליכם למדוד את ה-TFCB בשטח, להשתמש בכלים של שיעור ה-Lab כדי להציג פירוט של הסיבות, ולאחר מכן לבצע אופטימיזציה כשהדבר אפשרי. לא כל השיטות המומלצות כאן יתאימו לכם, אבל חלקן כן. כמו תמיד, תצטרכו לעקוב מקרוב אחר נתוני השדות ולבצע שינויים לפי הצורך כדי להבטיח חוויית משתמש מהירה ככל האפשר.
תמונה ראשית (Hero) של טיילור ויק, שמקורה ב-UnFlood.