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

Barry Pollard

תאריך פרסום: 7 במרץ 2025

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

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

תכנון

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

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

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

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

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

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

הכללת כללי ספקולציה ישירות ב-HTML של הדף

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

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

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

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

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

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

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

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

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

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

איך מוצאים את האיזון בין השקעה גדולה מדי או קטנה מדי

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

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

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

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

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

מתחילים עם אחסון נתונים לפני האצווה

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

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

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

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

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