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

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

Barry Pollard

תאריך פרסום: 2 בדצמבר 2022, תאריך עדכון אחרון: 30 במאי 2025

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

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

בעבר, Chrome תמך בהצעה לשימוש במשאב , אבל לא הייתה תמיכה רחבה מחוץ ל-Chrome, והוא לא היה ממשק API יעיל במיוחד.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Speculation Rules API

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

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

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

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

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

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

מגבלות ב-Chrome

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

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

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

בנוסף, Chrome ימנע שימוש בשערות בתנאים מסוימים, כולל:

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

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

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

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

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

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

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

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

הכותרת Speculation-Rules של HTTP

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

שדה התג של כללי הספקולציות

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

{
  "prefetch": [
    "urls": ["next.html"],
    "tag": "my-prefetch-rules"
  ],
  "prerender": [
    "urls": ["next2.html"],
    "tag": "my-prerender-rules"
  ],
}

או ברמה הכוללת לכל כללי הספקולציות בכללי המדיניות:

{
  "tag": "my-rules",
  "prefetch": [
    "urls": ["next.html"]
  ],
  "prerender": [
    "urls": ["next2.html"]
  ],
}

לאחר מכן, התג הזה משתקף בכותרת ה-HTTP‏ Sec-Speculation-Tags, שאפשר להשתמש בה כדי לסנן כללי ספקולציה בשרת. כותרת ה-HTTP‏ Sec-Speculation-Tags יכולה לכלול כמה תגים אם ההשערה מכוסה בכמה כללים, כפי שמוצג בדוגמה הבאה:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

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

תגים יכולים להיות שימושיים גם בכלים, לדוגמה we are looking to add tags to DevTools.

השדה target_hint של כללי הספקולציות

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

ההצעה הזו מאפשרת לטפל בהשערות של עיבוד מראש בקישורים מסוג target="_blank":

Open this link in a new tab

בשלב הזה, רק "target_hint": "_blank" ו-"target_hint": "_self" (ברירת המחדל אם לא צוין אחרת) נתמכים ב-Chrome, ורק לצורך עיבוד מראש – אי אפשר להשתמש בהם לצורך אחסון מראש.

השדה target_hint נדרש רק לכללי השערות של urls, כי בכללי מסמכים השדה target ידוע מהקישור עצמו.

כללי ספקולציות והסכמי SPA

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

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

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

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

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

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

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

כמה סקריפטים של speculationrules:

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

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

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

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

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

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

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

Product 123
Product 124

בדוגמה הזו, ה-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, ולהמתין להשלמת האחזור מראש.

אפשר גם להוסיף כמה פרמטרים ל-expects_no_vary_search באמצעות רווח מפריד ביניהם (כי No-Vary-Search היא כותרת מובנית של HTTP):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

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

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

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

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

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

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

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

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

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

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.

הוספת רכיב

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

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

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

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

מגרסה 3.1.0, הספרייה web-vitals עודכנה כדי לטפל בניווטים שעברו רינדור מראש באותו אופן שבו Chrome מודד את מדדי Core Web Vitals. הגרסה הזו מסמנת גם אירועי ניווט שעברו עיבוד מראש עבור המדדים האלה במאפיין 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 שוקלל להוסיף כלים נוספים לבדיקת הזכאות לעיבוד מראש, אולי בדומה לכלי הבדיקה של bfcache, וגם להוסיף API כדי לחשוף את הסיבה לכישלון של עיבוד מראש.

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

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

משוב

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

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

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

תודות

תמונה ממוזערת של Marc-Olivier Jodoin ב-Unsplash