עיבוד מראש של דפים ב-Chrome לניווט מיידי בדפים

Barry Pollard

תמיכה בדפדפן

  • 109
  • 109
  • x
  • x

צוות Chrome עבד על אפשרויות כדי להחזיר את העיבוד מראש המלא לדפים עתידיים שסביר להניח שהמשתמשים ינווטו אליהם.

היסטוריה קצרה של העיבוד מראש

בעבר, Chrome תמך ברמז למשאב <link rel="prerender" href="/next-page">, אבל לא הייתה תמיכה רחבה בו מעבר ל-Chrome ולא היה ממשק API מאוד אקספרסיבי.

העיבוד מראש הזה מדור קודם באמצעות הקישור rel=prerender, הוצא משימוש לטובת NoState Prefetch, שבמקום זאת איחזר את המשאבים הנדרשים לדף העתידי, אבל לא ביצע עיבוד מראש מלא של הדף או הפעיל JavaScript. שליפה מראש (prefetch) של NoState עוזרת לשפר את ביצועי הדף על ידי שיפור טעינת המשאבים, אבל היא לא מספקת טעינת דף מיידית כמו שעיבוד מראש מלא היה עושה.

צוות Chrome החזיר כעת עיבוד מראש מלא ל-Chrome. כדי למנוע סיבוכים עם השימוש הקיים וכדי לאפשר הרחבה עתידית של העיבוד מראש, המנגנון החדש לעיבוד מראש לא ישתמש בתחביר <link rel="prerender"...>, שכבר קיים בשליפה מראש מסוג NoState, עם הכוונה להפסיק את השימוש בשלב כלשהו בעתיד.

איך מתבצע עיבוד מראש של דף?

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

  1. כאשר תקליד כתובת אתר בסרגל הכתובות של Chrome (שנקרא גם 'סרגל הכתובות'), Chrome עשוי לעבד מראש באופן אוטומטי את הדף עבורך, אם יש לו מידת ודאות גבוהה שתבקר בדף זה.
  2. כשמקלידים מונח חיפוש בסרגל הכתובות של Chrome, Chrome עשוי לעבד מראש באופן אוטומטי את דף תוצאות החיפוש, כאשר מנוע החיפוש מורה לעשות זאת.
  3. אתרים יכולים להשתמש ב-Speculation Rules API כדי להורות ל-Chrome אילו דפים לבצע עיבוד מראש. הפעולה הזו מחליפה את הפעולות ש-<link rel="prerender"...> ביצעה ומאפשרת לאתרים לעבד מראש דף מסוים באופן יזום על סמך כללי הטעינות מראש בדף. הם יכולים להתקיים באופן סטטי בדפים או להיות מוחדרים באופן דינמי על ידי JavaScript לפי הצורך של בעל הדף.

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

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

ההשפעה של העיבוד מראש

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

דוגמה להשפעה של עיבוד מראש.

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

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

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

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

הצגת החיזויים בסרגל הכתובות של Chrome

בתרחיש לדוגמה הראשון, אפשר להציג את החיזויים של Chrome לגבי כתובות URL בדף chrome://predictors:

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

קווים ירוקים מציינים מספיק ביטחון כדי להפעיל עיבוד מראש. בדוגמה הזו, הקלדת "s" נותנת תחושת ביטחון סבירה (אפור), אבל לאחר שמקלידים "sh", Chrome מקבל מספיק ביטחון כך שאתם כמעט תמיד מנווטים אל https://sheets.google.com.

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

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

צילום מסך של תכונת Typeahead בסרגל הכתובות
התכונה 'Typeahead' בסרגל הכתובות

Chrome יעדכן את החיזויים שלו באופן קבוע בהתאם להקלדה ולבחירות שלכם.

  • לרמת סמך של יותר מ-50% (מוצגת בצבע ענבר), Chrome מתחבר מראש לדומיין באופן יזום, אבל לא מבצע עיבוד מראש של הדף.
  • לרמת סמך של יותר מ-80% (מוצג בירוק), Chrome יעבד מראש את כתובת ה-URL.

