שיפורים ב-Speculation Rules API

Barry Pollard

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

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

תכונות נוספות

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

כללים למסמך

בעבר, ה-API של כללי הספקולציות עבד על ידי ציון רשימה של כתובות URL לשליפה מראש או לעיבוד מראש:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

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

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

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

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

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

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

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

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

תשוקה

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

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

ההגדרה eagerness מאפשרת להגדיר מתי צריך להפעיל ספקולציות, ומפרידה מתי ליצור ספקולציות על סמך כתובות ה-URL שבהן צריך לבצע ספקולציות. ההגדרה eagerness זמינה גם עבור כללי המקור list וגם עבור document, והיא כוללת ארבע הגדרות שעבורן Chrome כולל את היוריסטיקה הבאה:

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

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

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

המגבלות ב-Chrome

גם עם האפשרות eagerness, יש ב-Chrome מגבלות כדי למנוע שימוש יתר ב-API הזה:

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

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

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

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

Chrome גם ימנע שימוש בספקולציות בתנאים מסוימים, כולל:

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

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

source אופציונלי

לפי הגדרת Chrome 122, המפתח source אופציונלי, כי אפשר להסיק את זה מנוכחות המפתחות url או where. לכן, שני כללי הטעינות האלה זהים:

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

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

כותרת HTTP Speculation-Rules

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

שיפור שימוש חוזר במטמון

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

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

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

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

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

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

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

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

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

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

בדוגמה הזו, ה-HTML של הדף ההתחלתי /products זהה גם למזהי המוצרים 123 וגם ל-124. עם זאת, בסופו של דבר תוכן הדף משתנה בהתאם לרינדור בצד הלקוח באמצעות JavaScript, שמשמש לאחזור נתוני מוצרים באמצעות פרמטר החיפוש id. לכן, אנחנו מאחזרים את כתובת ה-URL מראש באופן יסודי, והיא אמורה להחזיר כותרת HTTP No-Vary-Search שמראה את הדף שניתן להשתמש בו לכל פרמטר חיפוש id.

עם זאת, אם המשתמש ילחץ על אחד מהקישורים לפני סיום השליפה מראש, יכול להיות שהדפדפן לא קיבל את הדף /products. במקרה כזה, הדפדפן לא יודע אם הוא יכיל את כותרת ה-HTTP No-Vary-Search. לאחר מכן, לדפדפן תהיה אפשרות לבחור אם לאחזר שוב את הקישור, או להמתין להשלמת השליפה מראש (prefetch) כדי לראות אם הוא מכיל כותרת HTTP No-Vary-Search. ההגדרה expects_no_vary_search מאפשרת לדפדפן לדעת שתגובת הדף צפויה להכיל כותרת HTTP No-Vary-Search, ולהמתין להשלמת השליפה מראש (prefetch).

הדגמה (דמו)

יצרנו הדגמה (דמו) בכתובת https://speculative-rules.glitch.me/common-fruits.html. אפשר להשתמש בה כדי לראות כללי מסמכים שהגדרת הערך של eagerness בפעולה moderate:

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

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

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

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

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

אנחנו גם משקיעים הרבה מאמצים כדי ליצור סטנדרטיזציה של ה-API באמצעות Web Incubator Community Group (WICG) כדי לאפשר לדפדפנים אחרים להטמיע גם את ה-API המלהיב הזה אם ירצו.

WordPress

צוות הביצועים של WordPress Core (כולל מפתחים מ-Google), יצר פלאגין של Speculation Rules (כללי ספקולציות). הפלאגין הזה מאפשר הוספה פשוטה בלחיצה אחת של תמיכה בכללי מסמכים לכל אתר WordPress. הפלאגין הזה זמין להתקנה גם באמצעות הפלאגין WordPress Performance Lab. כדאי גם להתקין אותו. הוא יעדכן אותך לגבי יישומי פלאגין שקשורים לביצועים של הצוות.

יש שתי קבוצות של הגדרות זמינות: מצב ספקולציות וההגדרה Eagerness:

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

Akamai

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

NitroPack

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

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

Astro

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

סיכום

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

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

אנחנו מתכננים להמשיך להשתמש ב-Speculation Rules API במהלך שנת 2024, ונודיע לך על שיפורים נוספים שאנחנו נבצע ב-API.

אישורים

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