First Input Delay (FID)

Philip Walton

Browser Support

  • Chrome: 76.
  • Edge: 79.
  • Firefox: 89.
  • Safari: 26.2.

Source

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

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

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

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

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

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

מה זה FID?

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

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

כדי לספק חוויית משתמש טובה, אתרים צריכים לשאוף ל-First Input Delay (זמן התגובה הראשוני לקלט) של 100 אלפיות השנייה או פחות. כדי לוודא שביצועי האתר עונים על הציפיות של רוב המשתמשים ביחס למדד הזה, ערך הסף המומלץ למדידה הוא האחוזון ה-75 של טעינות הדפים (כלומר, 75% מחוויות הטעינה צריכות לעמוד ביעד). כדאי לנתח את הנתונים האלה במחשבים ובמכשירים ניידים בנפרד.

ערכי FID טובים הם 2.5 שניות או פחות, ערכים גרועים הם מעל 4.0 שניות, וכל ערך ביניהם מצביע על צורך בשיפור

פירוט של FID

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

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

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

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

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

התוצאה היא תקופות שבהן ה-thread הראשי עמוס לזמן קצר, וזה מסומן על ידי בלוקים של משימות בצבע בז'.

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

דוגמה למעקב אחר טעינת דף עם FCP ו-TTI

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

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

דוגמה למעקב אחר טעינת דף עם FCP,‏ TTI ו-FID

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

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

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

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

כלים בשטח

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

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

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

איך לשפר את ה-FID

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

יומן שינויים

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

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

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