מדריך להטמעת כללי ספקולציות לאתרים מורכבים יותר

Barry Pollard

תאריך פרסום: 7 במרץ 2025, תאריך העדכון האחרון: 23 באוקטובר 2025

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

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

תכנון

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

איך מטמיעים כללי ספקולציות

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

• ישירות בקוד ה-HTML של הדף
• שימוש ב-JavaScript
• שימוש בכותרת HTTP

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

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

הכללת כללי טעינה מראש ישירות ב-HTML של הדף

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

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

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "selector_matches": ".prerender" }
    }],
    "prefetch": [{
      "where": { "selector_matches": ".prefetch" }
    }]
  }
</script>

הסקריפט הקודם יבצע טרום-עיבוד של קישורים עם מחלקה prerender, ובדומה לכך יבצע טרום-אחזור כשקישור כולל מחלקה prefetch. כך המפתחים יכולים לכלול את המחלקות האלה ב-HTML כדי להפעיל השערות.

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

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

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

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

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

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

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

הוספת כללי ספקולציה באמצעות כותרת HTTP

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

Speculation-Rules: "/speculationrules.json"

יש דרישות נוספות לגבי האופן שבו משאב הכללים (/speculationrules.json בדוגמה הזו) מועבר ומשמש.

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

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

שיקולי עלות

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

שיקולי עלות למשתמשים

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

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

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

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

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

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

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

כדאי לקחת בחשבון עומס נוסף על ה-Backend

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

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

אפשר גם להשתמש בשרת או ב-CDN כדי לשלוט בתוצאות הניחוש, כפי שמזוהה על ידי כותרת ה-HTTP ‏sec-purpose. לדוגמה, המוצר Speed Brain של Cloudflare מאפשר רק ספקולציות שכבר נשמרו במטמון בשרת קצה של CDN, ולא ישלח בקשות בחזרה למקור.

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

איזון בין ספקולציות מוגזמות לבין ספקולציות מועטות מדי

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

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

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

שלבים להטמעה של כללי ספקולציות

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

מתחילים עם אחזור מראש

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

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

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

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

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

טרום-עיבודים ברמת סיכון נמוכה

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

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

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

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

<script type="speculationrules">
  {
    "prefetch": [{
      "urls": ["next.html", "next2.html"],
      "eagerness": "eager"
    }],
    "prerender": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

הצגה מוקדמת מוקדמת יותר

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

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

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "selector_matches": : ".prerender"
        },
        "eagerness": "eager",
      },
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": {"href_matches": "/logout"}}
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

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

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

‫Analytics, מודעות ו-JavaScript

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

חלק מספקי ניתוח הנתונים (כמו Google Analytics) וספקי המודעות (כמו Google Publisher Tag) כבר תומכים בכללי ניחוש, ולא יתעדו צפיות עד שהדף יופעל. עם זאת, יכול להיות שספקים אחרים או ניתוח נתונים בהתאמה אישית שהטמעתם ידרשו התייחסות נוספת. אנחנו מנהלים רשימה של ספקים שידוע לנו שהם תומכים בכללי הניחושים.

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

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

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

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

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

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

עדכון של השערות לגבי טרום-עיבוד

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

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

‫Broadcast Channel API היא דרך אחת לאפשר לדף אחד בדפדפן לשדר עדכונים כאלה לדפים אחרים. הפעולה הזו תפתור גם את הבעיה של פתיחת כמה כרטיסיות. דפים שעברו טרום-עיבוד יכולים להאזין להודעות שידור – אבל הם לא יכולים לשלוח הודעות שידור משלהם עד שהם מופעלים.

לחלופין, אפשר לקבל עדכונים לדפים שעברו טרום-עיבוד באמצעות השרת (באמצעות fetch() תקופתי או חיבור WebSocket), אבל יכול להיות שיהיו עיכובים בעדכונים.

ביטול או רענון של השערות לגבי טרום-עיבוד

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

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

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

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

async function refreshSpeculations() {
  const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');

  for (const speculationScript of speculationScripts) {
    // Get the current rules as JSON text
    const ruleSet = speculationScript.textContent;

    // Remove the existing script to reset prerendering
    speculationScript.remove();
    
    // Await for a microtask before re-inserting.
    await Promise.resolve();

    // Reinsert rule in a new speculation rules script
    const newScript = document.createElement('script');
    newScript.type = 'speculationrules';
    newScript.textContent = ruleSet;
    console.log(newScript);

    // Append the new script back to the document
    document.body.appendChild(newScript);
  }
}

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

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

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

מדידת ההשפעה

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

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

איך מודדים הצלחה

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

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

איך מודדים את השימוש ואת הבזבוז

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

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

if (document.prerendering) {
  console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
  console.log("Page has already prerendered");
} else {
  console.log("This page load was not using prerendering");
}

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

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

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

סיכום

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

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