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

Barry Pollard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

או באמצעות כללי מסמכים (זמינים מ-Chrome 121), שמעבדים מראש קישורים שנמצאו במסמך על סמך סלקטורים של href (מבוססים על URL Template API) או סלקטורים ב-CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

צוות Chrome הכין Codelab של כללי ספקולציות שידריך אתכם איך להוסיף כללי ספקולציות לאתר.

תשוקה

ההגדרה 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 שצריך להשתמש בה תלויה באתר שלכם. באתר סטטי וקליל, העלאת השערות באופן יסודי יותר עשויה להיות כרוכה בעלות נמוכה שתועיל למשתמשים. יכול להיות שאתרים עם ארכיטקטורות מורכבות יותר ומטענים ייעודיים (payload) של דפים כבדים יותר עשויים להעדיף פחות בזבוז על ידי העלאת השערות בתדירות נמוכה יותר, עד שתקבלו אות חיובי יותר לכוונת המשתמשים כדי להגביל את בזבוז.

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

<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:

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

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

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

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

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

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

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

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

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

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

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

כותרת ה-HTTP Speculation-Rules

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

כותרת ה-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 או חלקי, ולאחר מכן הם מעובדים ומוצגים בדף הנוכחי. הנתונים שנחוצים להפעלת הניווטים האלה יכולה להיות ניתנת לשליפה מראש (prefetch) על ידי האפליקציה מעבר לכללי ספקולציות, אבל אי אפשר לעבד אותם מראש.

אפשר להשתמש בכללי ספקולציות כדי לעבד מראש את האפליקציה עצמה מדף קודם. הפעולה הזו יכולה לקזז חלק מהעלויות הנוספות של טעינה ראשונית בחלק מה-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>

התמיכה של No-Vary-Search

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

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

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

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

כללי ספקולציות תומכים בשימוש ב-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. לאחר מכן, לדפדפן תהיה אפשרות לבחור אם לאחזר שוב את הקישור, או להמתין להשלמת השליפה מראש (prefetch) כדי לראות אם הוא מכיל כותרת 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 יבטל את ההשערה.

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

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

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

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

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

אין תמיכה בכללי ספקולציות לשליפה מראש של דפים שמנוהלים על ידי Service Workers. אנחנו פועלים להוספת התמיכה הזו. לקבלת עדכונים, מומלץ לעקוב אחר הבעיה של קובץ שירות התמיכה (service worker). יש תמיכה בעיבוד מראש בדפים שמנוהלים על ידי Service Worker.

זיהוי תמיכה ב-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 type = "speculationrules"> ישירות ל-DOM באמצעות innerHTML לא תרשום את כללי ההשערה מטעמי אבטחה, וצריך להוסיף את הרכיב הזה כמו קודם. עם זאת, תוכן שנוסף באופן דינמי באמצעות innerHTML שמכיל קישורים חדשים ייאספו בהתאם לכללים הקיימים בדף.

באופן דומה, עריכה ישירה של החלונית Elements בכלי הפיתוח ל-Chrome לצורך הוספת הרכיב <script type = "speculationrules"> לא רושמת את כללי ההשערה. במקום זאת, צריך להריץ את הסקריפט שיוסיף את ה-DOM באופן דינמי ל-DOM כדי להוסיף את הכללים. במקום זאת, צריך להריץ את הסקריפט שיוסיף את הכללים באופן דינמי.

הוספת כללי ספקולציות דרך Tag Manager

כדי להוסיף כללי ספקולציות באמצעות מנהל תגים כמו Google Tag Manager (GTM), צריך להוסיף אותם באמצעות JavaScript, ולא להוסיף את הרכיב <script type = "speculationrules"> דרך GTM ישירות מאותן הסיבות שצוינו קודם:

לתשומת ליבכם: בדוגמה הזו משתמשים ב-var כי GTM לא תומך ב-const.

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

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

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

כללי ספקולציות משתמשים ברכיב <script>, למרות שהם מכילים רק JSON, צריך לכלול אותם ב-Content-Security-Policy ב-script-src אם האתר משתמש בו – באמצעות גיבוב או צפנים.

אפשר להוסיף inline-speculation-rules חדש אל script-src וכך לקבל תמיכה ברכיבי <script type="speculationrules"> שהוחדרו מגיבוב או מסקריפטים לא מעובדים. פעולה זו אינה תומכת בכללים הכלולים ב-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), הדף לא יעבור עיבוד מראש וכל דף לשליפה מראש יימחק.

אם אתם לא רוצים שדף מסוים יעבור עיבוד מראש, זו הדרך הטובה ביותר להבטיח שהוא לא יקרה. עם זאת, כדי לספק את החוויה הטובה ביותר, מומלץ לאפשר עיבוד מראש במקום זאת, אבל לעכב פעולות שאמורות להתרחש רק כאשר הדף נצפה בפועל באמצעות 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 במסוף. אם מוחזר ערך שאינו אפס, אתם יודעים שהדף עבר עיבוד מראש:

כשהדף מופעל על ידי המשתמש שצופה בדף, האירוע 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 whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

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

השהיית תוכן אחר במהלך העיבוד מראש

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

לדוגמה, בהינתן הסקריפט הבא:

<script src="https://example.com/app/script.js" async></script>

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

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

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

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

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

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

כדי למדוד מדדי ביצועים, ניתוח הנתונים צריך לשקול אם עדיף למדוד אותם על סמך זמן ההפעלה ולא על סמך זמן הטעינה של הדף שעליו ידווחו ממשקי ה-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');

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

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

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

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

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

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

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

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

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

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

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

משוב

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

קישורים רלוונטיים

• Codelab של כללי ספקולציות
• כללי ספקולציות לניפוי באגים
• חדש: שליפה מראש ללא מצב (NoState)
• מפרט ספקולציות של Rules API
• מאגר GitHub של ספקולציות ניווט
• תוספים ל-Chrome: הרחבת ה-API לתמיכה בניווט מיידי

אישורים

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