דף זה תורגם על ידי Cloud Translation API.

First Input Delay (FID)

Philip Walton

תמיכה בדפדפן

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

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

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

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

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

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

מהו FID?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלים לשטח

מדידת 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 במסוף ולחשב את ההשהיה שלהן. עם זאת, מדידת FID ב-JavaScript מורכבת יותר. הפרטים מופיעים בהמשך:

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

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

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

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

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

יומן שינויים

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

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

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