First Input Delay (FID)

Philip Walton

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

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

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

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

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

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

מהו FID?

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

מהו ציון FID טוב?

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

FID בפירוט

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

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

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

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

כתוצאה מכך, יש תקופות שבהן ה-thread הראשי עמוס לרגע, כפי שמצוין בבלוק הtask בצבע בז'.

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

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

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

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

מה קורה אם לא מוגדרת אינטראקציה למעקב אחרי אירועים?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

למה צריך להביא בחשבון רק את זמן האחזור של הקלט?

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

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

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

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

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

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

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

איך משפרים את FID

יש מדריך מלא בנושא אופטימיזציה של FID שמסביר איך לשפר את המדד הזה.

יומן שינויים

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

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

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