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

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

Kenji Baheux

Barry Pollard

מהם רמזים מוקדמים?

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

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

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

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

במקרים מסוימים, שיפור הביצועים של Largest Contentful Paint יכול לנוע בין כמה מאות אלפיות השנייה, כפי שציינו ב-Shopify וב-Cloudflare, ועד שנייה אחת מהר יותר, כפי שרואים בהשוואה הזו לפני ואחרי:

השוואה בין נתונים לפני ואחרי שימוש ב-Early Hints באתר בדיקה שנערך באמצעות WebPageTest‏ (Moto G4 – DSL)

איך משתמשים ב-Early Hints

הערה: לפני שמתעמקים בנושא, חשוב לשים לב שרמזים מוקדמים לא שימושיים אם השרת יכול לשלוח מיד 200 (או תשובות סופיות אחרות). במקום זאת, מומלץ להשתמש ב-preload או ב-preconnect הרגילים בתגובה הראשית (באמצעות כותרת ה-HTTP Link), או בתגובה הראשית (באמצעות רכיבי <link>). במקרים שבהם השרת צריך קצת זמן כדי ליצור את התשובה הראשית, כדאי להמשיך לקרוא.

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

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

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

כשמשתמשים בהם ב-HTML, בדרך כלל רוצים preconnect או preload משאבים שסורק ההטענה מראש לא יזהה ב-HTML – לדוגמה, גופנים או תמונות רקע, שבמקרה אחר יימצאו מאוחר יותר. ב-Early Hints, לא יהיה לכם HTML, לכן מומלץ במקום זאת להשתמש ב-preconnect לדומיינים קריטיים או ב-preload למשאבים קריטיים שיכול להיות שיימצאו מוקדם יותר ב-HTML – לדוגמה, טעינת main.css או app.js מראש. בנוסף, לא כל הדפדפנים תומכים ב-preload ל-Early Hints – ראו תמיכה בדפדפנים.

נקודה חשובה: מה שתחליטו לגבי preconnect או preload כ'רמזים מוקדמים' עשוי להיות שונה מהמשאבים בדרך כלל שחיברתם מראש או טענתם מראש ב-HTML.

השלב השני כולל צמצום הסיכון לשימוש ב-Early Hints במשאבים או במקורות שעשויים להיות מיושנים או שהמשאב הראשי לא משתמש בהם יותר. לדוגמה, יכול להיות שמשאבים שמתעדכנים לעיתים קרובות ויש להם גרסאות (למשל, example.com/css/main.fa231e9c.css) הם לא הבחירה הטובה ביותר. חשוב לזכור שהבעיה הזו לא ספציפית ל-Early Hints, אלא חלה על כל preload או preconnect בכל מקום שבו הם עשויים להופיע. זהו סוג הפרטים שהכי קל לטפל בהם באמצעות אוטומציה או תבניות (לדוגמה, תהליך ידני עלול להוביל לכתובות URL של גרסאות או גיבוב לא תואמות בין preload לבין תג ה-HTML בפועל שמשתמש במשאב).

לדוגמה, נניח את התהליך הבא:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

השרת צופה שיהיה צורך ב-main.abcd100.css ומציע לטעון אותו מראש באמצעות הנחיות מוקדמות:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

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

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

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

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

לבסוף, בצד השרת, מחפשים בקשות של משאבים ראשיים שנשלחות מדפדפנים שידועים כתומכים ב-Early Hints, ומגיבים מיד עם 103 Early Hints. בתגובה 103, צריך לכלול את ההנחיות הרלוונטיות להתחברות מראש ולטעינה מראש. כשהמשאב הראשי יהיה מוכן, יש להמשיך עם התגובה הרגילה (לדוגמה, 200 OK אם הפעולה בוצעה בהצלחה). כדי לשמור על תאימות לאחור, מומלץ לכלול גם כותרות HTTP מסוג Link בתגובה הסופית, ואולי אפילו להוסיף משאבים קריטיים שהתגלו במהלך יצירת המשאב הראשי (לדוגמה, החלק הדינמי של משאב מפתח אם פעלתם לפי ההצעה 'פיצול לשניים'). כך זה נראה:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

כמה רגעים לאחר מכן:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

תמיכה בדפדפנים

אמנם יש תמיכה בהנחיות מוקדמות בגרסה 103 בכל הדפדפנים העיקריים, אבל ההנחיות שאפשר לשלוח בהנחיה מוקדמת משתנות בהתאם לדפדפן:

תמיכה בחיבור מראש:

תמיכה בדפדפנים

• 103
• 103
• 120
• 17

תמיכה בחיוב מראש:

תמיכה בדפדפנים

• 103
• 103
• 123
• x

ב-Chrome DevTools יש גם תמיכה ב-103 הנחיות מוקדמות, ואפשר לראות את הכותרות Link במשאבי המסמך:

הכותרות Link של הרמזים המוקדמים מוצגות בכלי הפיתוח ל-Chrome.