ממשק ה-API של כללי ספקולציות

באפשרות השלישית של עיבוד מראש, מפתחי אתרים יכולים להוסיף הוראות JSON לדפים שלהם כדי ליידע את הדפדפן באילו כתובות URL לבצע עיבוד מראש:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

לחלופין, לפי כללי המסמך (זמינים מ-Chrome 121), שמעבדים מראש קישורים שנמצאו במסמך על סמך href או סלקטורים ב-CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

להיטות

תמיכה בדפדפן

  • 121
  • 121
  • x
  • x

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

  • immediate: משמש לביצוע השערות בהקדם האפשרי, כלומר, ברגע שמתקיימים כללי הטעינות מראש.
  • eager: הפעולה הזו זהה להגדרה של immediate, אבל בעתיד אנחנו מתכוונים למקם אותה במקום כלשהו בין immediate ל-moderate.
  • moderate: הפעולה הזו מבצעת השערות אם מעבירים את העכבר מעל קישור במשך 200 אלפיות השנייה (או באירוע pointerdown אם הוא מוקדם יותר, ובנייד שבו אין אירוע hover).
  • conservative: מתבצעת השערה לגבי הסמן או נגיעה למטה.

ערך ברירת המחדל של eagerness עבור כללי list הוא immediate. ניתן להשתמש באפשרויות moderate ו-conservative כדי להגביל את הכללים של list לכתובות URL שהמשתמש יוצר איתן אינטראקציה לרשימה ספציפית. עם זאת, במקרים רבים, כללים של document עם תנאי where מתאים עשויים להתאים יותר.

ערך ברירת המחדל של eagerness עבור כללי document הוא conservative. מכיוון שמסמך יכול לכלול כתובות URL רבות, יש להפעיל שיקול דעת בעת השימוש ב-immediate או ב-eager עבור כללי document (מידע נוסף מפורט גם בקטע המגבלות ב-Chrome).

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

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

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

שליפה מראש (prefetch)

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

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

המגבלות ב-Chrome

ב-Chrome יש מגבלות כדי למנוע שימוש יתר ב-Speculation Rules API:

להיטות שליפה מראש (prefetch) עיבוד מראש
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
מגבלות ספקולציות ב-Chrome.

ההגדרות של moderate ו-conservative, שתלויות באינטראקציה של המשתמשים, פועלות בצורת FIFO: 'נכנס ראשון ויוצא' (FIFO): אחרי הגעה למגבלה, ספקולציה חדשה תגרום לביטול הספקולציה הישנה ביותר והחלפתה בהגדרה החדשה יותר, על מנת לחסוך בזיכרון. ניתן להפעיל שוב ספקולציה שבוטלה – לדוגמה, העברת העכבר מעל הקישור הזה תגרום לחישוב מחדש של כתובת ה-URL הזו, וכתוצאה מכך תידל את ההשערה הישנה ביותר. במקרה כזה, הטעינות הקודמות יישמרו במטמון של ה-HTTP מטמון את כל המשאבים הניתנים לשמירה במטמון של כתובת ה-URL הזו. לכן, העלאת שאלות למועד נוסף אמורה להיות נמוכה יותר. לכן המגבלה מוגדרת לסף הצנוע של 2. כללים לרשימות סטטיות לא מופעלים על ידי פעולת המשתמש ולכן יש להם מגבלה גבוהה יותר כי הדפדפן לא יכול לדעת אילו נדרשים ומתי הם נחוצים.

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

Chrome גם ימנע שימוש בספקולציות בתנאים מסוימים, כולל:

  • שמור נתונים.
  • חיסכון באנרגיה כשהסוללה פועלת וכשהסוללה חלשה.
  • מגבלות זיכרון.
  • כשההגדרה 'טעינה מראש של דפים' מושבתת (והיא גם מושבתת במפורש על ידי תוספי Chrome כמו uBlock Origin).
  • דפים שנפתחו בכרטיסיות ברקע.

