דף זה תורגם על ידי Cloud Translation API.

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

Barry Pollard

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

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

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

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

כללי מסמכים

בעבר, ממשק Speculation Rules API עבד על ידי ציון רשימה של כתובות URL לטעינה מראש או לעיבוד מראש:

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

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

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

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

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

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

מגבלות ב-Chrome

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

`eagerness`	אחזור מראש (prefetch)	עיבוד מראש
`immediate` / `eager`	50	10
`moderate` / `conservative`	2 (FIFO)	2 (FIFO)

הגבלות על השערות ב-Chrome

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

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

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

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

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

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

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

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

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

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

ההצעה 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. לאחר מכן, הדפדפן יכול לבחור אם לאחזר את הקישור שוב או להמתין להשלמת האחזור מראש כדי לבדוק אם הוא מכיל כותרת HTTP מסוג No-Vary-Search. ההגדרה expects_no_vary_search מאפשרת לדפדפן לדעת שתגובת הדף צפויה לכלול כותרת HTTP מסוג No-Vary-Search, ולהמתין להשלמת האחזור מראש.

הדגמה (דמו)

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

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

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

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

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

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

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

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

WordPress

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

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

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

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

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

תודות

תמונה ממוזערת של Robbie Down ב-Unsplash