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

איך מבצעים אופטימיזציה לפי המדד 'זמן לקבלת הבאיט הראשון'

Jeremy Wagner

Barry Pollard

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

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

איך מודדים את זמן אחזור ה-TTFB

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

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

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

קבוצת משנה של TTFB מוצגת בבדיקת זמן התגובה של השרת:

בדף המדד 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 - $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 יוצגו באופן חזותי בחלונית הזמנים בכרטיסייה רשת בכלי הפיתוח ל-Chrome:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספקי 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 שדומה ל-Service Worker API כדי ליירט בקשות, לנהל תשובות באופן פרוגרמטי במטמון קצה או לשכתב תשובות לגמרי.
• ספקי CDN מבצעים אופטימיזציה מצוינת לדחיסה. קשה מאוד לבצע דחיסה בצורה נכונה בעצמכם, והיא עלולה להוביל לזמני תגובה איטיים יותר במקרים מסוימים עם סימון שנוצר באופן דינמי, שצריך לדחוס בזמן אמת.
• ספקי ה-CDN גם יאחסנו באופן אוטומטי בתגובה דחוסה למשאבים סטטיים, וכך יוצרים את השילוב הטוב ביותר של יחס דחיסה וזמן תגובה.

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

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

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

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

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

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

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

הימנעות מהפניות לכמה דפים

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

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

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

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

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

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

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

העברת ה-Markup לדפדפן

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

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

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

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

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

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

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

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

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

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

סיכום

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

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

התמונה הראשית (Hero) היא של Taylor Vick, מ-Unsplash.