עד להפעלה, Chrome גם לא מעבד iframes ממקורות שונים בדפים שעברו עיבוד מראש.

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

איך לכלול כללי ספקולציות בדף

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

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

אם אתם מעדיפים הוספה דינמית, על סמך פעולות כמו העברת העכבר מעל קישור או לחיצה עליו למטה – כפי שספריות רבות עשו בעבר עם <link rel=prefetch> – מומלץ לבדוק כללי מסמכים, כי הם מאפשרים לדפדפן לטפל בתרחישי שימוש רבים.

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

כותרת ה-HTTP Speculation-Rules

תמיכה בדפדפן

  • 121
  • 121
  • x
  • x

מקור

ניתן לספק כללי ספקולציות גם באמצעות כותרת HTTP מסוג Speculation-Rules, במקום לכלול אותם ישירות ב-HTML של המסמך. הדבר מאפשר פריסה קלה יותר על ידי CDNs ללא צורך לשנות את תוכן המסמכים עצמם.

כותרת ה-HTTP Speculation-Rules מוחזרת עם המסמך ומפנה למיקום של קובץ JSON שמכיל את כללי הטעינות מראש:

Speculation-Rules: "/speculationrules.json"

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

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

אם אתם רוצים להשתמש בכתובות URL יחסיות, מומלץ לכלול את המפתח "relative_to": "document" בכללי הטעינות מראש. אחרת, כתובות URL יחסיות יהיו יחסיות לכתובת ה-URL של קובץ ה-JSON של כללי הטעינות מראש. האפשרות הזו יכולה להיות שימושית במיוחד אם אתם צריכים לבחור קישורים מאותו מקור, או חלק מהם.

כללי ספקולציות ו-SPA

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

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

כללי ספקולציות לניפוי באגים

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

כללי ספקולציות מרובים

אפשר להוסיף לאותו הדף גם כמה כללי ספקולציות, והם יצורפו לכללים הקיימים. לכן, כל הדרכים השונות הבאות יובילו לעיבוד מראש של one.html וגם של two.html:

רשימה של כתובות URL:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

ריבוי speculationrules:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

מספר רשימות בתוך קבוצה אחת של speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

תמיכה בדפדפן

  • 121
  • 121
  • x
  • x

מקור

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

לדוגמה, פרמטרים של מנטר התנועה של Urchin משמשים את Google Analytics למדידת קמפיינים, אבל בדרך כלל הם לא גורמים להעברה של דפים שונים מהשרת. המשמעות היא ש-page1.html?utm_content=123 ו-page1.html?utm_content=456 יציגו את אותו הדף מהשרת, כך שניתן יהיה לעשות שימוש חוזר באותו דף מהמטמון.

באופן דומה, אפליקציות יכולות להשתמש בפרמטרים אחרים של כתובת אתר שמטופלות רק בצד הלקוח.

ההצעה No-Vary-Search מאפשרת לשרת לציין פרמטרים שלא מובילים לשינוי במשאב שמועבר, וכך לאפשר לדפדפן לעשות שימוש חוזר בגרסאות קודמות של מסמך שההבדל היחיד ביניהם הוא הפרמטרים האלה. האפשרות הזו נתמכת ב-Chrome (ובדפדפנים המבוססים על Chromium) רק לצורך השערות ניווט בשליפה מראש (prefetch).

כללי הטעינות מראש תומכים בשימוש ב-expects_no_vary_search כדי לציין את המקום שבו יש להחזיר כותרת HTTP מסוג No-Vary-Search. כך תוכלו למנוע הורדות מיותרות.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

