צוות 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>
אפשר גם להשתמש בסלקטורים ב-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) כבדים יותר של דפים, יעדיפו להפחית את כמות הפסולת על ידי ביצוע השערות בתדירות נמוכה יותר, עד שתקבלו אות חיובי יותר לגבי הכוונה של המשתמשים להגביל את הפסולת.
האפשרות 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) |
ההגדרות 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
בפעולה:
![צילום מסך של אתר להדגמה שנוצר בתקלה שבה מפורטים מספר קישורים המתויגים עם פירות. כלי הפיתוח פתוחים ומוצגים בהם שניים מהקישורים (apple.html ו-כתום.html) כבר עובדו מראש בהצלחה.](https://developer.chrome.com/static/blog/speculation-rules-improvements/images/speculation-rules-demo.png?authuser=5&hl=he)
פותחים את כלי הפיתוח, לוחצים על החלונית 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 עם ההגדרות של כללי ספקולציות. יש שתי אפשרויות: מצב ספקולציה עם אפשרות לשליפה מראש (prefetch) או לעיבוד מראש, והגדרה של ערנות (Eagerness) עם הגדרות שמרניות, מדיניות בינונית או Eager.](https://developer.chrome.com/static/blog/speculation-rules-improvements/images/wordpress-speculation-rules.png?authuser=5&hl=he)
להגדרות מורכבות יותר – לדוגמה, כדי להחריג כתובות 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.