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

Barry Pollard

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

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

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

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

כללים למסמכים

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

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

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

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

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

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

הערה: גרסה קודמת של כללי מסמך (שהייתה זמינה במהלך גרסת המקור לניסיון) כללה גרסה href_matches מורכבת יותר, שחייב שימוש בתחביר נוסף כדי להתאים לפרמטרים ולמקטעים של כתובות URL ({"href_matches": "/*\\?*#*"}). הגרסה הזו פשוטה יותר.

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

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

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

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

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

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

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

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

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

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

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

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

כללי הטעינות מראש תומכים בשימוש ב-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, ולהמתין שהשליפה מראש (prefetch) תושלם.

הדגמה (דמו)

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

הדגמה של כללי ספקולציות

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

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

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

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

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

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

WordPress

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

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

פלאגין של כללי ספקולציות ב-WordPress

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

אקמאי

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

NitroPack

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

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

אסטרו

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

סיכום

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

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

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

אישורים

תמונה ממוזערת של רובי דאון ב-Unflaיז