בדוגמה הזו, קוד ה-HTML של הדף הראשוני /products זהה בשני מזהי המוצרים 123 ו-124. עם זאת, תוכן הדף משתנה בסופו של דבר על סמך רינדור בצד הלקוח באמצעות JavaScript, כדי לאחזר נתוני מוצרים באמצעות פרמטר החיפוש id. לכן, אנחנו מאחזרים מראש את כתובת ה-URL באופן דחוף, והיא אמורה להחזיר כותרת HTTP מסוג No-Vary-Search שמראה שהדף יכול לשמש לכל פרמטר חיפוש id.

עם זאת, אם המשתמש לוחץ על אחד מהקישורים לפני שהשליפה מראש הושלמה, יכול להיות שהדפדפן לא קיבל את הדף /products. במקרה כזה, הדפדפן לא יודע אם הוא יכיל את כותרת ה-HTTP No-Vary-Search. לאחר מכן הדפדפן יכול לבחור אם לאחזר את הקישור שוב, או להמתין לסיום השליפה מראש כדי לראות אם הוא מכיל כותרת HTTP מסוג No-Vary-Search. ההגדרה expects_no_vary_search מאפשרת לדפדפן לדעת שהתגובה של הדף צפויה להכיל כותרת HTTP מסוג No-Vary-Search, ולהמתין שהשליפה מראש (prefetch) תושלם.

הגבלות על כללי ספקולציות ושיפורים עתידיים

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

