אפשר להשתמש בכללי ספקולציות כדי לשלוף מראש ולעבד מראש את הניווטים בדף הבא, כפי שמפורט בפוסט הקודם. כך אפשר לטעון דפים הרבה יותר מהר, או אפילו באופן מיידי, ולשפר משמעותית את המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) במעברים הנוספים האלה בין דפים.
ניפוי באגים של כללי ספקולציות יכול להיות מסובך. זה נכון במיוחד לגבי דפים שעברו רינדור מראש, כי הדפים האלה עוברים רינדור בכלי רינדור נפרד – בדומה לכרטיסייה מוסתרת ברקע שמחליפה את הכרטיסייה הנוכחית כשהיא מופעלת. לכן, לא תמיד אפשר להשתמש באפשרויות הרגילות של כלי הפיתוח כדי לנפות באגים.
צוות Chrome עובד קשה כדי לשפר את התמיכה של כלי הפיתוח בניפוי באגים של כללי ספקולציה. בפוסט הזה נציג את כל הדרכים השונות להשתמש בכלים האלה כדי להבין את כללי הספקולציה של דף, למה הם לא פועלים, ומתי מפתחים יכולים להשתמש באפשרויות המוכרות יותר של כלי הפיתוח – ומתי לא.
הסבר על המונחים שמתחילים ב "טרום-"
יש הרבה מונחים עם התחילית "טרום" שעלולים לבלבל, אז נתחיל בהסבר עליהם:
- אחזור מראש: אחזור של משאב או מסמך מראש כדי לשפר את הביצועים בעתיד. הפוסט הזה עוסק בשליפה מראש של מסמכים באמצעות Speculation Rules API, ולא באפשרות הדומה אך הישנה יותר
<link rel="prefetch">, שמשמשת לעיתים קרובות לשליפה מראש של משאבי משנה. - עיבוד מראש: התהליך הזה מתקדם יותר מאחזור מראש, ומעבד את כל הדף כאילו המשתמש נכנס אליו, אבל שומר אותו בתהליך עיבוד מוסתר ברקע שמוכן לשימוש אם המשתמש אכן ייכנס אליו. שוב, המסמך הזה עוסק בגרסה החדשה יותר של Speculation Rules API, ולא באפשרות הישנה יותר של
<link rel="prerender">(שכבר לא מבצעת רינדור מראש מלא). - ניווטים ספקולטיביים: המונח הכולל לאפשרויות החדשות של שליפה מראש ורינדור מראש שמופעלות על ידי כללי ספקולציה.
- טעינה מראש: מונח עמוס שיכול להתייחס למספר טכנולוגיות ותהליכים, כולל
<link rel="preload">, סורק הטעינה מראש וטעינה מראש של ניווט ב-Service Worker. לא נתייחס לפריטים האלה כאן, אבל המונח נכלל כדי להבדיל אותם בבירור מהמונח "ניווטים ספקולטיביים".
כללי ספקולציות של prefetch
אפשר להשתמש בכללי ספקולציות כדי לשלוף מראש את המסמך של הניווט הבא. לדוגמה, כשמוסיפים את קטע ה-JSON הבא לדף, המערכת תבצע אחזור מראש של next.html ו-next2.html:
<script type="speculationrules">
{
"prefetch": [
{
"source": "list",
"urls": ["next.html", "next2.html"],
"tag": "rule-set-tag-1"
}
]
}
</script>
לשימוש בכללי ספקולציה לאחזור מראש של ניווט יש כמה יתרונות על פני התחביר הישן יותר של <link rel="prefetch">, כמו API אקספרסיבי יותר והתוצאות נשמרות במטמון הזיכרון ולא במטמון הדיסק של HTTP.
ניפוי באגים ב-prefetch כללי ספקולציות
אפשר לראות שליפות מראש (prefetch) שהופעלו על ידי כללי ספקולציות בחלונית רשת, באותו אופן שבו רואים שליפות אחרות:
שתי הבקשות שמודגשות באדום הן המשאבים שאוחזרו מראש, כפי שניתן לראות בעמודה Type. הם נשלפים בעדיפות Lowest כי הם מיועדים לניווטים עתידיים, ו-Chrome נותן עדיפות למשאבים של הדף הנוכחי.
לחיצה על אחת מהשורות מציגה גם את כותרת ה-HTTP Sec-Purpose: prefetch, שבאמצעותה אפשר לזהות את הבקשות האלה בצד השרת:
ניפוי באגים ב-prefetch באמצעות הכרטיסיות "טעינה מראש"
הוספנו קטע חדש בשם טעינה מראש ספקולטיבית לחלונית אפליקציה בכלי הפיתוח ל-Chrome, מתחת לקטע שירותים שפועלים ברקע, כדי לעזור בניפוי באגים של כללי ספקולציה:
בקטע הזה יש שלוש כרטיסיות:
- טעינות מראש, שבהן מופיע סטטוס הרינדור מראש של הדף הנוכחי.
- כללים: רשימה של כל קבוצות הכללים שנמצאו בדף הנוכחי, שמוגדרות ככתובות URL או כתגי כללים, אם יש כאלה.
- השערות: רשימה של כל כתובות ה-URL שאוחזרו מראש ורונדרו מראש מקבוצות הכללים.
הכרטיסייה Speculations מוצגת בצילום המסך הקודם, ואנחנו יכולים לראות שבדף לדוגמה הזה יש קבוצה אחת של כללי ספקולציות לשליפה מראש של 3 דפים. שתיים מהאחזורים מראש האלה הצליחו ואחד נכשל. אפשר ללחוץ על הסמל שלצד קבוצת הכללים כדי לעבור למקור של קבוצת הכללים בחלונית רכיבים. אפשר גם ללחוץ על הקישור סטטוס כדי לעבור לכרטיסייה השערות, שמסוננת לפי קבוצת הכללים הזו.
בכרטיסייה Speculations מופיעות כל כתובות ה-URL המטורגטות, לצד הפעולה (אחזור מראש או רינדור מראש), קבוצת הכללים שממנה הן הגיעו (כי יכולות להיות כמה קבוצות בדף) והסטטוס של כל ספקולציה:
מעל כתובות ה-URL, אפשר להשתמש בתפריט נפתח כדי להציג כתובות URL מכל קבוצות הכללים, או רק כתובות URL מקבוצת כללים מסוימת. מתחת לזה מופיעות כל כתובות ה-URL. לחיצה על כתובת URL תציג מידע מפורט יותר.
בצילום המסך הזה אפשר לראות את סיבת הכישלון של הדף next3.html (שלא קיים ולכן מחזיר את הקוד 404, שהוא קוד סטטוס של HTTP שלא בתבנית של 2xx).
בכרטיסיית הסיכום טעינה מראש מוצג הדוח סטטוס הטעינה מראש של הדף הזה, שבו אפשר לראות אם בוצעה שליפה מראש או רינדור מראש של הדף.
בדף שנשלף מראש, אמורה להופיע הודעה על הצלחה כשעוברים לדף הזה:
ספקולציות ייחודיות
כשמתבצע ניווט מדף עם כללי ספקולציות שלא מוביל לשימוש בשליפה מראש או ברינדור מראש, בקטע נוסף בכרטיסייה יוצגו פרטים נוספים על הסיבה לכך שכתובת ה-URL לא תאמה לאף אחת מכתובות ה-URL של הספקולציות. זה שימושי לזיהוי שגיאות הקלדה בכללי הספקולציות.
לדוגמה, כאן עברנו אל next4.html, אבל רק next.html, next2.html או next3.html הם אחזורים מראש, כך שאנחנו יכולים לראות שזה לא ממש תואם לאף אחד משלושת הכללים האלה.
הכרטיסיות טעינות מראש שימושיות מאוד לניפוי באגים בכללי הטעינה מראש עצמם, ולמציאת שגיאות תחביר ב-JSON.
לגבי השליפות מראש עצמן, החלונית רשת היא כנראה מקום מוכר יותר. בדוגמה של השגיאה באחזור מראש, אפשר לראות את שגיאת 404 של האחזור מראש כאן:
עם זאת, הכרטיסיות Speculative loads (טעינות מראש) שימושיות הרבה יותר לכללי ספקולציות של רינדור מראש, שמוסברים בהמשך.
כללי ספקולציות של prerender
כללי הספקולציות של רינדור מראש פועלים לפי אותו תחביר כמו כללי הספקולציות של שליפה מראש. לדוגמה:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"],
"tag": "rule-set-tag-1"
}
]
}
</script>
קבוצת הכללים הזו מפעילה טעינה ועיבוד מלאים של הדפים שצוינו (בכפוף להגבלות מסוימות). כך אפשר ליהנות מחוויית טעינה מיידית, אבל זה דורש משאבים נוספים.
עם זאת, בניגוד לאחזור מראש, אי אפשר לראות את הפעולות האלה בחלונית רשת, כי הן מאוחזרות ומרונדרות בתהליך רינדור נפרד ב-Chrome. לכן הכרטיסיות Speculative loads חשובות יותר לניפוי באגים של כללי טעינה מראש של רינדור מראש.
ניפוי באגים ב-prerender באמצעות הכרטיסיות "טעינות מראש"
אפשר להשתמש באותם מסכים של טעינות מראש לכללי ספקולציות של רינדור מראש, כמו שמוצג בדף הדגמה דומה שמנסה לרנדר מראש, במקום לשלוף מראש את שלושת הדפים:
כאן אנחנו רואים שוב שאחת משלוש כתובות ה-URL נכשלה ברינדור מראש, והמפתחים יכולים לקבל את הפרטים לכל כתובת URL בכרטיסייה Speculations (השערות) על ידי לחיצה על הקישור 2 Ready, 1 Failure (2 מוכנות, 1 נכשלה).
ב-Chrome 121 השקנו תמיכה בכללי מסמכים. כך הדפדפן יכול לאסוף את הנתונים האלה מקישורים עם אותו מקור בדף, במקום להגדיר קבוצה ספציפית של כתובות URL:
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{"href_matches": "/*"},
{"not": { "href_matches": "/not-safe-to-prerender/*"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
בדוגמה הזו, כל הקישורים מאותו מקור נבחרים כמועמדים לרינדור מראש, חוץ מאלה שמתחילים ב-/not-safe-to-prerender.
הוא גם מגדיר את הרינדור מראש eagerness ל-moderate, כלומר הניווטים מרונדרים מראש כשמעבירים את העכבר מעל הקישור (במחשב), על סמך אזור התצוגה (בנייד) או כשלוחצים עליו.
יש כללים דומים לזה באתר ההדגמה של כללי הספקולציות, והשימוש בקטע החדש טעינה מראש ספקולטיבית באתר הזה מראה את התועלת של הכרטיסייה החדשה הזו, כי כל כתובות ה-URL הכשירות שהדפדפן מצא בדף מפורטות:
הסטטוס הוא לא הופעל כי תהליך הרינדור מראש של הדפים האלה לא התחיל. עם זאת, כשאנחנו מעבירים את הסמן מעל הקישורים, אנחנו רואים שהסטטוס משתנה כשכל כתובת URL עוברת רינדור מראש:
ב-Chrome יש מגבלות על רינדורים מראש, כולל מקסימום של 2 רינדורים מראש לרמת הלהיטות moderate. לכן, אחרי שמעבירים את העכבר מעל הקישור השלישי, רואים את סיבת הכישלון של כתובת ה-URL הזו:
ניפוי באגים של prerender באמצעות החלוניות האחרות של כלי הפיתוח
בניגוד לאחזור מראש, דפים שעברו רינדור מראש לא יופיעו בתהליכי הרינדור הנוכחיים בחלוניות של DevTools, כמו החלונית רשת, כי הם עוברים רינדור במרנדר משלהם שפועל מאחורי הקלעים.
עם זאת, עכשיו אפשר להחליף את המרנדר שמשמש את החלוניות של כלי הפיתוח באמצעות התפריט הנפתח שבפינה השמאלית העליונה, או על ידי בחירת כתובת URL בחלק העליון של החלונית ובחירה באפשרות בדיקה:
התפריט הנפתח הזה (והערך שנבחר) משותף גם לכל החלוניות האחרות, כמו החלונית רשת, שבה אפשר לראות שהדף המבוקש הוא הדף שרונדר מראש:
אם נסתכל על כותרות ה-HTTP של המשאבים האלה, נראה שכולם יוגדרו עם הכותרת Sec-Purpose: prefetch;prerender:
או בחלונית Elements (רכיבים), שבה אפשר לראות את תוכן הדף, כמו בצילום המסך הבא שבו רואים שהרכיב <h1> מיועד לדף שעבר רינדור מראש:
או בחלונית Console, שבה אפשר לראות את יומני המסוף שהדף שרונדר מראש פולט:
ניפוי באגים של כללי ספקולציות בדף שעבר רינדור מראש
בקטעים הקודמים הסברנו איך לנפות באגים בדפים שעברו רינדור מראש בדף שמתחיל את הרינדור מראש. עם זאת, יכול להיות שגם הדפים שרונדרו מראש יספקו מידע על תוצאות ניפוי הבאגים, על ידי ביצוע קריאות לניתוח נתונים או רישום ביומן במסוף (שאפשר לראות כפי שמתואר בסעיף הקודם).
בנוסף, אחרי שהמשתמש מפעיל דף שרונדר מראש על ידי ניווט אליו, בכרטיסייה טעינות משוערות יוצג הסטטוס הזה, וגם אם הרינדור מראש הצליח או לא. אם לא ניתן היה לבצע רינדור מראש, יופיע הסבר לסיבה לכך:
בנוסף, כמו במקרה של שליפות מראש (prefetch), אם תנווטו מדף עם כללי טעינה מראש שלא תאמו לדף הנוכחי, בכרטיסייה טעינות מראש תופיע הסיבה לכך שכתובות ה-URL לא תאמו לאלה שכלולות בכללי הטעינה מראש של הדף הקודם:
סיכום
בפוסט הזה הצגנו את הדרכים השונות שבהן מפתחים יכולים לנפות באגים בכללי ספקולציות של שליפה מראש ורינדור מראש. הצוות ממשיך לעבוד על כלים לכללי ספקולציה, ונשמח לשמוע הצעות ממפתחים לגבי דרכים אחרות שיכולות לעזור לנפות באגים ב-API החדש והמלהיב הזה. אנחנו ממליצים למפתחים לדווח על בעיות בIssue Tracker של Chrome לגבי כל הגשת בקשה להוספת תכונה או באג שזוהה.
תודות
התמונה הממוזערת נוצרה על ידי Nubelson Fernandes ב-Unsplash.