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

Barry Pollard

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

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

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

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

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

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

מדידת ההשפעה

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

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

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

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