תודה שצפית ב-Google I/O! צפייה בתוכן על פי דרישה.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מדידת אינטראקציה עד הצבע הבא (INP)

1. מבוא

בשיעור Codelab האינטראקטיבי הזה נסביר איך למדוד את מהירות התגובה לאינטראקציה באתר (INP) באמצעות ספריית web-vitals.

דרישות מוקדמות

ידע בפיתוח HTML ו-JavaScript.
מומלץ: לקרוא את מאמרי העזרה בנושא מדד INP ב-web.dev.

מה תלמדו

איך מוסיפים את ספריית web-vitals לדף ומשתמשים בנתוני השיוך שלה.
אפשר להשתמש בנתוני השיוך כדי לאבחן איפה ואיך כדאי להתחיל לשפר את מדד INP.

מה צריך

מחשב עם אפשרות לשכפל קוד מ-GitHub ולהריץ פקודות npm.
כלי לעריכת טקסט.
גרסה עדכנית של Chrome כדי שכל המדידות של האינטראקציות יפעלו.

2. להגדרה

קבלת הקוד והרצתו

הקוד נמצא במאגר web-vitals-codelabs.

משכפלים את המאגר בטרמינל: git clone https://github.com/GoogleChromeLabs/web-vitals-codelabs.git.
עוברים לספרייה המשוכפלת: cd web-vitals-codelabs/measuring-inp.
מתקינים את שאר הספריות הדרושות לצורך יצירת ספריות הלקוח: npm ci.
מפעילים את שרת האינטרנט: npm run start.
עוברים אל http://localhost:8080/ בדפדפן.

ניסיון השימוש בדף

בשיעור Codelab הזה נשתמש באתר Gastropodicon (אתר פופולרי עם הפניות לאנטומיה של חלזונות) כדי לבדוק בעיות פוטנציאליות שקשורות ל-INP.

צילום מסך של דף ההדגמה של Gastropodicon

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

3. התמצאות בכלי הפיתוח ל-Chrome

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

ב-codelab הזה נשתמש גם בחלונית Performance וגם בConsole. אפשר לעבור ביניהם בכל שלב באמצעות הכרטיסיות בחלק העליון של DevTools.

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

צילום מסך של חלונית הביצועים בכלי הפיתוח לצד האפליקציה, עם האטה של 4x במעבד

4. התקנה של web-vitals

‫web-vitals היא ספריית JavaScript למדידת מדדי Web Vitals שהמשתמשים חווים. אפשר להשתמש בספרייה כדי לתעד את הערכים האלה, ואז לשלוח אותם לנקודת קצה של Analytics לצורך ניתוח מאוחר יותר. למטרות שלנו, אנחנו רוצים להבין מתי ואיפה מתרחשות אינטראקציות איטיות.

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

ב-Codelab הזה נתקין מ-npm ונטען את הסקריפט ישירות כדי לא להתעמק בתהליך build מסוים.

יש שתי גרסאות של web-vitals שאפשר להשתמש בהן:

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

כדי למדוד את INP בשיעור Codelab הזה, אנחנו רוצים את גרסת השיוך.

מוסיפים את web-vitals לdevDependencies של הפרויקט על ידי הפעלת npm install -D web-vitals

מוסיפים את `web-vitals` לדף:

מוסיפים את גרסת השיוך של הסקריפט לתחתית של index.html ורושמים את התוצאות במסוף:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log);
</script>

רוצה לנסות?

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

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

‫web-vitals מספק אפשרות reportAllChanges לדיווח מפורט יותר. כשמפעילים את האפשרות הזו, לא מדווחים על כל אינטראקציה, אלא על כל אינטראקציה שהיא איטית יותר מכל אינטראקציה שקדמה לה.

נסו להוסיף את האפשרות לסקריפט ולקיים אינטראקציה עם הדף שוב:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log, {reportAllChanges: true});
</script>

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

צילום מסך של המסוף בכלי הפיתוח, שבו הודעות INP הודפסו בהצלחה

5. מה נכלל בשיוך?

נתחיל עם האינטראקציה הראשונה שרוב המשתמשים יקיימו עם הדף – תיבת הדו-שיח לבקשת הסכמה לשימוש בקובצי Cookie.

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

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

אובייקט נתוני INP שנרשם במסוף כלי הפיתוח

המידע הזה ברמה העליונה זמין גם בגרסאות הרגילות של מדדי הליבה של האתר וגם בגרסאות שכוללות שיוך (Attribution):

{
  name: 'INP',
  value: 344,
  rating: 'needs-improvement',
  entries: [...],
  id: 'v4-1715732159298-8028729544485',
  navigationType: 'reload',
  attribution: {...},
}

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