עיבוד מראש של דפים ממקורות שונים באותו אתר (לדוגמה, https://a.example.com יכול לבצע עיבוד מראש של דף ב-https://b.example.com). כדי להשתמש באפשרות הזו, הדף שעבר עיבוד מראש (https://b.example.com בדוגמה הזו) צריך להביע הסכמה על ידי הכללת כותרת HTTP Supports-Loading-Mode: credentialed-prerender, או ש-Chrome יבטל את העיבוד מראש.

גרסאות עתידיות עשויות גם לאפשר עיבוד מראש לדפים ממקורות שונים (שבהם האתר מביע הסכמה עם כותרת HTTP דומה של Supports-Loading-Mode: uncredentialed-prerender), ולהפעיל עיבוד מראש בכרטיסיות חדשות.

זיהוי תמיכה ב-API של כללי ספקולציות

אפשר להשתמש בבדיקות HTML רגילות כדי לזהות תמיכה ב-Speculation Rules API:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

הוספה דינמית של כללי ספקולציות באמצעות JavaScript

דוגמה להוספת כלל ספקולציות prerender באמצעות JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

בדף ההדגמה של העיבוד מראש אפשר לראות הדגמה של העיבוד מראש ב-Speculation Rules API באמצעות הכנסת JavaScript.

ביטול כללי הטעינות מראש

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

כללי ספקולציות ומדיניות אבטחת תוכן

מכיוון שכללי הטעינות מראש משתמשים ברכיב <script>, על אף שהם מכילים רק JSON, הם צריכים להיכלל ב-script-src Content-Security-Policy אם האתר משתמש באלמנט הזה – באמצעות גיבוב או צופן חד-פעמי (nonce).

ניתן להוסיף רכיב inline-speculation-rules חדש אל script-src, וכך לתמוך ברכיבי <script type="speculationrules"> שהוחדרו מ-hash או מסקריפטים ללא ערך. האפשרות הזו לא תומכת בכללים הכלולים ב-HTML הראשוני, ולכן יש להזריק את הכללים על ידי JavaScript עבור אתרים שמשתמשים ב-CSP מחמיר.

זיהוי והשבתה של עיבוד מראש

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

עם זאת, יכולים להיות מקרים שבהם לא תרצו שעיבוד מראש יתבצע, למשל כשמצב הדפים ישתנה בהתאם לבקשה הראשונית או בהתאם ל-JavaScript שמופעל בדף.

הפעלה והשבתה של עיבוד מראש ב-Chrome

העיבוד מראש מופעל רק למשתמשי Chrome שהוגדרה להם ההגדרה 'טעינה מראש של דפים' ב-chrome://settings/performance/. בנוסף, העיבוד מראש מושבת גם במכשירים עם נפח זיכרון נמוך או אם מערכת ההפעלה נמצאת במצב 'חיסכון בנתונים' או 'חיסכון באנרגיה'. יש לעיין בקטע מגבלות ב-Chrome.

זיהוי והשבתה של עיבוד מראש בצד השרת

דפים שעברו עיבוד מראש יישלחו עם כותרת ה-HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

בדפים שנשלפו מראש באמצעות Speculation Rules API, הכותרת הזו תוגדר ל-prefetch בלבד:

Sec-Purpose: prefetch

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

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

זיהוי עיבוד מראש ב-JavaScript

ה-API של document.prerendering יחזיר true בזמן העיבוד מראש של הדף. דפים יכולים להשתמש בהגדרה הזו כדי למנוע, או להשהות, פעילויות מסוימות במהלך העיבוד מראש, עד שהדף יופעל בפועל.

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

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

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

הדרך הקלה ביותר לבדוק אם דף עבר עיבוד מראש (מלא או חלקי) היא לפתוח את כלי הפיתוח אחרי שהדף הופעל ולהקליד performance.getEntriesByType('navigation')[0].activationStart במסוף. אם מוחזר ערך שאינו אפס, סימן שהדף עבר עיבוד מראש:

מסוף בכלי הפיתוח ל-Chrome שבו מוצגת הפעלה חיובית התחלה שמציינת שהדף עבר עיבוד מראש
בדיקת עיבוד מראש במסוף.

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

באמצעות ממשקי ה-API האלה, JavaScript חזית יכול לזהות דפים שעברו עיבוד מראש ולפעול בהתאם כראוי.

ההשפעה על ניתוח נתונים

מערכת Analytics משמשת למדידת שימוש באתר, למשל שימוש ב-Google Analytics כדי למדוד אירועים וצפיות בדפים. לחלופין, על ידי מדידת מדדי ביצועים של דפים באמצעות Real User Monitoring (RUM).

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

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

אפשר להשיג את זה באמצעות שימוש ב-Promise שממתין לאירוע prerenderingchange אם מתבצע עיבוד מראש של מסמך, או שהעיבוד שלו מתבצע באופן מיידי אם המצב עכשיו:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

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

// Set up a promise for when the page is first made visible
const whenActivated = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

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

מדידת ביצועים

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

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

בגרסה 3.1.0, הספרייה web-vitals עודכנה כדי לטפל בניווטים שעברו עיבוד מראש באותו אופן שבו Chrome מודד את מדדי הליבה לבדיקת חוויית המשתמש באתר. הגרסה הזו מסמנת גם ניווטים שעברו עיבוד מראש למדדים האלה במאפיין Metric.navigationType, אם הדף עבר עיבוד מלא או חלקי.

מדידת עיבודים מראש

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

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

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

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

מדידת שיעורי ההיטים

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

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

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

לאחר מכן ניתן להעריך את 'שיעור ההיטים המוצלחים' על ידי בחינת ההבדל בין שני הנתונים. בדפים שבהם אתם משתמשים ב-Speculation Rules API כדי לבצע עיבוד מראש של דפים, תוכלו להתאים את הכללים בהתאם כדי לשמור על שיעור היטים גבוה כדי לשמור על איזון בין שימוש במשאבי המשתמשים כדי לעזור להם, לבין שימוש בהם ללא צורך.

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

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

ההשפעה על התוספים

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

משוב

העיבוד מראש נמצא בשלבי פיתוח פעילים על ידי הצוות של Chrome, ויש הרבה תוכניות להרחבת היקף האפשרויות שזמינות בגרסת Chrome 108. נשמח לקבל כל משוב על מאגר GitHub או להשתמש בכלי למעקב אחר בעיות, ונשמח לשמוע ולשתף מקרים לדוגמה של ה-API החדש והמרגש הזה.

אישורים

תמונה ממוזערת מאת Marc-Olivier Jodoin ב-UnFlood