הערה: כדי להשתמש במשאבים של רמזים מוקדמים, אין לסמן את Disable cache בכלי הפיתוח כי 'רמזים מוקדמים' משתמשים במטמון של הדפדפן. במשאבים שהועלו מראש, הגורם המפעיל יופיע כ-early-hints והגודל יופיע כ-(Disk cache):

למשאבים עם רמזים מוקדמים יש early-hints מפעיל והם נטענים מהמטמון בדיסק.

לשם כך נדרש גם אישור מהימן לבדיקות HTTPS.

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

תמיכה לשרתים

ריכזנו כאן סיכום קצר של רמת התמיכה ב-Early Hints בתוכנות פופולריות של שרתי HTTP בקוד פתוח:

• Apache: יש תמיכה באמצעות mod_http2.
• H2O: נתמך.
• NGINX: מודול ניסיוני.
• Node: יש תמיכה מאז גרסה 18.11.0 ב-http וב-http2

הפעלת הנחיות מוקדמות בדרך הקלה

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

• טיפים מוקדמים לשימוש בשירות של Cloudflare
• Early Hints ב-Fastly.
• Early Hints ב-Akamai

איך למנוע בעיות עבור לקוחות שלא תומכים ברמזים מוקדמים

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

פליטת 103 רמזים מוקדמים בתגובה ללקוחות ששולחים כותרת בקשת HTTP sec-fetch-mode: navigate צריכה לוודא שהרמזים האלה יישלחו רק עבור לקוחות חדשים יותר שמבינים להמתין לתגובה הבאה. בנוסף, מכיוון שיש תמיכה ברמזים מוקדמים רק בבקשות ניווט (כמפורט במגבלות הנוכחיות), יש יתרון נוסף – הימנעות משליחה לא נחוצה של בקשות כאלה לגבי בקשות אחרות.

בנוסף, מומלץ לשלוח את ההצעות המוקדמות רק דרך חיבורי HTTP/2 או HTTP/3, ורוב הדפדפנים יקבלו אותן רק דרך הפרוטוקולים האלה.

דפוס מתקדם

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

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

המגבלות הנוכחיות

ריכזנו כאן את המגבלות של הנחיות מוקדמות כפי שהן מוטמעות ב-Chrome:

• זמין רק לבקשות ניווט (כלומר, המשאב הראשי של המסמך ברמה העליונה).
• יש תמיכה רק ב-preconnect וב-preload (כלומר, אין תמיכה ב-prefetch).
• רמזים מוקדמים ואחריהם הפניה אוטומטית ממקורות שונים בתגובה הסופית יגרמו ל-Chrome להשמיט את המשאבים והחיבורים שהוא השיג באמצעות רמזים מוקדמים.
• משאבים שנטענים מראש באמצעות רמזים מוקדמים מאוחסנים במטמון ה-HTTP ומאוחזרים משם על ידי הדף מאוחר יותר. לכן, אפשר לטעון מראש רק משאבים שאפשר לשמור במטמון באמצעות הנחיות מוקדמות, אחרת המשאב ייאוחזר פעמיים (פעם אחת על ידי ההנחיות המוקדמות ופעם נוספת על ידי המסמך). ב-Chrome, מטמון ה-HTTP מושבת באישורי HTTPS לא מהימנים (גם אם אתם ממשיכים לטעון את הדף).
• אי אפשר לטעון מראש תמונות עם תגובה דינמית (באמצעות imagesrcset,‏ imagesizes או media) באמצעות כותרות HTTP מסוג <link>, כי אזור התצוגה לא מוגדר עד ליצירת המסמך. המשמעות היא שאי אפשר להשתמש ב-103 הנחיות מוקדמות כדי לטעון מראש תמונות רספונסיביות, וייתכן שהתמונה הלא נכונה תיטען אם משתמשים בהן למטרה הזו. כדאי לעיין בדיון הזה בנושא הצעות לטיפול טוב יותר בבעיה.

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

מה השלב הבא?

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

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

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

הקשר ל-H2/Push

אם אתם מכירים את התכונה HTTP2/Push שהוצאה משימוש, יכול להיות שתתהו מה ההבדל בין הטיפים המוקדמים לבין התכונה הזו. בעוד שב-Early Hints נדרש מסלול הלוך ושוב כדי שהדפדפן יתחיל לאחזר משאבי משנה קריטיים, ב-HTTP2/Push השרת יכול להתחיל לדחוף משאבי משנה לצד התגובה. זה נשמע נהדר, אבל לכך הייתה השפעה שלילית מבחינה מבנית: ב-HTTP2/Push היה קשה מאוד להימנע משליחת משאבי משנה שכבר היו בדפדפן. אפקט "דחיפת-היתר" הזה הוביל לשימוש פחות יעיל ברוחב הפס של הרשת, מה שגרם לפגיעה משמעותית בביצועים. באופן כללי, הנתונים מ-Chrome הראו ש-HTTP2/Push גרם למעשה לירידה נטו בביצועים ברחבי האינטרנט.

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

התמונה הממוזערת היא של Pierre Bamin.