עם זאת, כדי לגלות מה קורה בזמן הזה, אנחנו מתעניינים בעיקר בנכס attribution. כדי ליצור את נתוני השיוך, web-vitals בודק אילו מסגרות של אנימציות ארוכות (LoAF) חופפות לאירוע מסוג קליק. לאחר מכן, ה-LoAF יכול לספק נתונים מפורטים על אופן השימוש בזמן במהלך הפריים הזה, החל מהסקריפטים שהופעלו ועד לזמן שהוקדש לקריאה חוזרת (callback), לסגנון ולפריסה של requestAnimationFrame.

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

attribution: {
  interactionTargetElement: Element,
  interactionTarget: '#confirm',
  interactionType: 'pointer',

  inputDelay: 27,
  processingDuration: 295.6,
  presentationDelay: 21.4,

  processedEventEntries: [...],
  longAnimationFrameEntries: [...],
}

קודם כל, יש מידע על מה שהייתה אינטראקציה איתו:

‫interactionTargetElement: הפניה פעילה לרכיב שהייתה איתו אינטראקציה (אם הרכיב לא הוסר מ-DOM).
‫interactionTarget: בורר למציאת הרכיב בדף.

בהמשך, מפורטות נקודות הזמן ברמה גבוהה:

‫inputDelay: הזמן שחלף מהרגע שבו המשתמש התחיל את האינטראקציה (למשל, לחץ על העכבר) ועד שהתחיל לפעול רכיב event listener של האינטראקציה הזו. במקרה הזה, עיכוב הקלט היה רק כ-27 אלפיות השנייה, גם כשויסות הנתונים במעבד היה מופעל.
‫processingDuration: משך הזמן שנדרש להרצה של פונקציות event listener עד להשלמה. לעתים קרובות, בדפים יש כמה מאזינים לאירוע יחיד (לדוגמה, pointerdown, pointerup ו-click). אם כולם פועלים באותו פרים של אנימציה, הם יאוחדו לזמן הזה. במקרה הזה, משך העיבוד הוא 295.6 מילישניות – רוב הזמן של INP.
‫presentationDelay: הזמן שחלף מסיום הפעולה של רכיבי event listener ועד שהדפדפן סיים לבצע רינדור (painting) של הפריים הבא. במקרה הזה, 21.4 אלפיות השנייה.

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

אם מתעמקים קצת יותר, אפשר לראות שהמערך processedEventEntries מכיל חמישה אירועים, בניגוד לאירוע היחיד במערך INP ברמה העליונה entries. מה ההבדל?

processedEventEntries: [
  {
    name: 'mouseover',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {
    name: 'mousedown',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {name: 'mousedown', ...},
  {name: 'mouseup', ...},
  {name: 'click', ...},
],

הערך ברמה העליונה הוא אירוע ה-INP, במקרה הזה קליק. השיוך processedEventEntries הוא כל האירועים שעברו עיבוד במהלך אותו פריים. שימו לב שהוא כולל אירועים אחרים כמו mouseover ו-mousedown, ולא רק את אירוע מסוג קליק. המידע על האירועים האחרים האלה יכול להיות חיוני אם הם גם היו איטיים, כי כולם תרמו לאיטיות התגובה.

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

`longAnimationFrameEntries`

הרחבת הרשומה של LoAF:

longAnimationFrameEntries: [{
  name: 'long-animation-frame',
  startTime: 1823,
  duration: 319,

  renderStart: 2139.5,
  styleAndLayoutStart: 2139.7,
  firstUIEventTimestamp: 1801.6,
  blockingDuration: 268,

  scripts: [{...}]
}],

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

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 1828.6,
  executionStart: 1828.6,
  duration: 294,

  sourceURL: 'http://localhost:8080/third-party/cmp.js',
  sourceFunctionName: '',
  sourceCharPosition: 1144
}]

במקרה הזה, אפשר לראות שרוב הזמן הושקע בפונקציה אחת event-listener, שהופעלה ב-BUTTON#confirm.onclick. אפשר אפילו לראות את כתובת ה-URL של מקור הסקריפט ואת מיקום התו שבו הוגדרה הפונקציה.

Takeaway

מה אפשר להסיק לגבי המקרה הזה מנתוני השיוך האלה?

האינטראקציה הופעלה על ידי קליק על הרכיב button#confirm (מתוך attribution.interactionTarget והמאפיין invoker ברשומה של שיוך סקריפט).
רוב הזמן הושקע בהפעלת מאזיני אירועים (מתוך attribution.processingDuration בהשוואה למדד הכולל value).
קוד ה-event listener האיטי מתחיל מ-click listener שמוגדר ב-third-party/cmp.js (מ-scripts.sourceURL).

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

6. כמה פונקציות event listener

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

מתחילים להקליד בתיבת החיפוש. מה אפשר לראות בנתוני השיוך? מה לדעתך קורה?

נתוני שיוך (Attribution)

קודם כול, סקירה כללית של דוגמה אחת לבדיקת ההדגמה:

{
  name: 'INP',
  value: 1072,
  rating: 'poor',
  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'keyboard',

    inputDelay: 3.3,
    processingDuration: 1060.6,
    presentationDelay: 8.1,

    processedEventEntries: [...],
    longAnimationFrameEntries: [...],
  }
}

