דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התכונה Typeahead בסרגל הכתובות של Chrome — התכונה Typeahead בסרגל הכתובות.

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>

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

המגבלות ב-Chrome

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

נכונות	שליפה מראש (prefetch)	עיבוד מראש
`immediate` / `eager`	50	‏10
`moderate` / `conservative`	2 (FIFO)	2 (FIFO)

מגבלות הספק ב-Chrome.

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

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

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

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

הגדרת תג HTML בהתאמה אישית ב-Google Tag Manager — הוספת כללי ספקולציות דרך Google Tag Manager

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

מסוף בכלי הפיתוח ל-Chrome שמופיע בו הפעלה חיוביתStart (התחלה) כדי לציין שהדף עבר עיבוד מראש — בדיקת העיבוד מראש במסוף.

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

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

אזהרה: PerformanceNavigationTiming.type לא משתמש בערך prerender שהיה בשימוש עבור סוג הניווט הישן והמקורי יותר <link rel="prerender"...>. יכול להיות שזה ישתנה בעתיד, אבל נכון לעכשיו, לקוחות צריכים להשתמש ב-API document.prerendering כדי לזהות דפים בעיבוד מראש ושדה PerformanceNavigationTiming.activationStart שאינו אפס כדי לזהות דפים שעובדו מראש ושפעלו מאז.

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

מערכת 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 רוצים להוסיף עוד כלים לבדיקת הכשירות לעיבוד מראש,

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

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

משוב

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

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

אישורים

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

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

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

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

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

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

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

תשוקה

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

המגבלות ב-Chrome

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

כותרת ה-HTTP Speculation-Rules

כללי ספקולציות ושירותי SPA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

משוב

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

אישורים

כותרת ה-HTTP `Speculation-Rules`

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