First Input Delay (FID)

Philip Walton

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

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

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

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

החשיפה הראשונה של המשתמשים היא המהירות שבה האתר נטען בעזרת מדידה. First Contentful Paint (FCP). אבל באיזו מהירות האתר יכול לצבוע פיקסלים שהם רק חלק מהסיפור. לא פחות חשוב הוא מידת התגובה הוא הזמן שבו משתמשים מנסים לבצע אינטראקציה עם הפיקסלים האלה!

המדד 'עיכוב קלט ראשון' (FID) עוזר למדוד את החשיפה הראשונה של המשתמשים האינטראקטיביות והרספונסיביות של האתר.

מה זה FID?

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

מהו דירוג FID טוב?

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

מידע מפורט על FID

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

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

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

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

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

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

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

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

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

מה אם לאינטראקציה אין האזנה לאירועים?

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

לדוגמה, כל רכיבי ה-HTML הבאים צריכים להמתין משימות שמתבצעות ב-thread הראשי שיש להשלים לפני מענה למשתמש אינטראקציות:

• שדות טקסט, תיבות סימון ולחצני בחירה (<input>, <textarea>)
• בחירת תפריטים נפתחים (<select>)
• קישורים (<a>)

למה כדאי להשתמש רק בקלט הראשון?

עיכוב בעדכון קלט כלשהו עלול להוביל לחוויית משתמש גרועה, אבל בעיקר מומלץ למדוד את ההשהיה בקלט הראשון מכמה סיבות:

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

מה נחשב כקלט ראשון?

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

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

במילים אחרות, FID מתמקד ב-R (רספונסיביות) ב-RAIL ביצוע , ואילו גלילה ושינוי מרחק התצוגה קשורים יותר למילה א' (אנימציה) ולביצועים שלה את התכונות צריך להעריך בנפרד.

מה קורה אם משתמש לא מקיים אינטראקציה עם האתר?

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

המשמעות היא שלחלק מהמשתמשים לא יהיו ערכי FID, ולחלק מהמשתמשים יהיה FID נמוך והערכים של המשתמשים, סביר להניח שיהיו להם ערכי FID גבוהים.

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

למה כדאי להביא בחשבון רק את ההשהיה בקלט?

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

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

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

איך למדוד FID

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

כלים לשטח

• חוויית המשתמש ב-Chrome דיווח
• PageSpeed Insights
• Search Console (מדדי הליבה לבדיקת חוויית המשתמש באתר) בדוח)
• ספריית JavaScript של web-vitals

מדידת FID ב-JavaScript

כדי למדוד FID ב-JavaScript, אפשר להשתמש בפונקציה Event Timing API. הדוגמה הבאה מראה איך ליצור PerformanceObserver שמאזינים first-input כל רשומה ורושמת אותן במסוף:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

בדוגמה שלמעלה, ערך ההשהיה של הרשומה first-input נמדד לפי לוקחת את הדלתא בין startTime ל-processingStart חותמות זמן. ברוב המקרים זה יהיה ערך ה-FID. עם זאת, לא כל רשומות first-input תקפות למדידת FID.

בקטע הבא מפורטים ההבדלים בין הדוחות של ה-API לבין האופן שבו המדד מחושב.

ההבדלים בין המדד לבין ה-API

• ה-API ישלח first-input רשומות עבור דפים שנטענו בכרטיסיית רקע, אבל יש להתעלם מדפים אלה בעת חישוב FID.
• בנוסף, ה-API ישלח first-input רשומות אם הדף הועבר לרקע לפני שהקלט הראשון מתרחש, אבל צריך להתעלם גם מהדפים האלה בעת חישוב FID (הקלט משוקלל רק אם הדף היה בחזית כל הזמן).
• ה-API לא מדווח על רשומות first-input כשהדף משוחזר מ- את מטמון לדף הקודם/הבא, אבל FID נמדדים במקרים אלה, מכיוון שהמשתמשים חווים אותם כדף נפרד ביקורים באתר שלך.
• ה-API לא מדווח על קלט שמתרחש בתוך מסגרות iframe, אבל המדד כן כי הן חלק מחוויית המשתמש בדף. מי יכול הבדל בין CrUX ל-RUM. כדי למדוד כראוי FID, כדאי להתייחס אליהם. תמונות משנה יכולות להשתמש ב-API כדי לדווח על רשומות first-input שלהם למסגרת ההורה לצורך צבירה.

במקום לשנן את כל ההבדלים הקלים האלה, מפתחים יכולים להשתמש web-vitals ספריית JavaScript כדי למדוד את FID, שמטפל בהבדלים האלה בשבילכם (כשהדבר אפשרי, שימו לב שהבעיה ב-iframe לא נכללת בו):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

אפשר לעיין בקוד המקור עבור onFID() דוגמה מלאה לאופן שבו אפשר למדוד FID ב-JavaScript.

ניתוח של נתוני FID ודיווח עליהם

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

בעוד בחירה אחוזון לכולם ערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר הם ה-75 בחודש, ובמיוחד FID, מומלץ לבחון את האחוזונים ה-95 עד 99, מכיוון שהם תואמים החוויה הראשונה של משתמשים רעות במיוחד עם האתר שלכם. והיא להציג את התחומים שדורשים שיפור משמעותי.

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

איך לשפר את FID

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

יומן שינויים

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

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

אם יש לכם משוב על המדדים האלה, אתם יכולים לשלוח אותו בקבוצת Google בנושא web-vitals-feedback.