זהו ערך INP נמוך (עם הגבלת מהירות ה-CPU מופעלת) מאינטראקציה עם המקלדת עם רכיב input#search-terms. רוב הזמן – 1,061 אלפיות השנייה מתוך סך של 1,072 אלפיות השנייה של INP – הוקדש לעיבוד.

עם זאת, התוצאות של scripts מעניינות יותר.

שינוי פריסה

הערך הראשון במערך scripts מספק לנו הקשר חשוב:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 4875.6,
  executionStart: 4875.6,
  duration: 497,
  forcedStyleAndLayoutDuration: 388,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'handleSearch',
  sourceCharPosition: 940
},
...]

רוב משך העיבוד מתרחש במהלך ההפעלה של הסקריפט הזה, שהוא input מאזין (הגורם המפעיל הוא INPUT#search-terms.oninput). שם הפונקציה מצוין (handleSearch), וגם מיקום התו בקובץ המקור index.js.

עם זאת, יש נכס חדש: forcedStyleAndLayoutDuration. זהו הזמן שהושקע בהפעלת הסקריפט הזה, שבו הדפדפן נאלץ לבצע פריסה מחדש של הדף. במילים אחרות, 78% מהזמן – 388 אלפיות השנייה מתוך 497 – שהוקדש להרצת רכיב event listener זה, הוקדש למעשה להעמסה (thrashing) של הפריסה.

הבעיה הזו היא בעדיפות ראשונה.

מאזינים חוזרים

כל אחת משתי רשומות הסקריפט הבאות לא בולטת במיוחד:

scripts: [...,
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5375.3,
  executionStart: 5375.3,
  duration: 124,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526,
},
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5673.9,
  executionStart: 5673.9,
  duration: 95,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526
}]

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

הדבר המוזר הוא ששניהם מגיעים מאותו קובץ מקור ומאותו מיקום של התו.

בסופו של דבר, הדפדפן עיבד כמה לחיצות על מקשים בפריים אנימציה יחיד, ולכן רכיב event listener זה פעל פעמיים לפני שניתן היה לצייר משהו!

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

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

7. השהיה לאחר קלט

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

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

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

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

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

בהרבה דפים, עבודה כבדה ב-main thread לא תתנהג בצורה כזו, אבל זו הדגמה טובה שמראה איך אפשר לזהות אותה בנתוני השיוך של INP.

דוגמה לשיוך שמתבסס רק על תיבת החיפוש במהלך קפיצת החילזון:

{
  name: 'INP',
  value: 728,
  rating: 'poor',

  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'pointer',

    inputDelay: 702.3,
    processingDuration: 4.9,
    presentationDelay: 20.8,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 2064.8,
      duration: 790,

      renderStart: 2065,
      styleAndLayoutStart: 2854.2,
      firstUIEventTimestamp: 0,
      blockingDuration: 740,

      scripts: [{...}]
    }]
  }
}

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

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

כאן נכנסים לתמונה רשומות סקריפט של LoAF:

scripts: [{
  name: 'script',
  invoker: 'SPAN.onanimationiteration',
  invokerType: 'event-listener',

  startTime: 2065,
  executionStart: 2065,
  duration: 788,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'cryptodaphneCoinHandler',
  sourceCharPosition: 1831
}]

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

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

8. הצגת העיכוב: כשעדכון לא מוצג

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

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

כיצד הכלי הזה נראה?

{
  name: 'INP',
  value: 376,
  rating: 'needs-improvement',
  delta: 352,

  attribution: {
    interactionTarget: '#sidenav-button>svg',
    interactionType: 'pointer',

    inputDelay: 12.8,
    processingDuration: 14.7,
    presentationDelay: 348.5,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 651,
      duration: 365,

      renderStart: 673.2,
      styleAndLayoutStart: 1004.3,
      firstUIEventTimestamp: 138.6,
      blockingDuration: 315,

      scripts: [{...}]
    }]
  }
}

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

scripts: [{
  entryType: 'script',
  invoker: 'FrameRequestCallback',
  invokerType: 'user-callback',

  startTime: 673.8,
  executionStart: 673.8,
  duration: 330,

  sourceURL: 'http://localhost:8080/js/side-nav.js',
  sourceFunctionName: '',
  sourceCharPosition: 1193,
}]

אם בוחנים את הרשומה היחידה במערך scripts, אפשר לראות שהזמן מושקע ב-user-callback מ-FrameRequestCallback. הפעם העיכוב בהצגת המודעה נגרם בגלל קריאה חוזרת (callback) של requestAnimationFrame.

9. סיכום

צבירה של נתונים מהשטח

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

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

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

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

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

שיוך בכל מקום!

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

עכשיו אתם יכולים להשתמש בנתוני השיוך של INP בכל אתר.

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

const script = document.createElement('script');
script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';
script.onload = function () {
  webVitals.onINP(console.log, {reportAllChanges: true});
};
document.head.appendChild(script);