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

Barry Pollard

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

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

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

תכנון

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

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

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

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

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

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

שיקולי עלות

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

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

סיכום

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

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