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

1. מבוא

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

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

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

מה תלמדו

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

מה צריך

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

2. להגדרה

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

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

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

איך משתמשים בדף

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי למדוד את ה-INP ב-codelab הזה, אנחנו רוצים את גרסת השיוך (Attribution).

מוסיפים את 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>

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

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

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

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

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

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

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

טייק אוויי

מה אפשר ללמוד על המקרה הזה מנתוני הייחוס האלה?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. סיכום

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

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

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

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

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

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

ייחוס בכל מקום!

שיוך מבוסס-LoAF של מדד ה-INP הוא כלי יעיל לניפוי באגים. הוא מספק נתונים מפורטים על מה שקרה בדיוק במהלך ה-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);

מידע נוסף

• ‫web.dev: מהירות התגובה לאינטראקציה באתר
• ‫web.dev: איתור אינטראקציות איטיות בשטח
• ‫web.dev: אופטימיזציה של מהירות התגובה לאינטראקציה באתר
• ‫Codelab בנושא INP