כללי ספקולציות לניפוי באגים באמצעות כלי הפיתוח ל-Chrome

Barry Pollard

אפשר להשתמש בכללי השערות כדי לבצע טעינה מראש של ניווט לדף הבא ולבצע עיבוד מראש של ניווט לדף הבא, כפי שמתואר בפוסט הקודם. כך אפשר לטעון דפים מהר יותר, או אפילו באופן מיידי, ולשפר באופן משמעותי את מדדי Core Web Vitals במעברים הנוספים לדפים.

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

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

הסבר על המונחים 'pre-'

יש הרבה מונחים עם 'טרום' שמבלבלים, אז נתחיל בהסבר על המונחים הבאים:

• אחזור מראש: אחזור מראש של משאב או מסמך כדי לשפר את הביצועים בעתיד. הפוסט הזה עוסק בהטמעת טעינה מראש של מסמכים באמצעות Speculation Rules API, ולא באפשרות <link rel="prefetch"> הדומה אך הישנה יותר, שמשמשת לרוב להטמעת טעינה מראש של משאבי משנה.
• עיבוד מראש: התהליך הזה הולך צעד אחד קדימה מעבר לטעינה מראש, ומעבד בפועל את כל הדף כאילו המשתמש מנווט אליו, אבל שומר אותו בתהליך עיבוד מוסתר ברקע, מוכן לשימוש אם המשתמש מנווט אליו בפועל. שוב, המסמך הזה מתייחס לגרסה החדשה יותר של Speculation Rules API, ולא לאפשרות הישנה יותר <link rel="prerender"> (שכבר לא מבצעת עיבוד מראש מלא).
• ניווטים ספקולטיביים: המונח הכולל לאפשרויות החדשות של טעינה מראש ועיבוד מראש שמופעל על ידי כללי ספקולציה.
• טעינה מראש: מונח בעל עומס יתר שיכול להתייחס למספר טכנולוגיות ותהליכים, כולל <link rel="preload">, סורק הטעינה מראש וטעינות מראש של ניווט של שירותי עבודה. הפריטים האלה לא ייכללו כאן, אבל המונח נכלל כדי להבדיל בבירור בין הפריטים האלה לבין המונח 'ניווטים ספקולטיביים'.

כללי ספקולציות בחשבון prefetch

אפשר להשתמש בכללי ספקולציות כדי לבצע אחסון מראש של המסמך הבא בניווט. לדוגמה, כשמוסיפים את ה-JSON הבא לדף, next.html ו-next2.html יאוחסנו מראש:

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

לשימוש בכללי השערות להטמעה מראש של נתוני ניווט יש כמה יתרונות על פני התחביר הישן של <link rel="prefetch">, כמו API חזותי יותר והעובדה שהתוצאות מאוחסנות במטמון בזיכרון ולא במטמון הדיסק של HTTP.

ניפוי באגים של כללי ספקולציות prefetch

אחזור מראש שמופעל על ידי כללי ספקולציה מופיע בחלונית רשת באותו אופן שבו מופיע אחזור אחר:

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

לחיצה על אחת מהשורות תציג גם את כותרת ה-HTTP‏ Sec-Purpose: prefetch, שבאמצעותה אפשר לזהות את הבקשות האלה בצד השרת:

ניפוי באגים ב-prefetch באמצעות הכרטיסיות 'טעינה ספקולטיבית'

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

יש שלוש כרטיסיות בקטע הזה:

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

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

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

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

בצילום המסך הזה אפשר לראות את הסיבה לכישלון בדף next3.html (הדף לא קיים ולכן מוחזר קוד סטטוס 404, שהוא לא קוד סטטוס HTTP מסוג 2xx).

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

בדף שעבר אחסון מראש, אמורה להופיע הודעה על הצלחה כשעוברים אליו:

ספקולציות שלא תאמו

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

לדוגמה, כאן פנינו אל next4.html, אבל רק next.html,‏ next2.html או next3.html הם טעינות מראש, כך שאפשר לראות שהדף הזה לא תואם לאף אחד משלושת הכללים האלה.

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

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

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

כללי ספקולציות בחשבון prerender

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

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

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

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

ניפוי באגים ב-prerender באמצעות הכרטיסיות 'טעינות ספקולטיביות'

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

כאן שוב רואים שאחת משלוש כתובות ה-URL נכשלה ברינדור מראש, ומפתחים יכולים לקבל את הפרטים לכל כתובת URL בכרטיסייה Speculations (ספקולציות) בלחיצה על הקישור 2 Ready, 1 Failure (2 מוכנות, 1 כשל).

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

הוא גם מגדיר את ה-prerender‏ eagerness לערך moderate, כלומר הניווטים עוברים עיבוד מראש כשעובר מעל הקישור או לוחצים עליו.

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

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

ב-Chrome מוגדרות מגבלות על עיבוד מראש, כולל 2 עיבודים מראש לכל היותר לצורך moderate, כך שלאחר העברת העכבר מעל הקישור השלישי, מוצגת הסיבה לכישלון של כתובת ה-URL הזו:

ניפוי באגים ב-prerender באמצעות שאר החלוניות של כלי הפיתוח

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

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

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

כשבודקים את כותרות ה-HTTP של המשאבים האלה, רואים שכולן יוגדרו עם הכותרת Sec-Purpose: prefetch;prerender:

לחלופין, אפשר להשתמש בחלונית Elements (רכיבים), שבה מוצגים תוכן הדף. לדוגמה, בצילום המסך הבא רואים שהרכיב <h1> מייצג את הדף שעבר עיבוד מראש:

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

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

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

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

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

סיכום

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

תודות

תמונה ממוזערת של Nubelson Fernandes ב-Unsplash.