כולנו יודעים עד כמה חשוב ליצור רושם ראשוני טוב. חשוב להכיר אנשים חדשים, וגם חשוב ליצור חוויות באינטרנט.
באינטרנט, רושם ראשוני טוב יכול לעשות את כל ההבדל בין משתמש שיהפוך למשתמש נאמן לבין עזיבה של משתמש שהוא לא יחזור אליו אף פעם. השאלה היא מה גורם ליצירת רושם טוב, ואיך אפשר למדוד את סוג הרושם שאתם מקבלים על המשתמשים.
באינטרנט לרושם הראשוני יש הרבה צורות שונות - הרושם הראשוני שהעיצוב של האתר והמראה שלו מושכים את העין, כמו גם רושם ראשוני על המהירות והמהירות שלו.
אמנם קשה למדוד עד כמה המשתמשים אוהבים עיצוב אתר באמצעות ממשקי API לאינטרנט, אך מדידת המהירות והמהירות של האתר לא נמדדת!
בעזרת הצגת תוכן ראשוני (FCP), המשתמשים מקבלים את הרושם הראשוני של מהירות הטעינה של האתר שלכם. אבל המהירות שבה האתר שלכם יכול לצבוע פיקסלים על המסך היא רק חלק מהסיפור. חשוב גם לדעת עד כמה האתר רספונסיבי כשמשתמשים מנסים לקיים אינטראקציה עם הפיקסלים האלה!
המדד'עיכוב בקלט ראשון' (FID) עוזר למדוד את הרושם הראשוני של המשתמשים לגבי האינטראקטיביות והמהירות של האתר.
מה זה FID?
FID מודד את הזמן מרגע האינטראקציה הראשונה של משתמש עם הדף (כלומר, כשהוא לוחץ על קישור, מקישים על לחצן או משתמש בפקד מותאם אישית שמופעל על ידי JavaScript) עד לרגע שבו הדפדפן יכול להתחיל לעבד אירועים (handlers) בתגובה לאינטראקציה.
מהו ציון FID טוב?
כדי לספק חוויית משתמש טובה, אתרים צריכים לשאוף לעיכוב של 100 אלפיות השנייה לכל היותר בזמן הקלט הראשון. כדי להבטיח שאתם עומדים ביעד הזה בשביל רוב המשתמשים, סף טוב למדידה הוא האחוזון ה-75 של טעינות דפים, שמפולחות בין מכשירים ניידים ומחשבים.
מידע מפורט על FID
כמפתחים שכותבים קוד שמגיב לאירועים, אנחנו מניחים לעיתים קרובות שהקוד שלנו יופעל באופן מיידי – ברגע שהאירוע מתרחש. אבל כמשתמשים, כולנו חווינו הרבה את ההפך - טענו דף אינטרנט בטלפון, ניסינו ליצור איתו אינטראקציה, ואחר כך היו מתוסכלים כשלא קרה כלום.
באופן כללי, עיכוב קלט (שנקרא גם זמן אחזור של קלט) מתרחש כי ה-thread הראשי של הדפדפן עסוק בביצוע פעולה אחרת, ולכן הוא לא יכול (עדיין) להגיב למשתמש. אחת הסיבות הנפוצות לכך היא שהדפדפן עסוק בניתוח ובהפעלה של קובץ JavaScript גדול שנטען על ידי האפליקציה. בזמן הזה האפליקציה לא יכולה להפעיל פונקציות event listener, כי יכול להיות שקוד ה-JavaScript שנטען ינקוט פעולה אחרת.
כדאי להביא בחשבון את ציר הזמן הבא של טעינה אופיינית של דף אינטרנט:
בתצוגה החזותית שלמעלה מוצג דף ששולח כמה בקשות רשת למשאבים (סביר להניח קובצי CSS ו-JS), ואחרי שהורדת המשאבים האלה מסתיימת, הם מעובדים ב-thread הראשי.
זה גורם למקרים שבהם ה-thread הראשי עמוס לרגע, וזה מצוין על ידי בלוקי המשימות בצבע בז'.
בדרך כלל, עיכובים ארוכים בהצגת התוכן הראשון מתרחשים בין First Contentful Paint (FCP) ל-Time to Interactive (TTI) כי חלק מהתוכן בדף מעבד, אבל הוא עדיין לא אינטראקטיבי בצורה אמינה. כדי להמחיש איך זה יכול לקרות, נוספו לציר הזמן FCP ו-TTI:
אולי שמתם לב שיש די זמן (כולל שלוש משימות ארוכות) בין ה-FCP ל-TTI, אם משתמש מנסה לבצע אינטראקציה עם הדף בפרק זמן זה (למשל, על ידי לחיצה על קישור), יהיה עיכוב בין מועד קבלת הקליק לבין המועד שבו ה-thread הראשי יכול להגיב.
חשבו מה היה קורה אם משתמש היה מנסה ליצור אינטראקציה עם הדף לקראת תחילת המשימה הארוכה ביותר:
מכיוון שהקלט מתרחש בזמן שהדפדפן נמצא באמצע ההרצה של משימה, צריך להמתין עד שהמשימה מסתיימת כדי להגיב לקלט. הזמן שצריך להמתין הוא ערך ה-FID של המשתמש הזה בדף הזה.
מה קורה אם לאינטראקציה אין event listener?
FID מודד את הדלתא שבין מועד קבלת אירוע קלט לבין המועד שבו ה-thread הראשי לא פעיל בפעם הבאה. כלומר, FID נמדד גם במקרים שבהם לא בוצעה רישום של האזנה לאירועים. הסיבה לכך היא שאינטראקציות רבות של משתמשים לא מחייבות האזנה לאירועים, אבל כן ה-thread הראשי צריך להיות לא פעיל כדי להפעיל אותן.
לדוגמה, כל רכיבי ה-HTML הבאים צריכים להמתין עד שמשימות מתבצעות ב-thread הראשי כדי שיסתיימו לפני שהן יגיבו לאינטראקציות של המשתמשים:
- שדות טקסט, תיבות סימון ולחצני בחירה (
<input>,<textarea>) - בחירת תפריטים נפתחים (
<select>) - קישורים (
<a>)
למה כדאי להתחשב רק בקלט הראשון?
אמנם עיכוב בכל קלט עלול לפגוע בחוויית המשתמש, אבל מומלץ למדוד את העיכוב הראשון בקלט, מכמה סיבות:
- העיכוב הראשון בקלט יהיה ההתרשמות הראשונה של המשתמש ממהירות התגובה של האתר, והחשיפות הראשונות הן חיוניות ליצירת הרושם הכולל על האיכות והאמינות של האתר.
- הבעיות הכי משמעותיות באינטראקטיביות שאנחנו רואים באינטרנט היום מתרחשות במהלך טעינת דפים. לכן, לדעתנו התמקדות בהתחלה בשיפור האינטראקציה הראשונה של המשתמש עם האתר תשפיע במידה הרבה ביותר על שיפור האינטראקציה הכוללת באינטרנט.
- הפתרונות המומלצים שמסבירים איך אתרים צריכים לתקן עיכובים ארוכים בקלט הראשון (פיצול קוד, טעינה פחות JavaScript מראש וכו') הם לא בהכרח אותם פתרונות לתיקון עיכובים בקלט ראשון לאחר טעינת דף. הפרדה בין המדדים האלה תאפשר לנו לספק למפתחי אינטרנט הנחיות ספציפיות יותר לגבי ביצועים.
מה נחשב כקלט ראשון?
FID הוא מדד שמודד את רמת הרספונסיביות של דף במהלך הטעינה. לכן, היא מתמקדת רק באירועי קלט מפעולות נפרדות כמו לחיצות, הקשות והקשות על מקשים.
אינטראקציות אחרות, כמו גלילה ושינוי מרחק התצוגה, הן פעולות מתמשכות שיש להן אילוצי ביצועים שונים לחלוטין (בנוסף, לעיתים קרובות דפדפנים יכולים להסתיר את זמן האחזור על ידי הרצתם בשרשור נפרד).
במילים אחרות, FID מתמקד ב-R (תגובתיות) במודל הביצועים של RaIL, ואילו הגלילה ושינוי מרחק התצוגה קשורים יותר ל-A (אנימציה), ויש להעריך את תכונות הביצועים שלהם בנפרד.
מה קורה אם משתמש לעולם לא יוצר אינטראקציה עם האתר?
לא כל המשתמשים ייצרו אינטראקציה עם האתר בכל פעם שהם נכנסים אליו. ולא כל האינטראקציות רלוונטיות ל-FID (כפי שצוין בקטע הקודם). בנוסף, חלק מהאינטראקציות הראשונות של המשתמשים מתרחשות בזמנים לא טובים (כשה-thread הראשי עמוס במשך פרק זמן ארוך), והאינטראקציות הראשונות של המשתמש שלו מתבצעות בזמנים טובים (כשה-thread הראשי לא פעיל לגמרי).
המשמעות היא שלמשתמשים מסוימים לא יהיו ערכי 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שלהן למסגרת ההורה לצורך צבירה.
במקום לזכור את כל ההבדלים הקלים האלה, מפתחים יכולים להשתמש בספריית 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.