המטרה של הדוח לגבי חוויית המשתמש ב-Chrome היא לעזור לקהילת האינטרנט להבין את ההפצה וההתפתחות של ביצועי המשתמשים האמיתיים. עד כה, התמקדנו במדדי צבע וטעינת דפים, כמו הצגת תוכן ראשוני (FCP) ו-Onload (OL). המדדים האלה עוזרים לנו להבין את הביצועים הויזואלית של אתרים עבור המשתמשים. החל מגרסה יוני 2018, אנחנו עורכים ניסויים במדד חדש שמתמקד במשתמשים, שמתמקד באינטראקטיביות של דפי אינטרנט: השהיה לאחר קלט ראשוני (FID). המדד החדש יאפשר לנו להבין טוב יותר עד כמה אתרים רספונסיביים לקלט של משתמשים.
לאחרונה הופצו ב-Chrome FID כגרסת מקור לניסיון, והמשמעות היא שאתרים יכולים להתנסות בתכונה החדשה הזו של פלטפורמת האינטרנט. באופן דומה, FID יהיה זמין בדוח חוויית המשתמש ב-Chrome כמדד ניסיוני, כלומר הוא יהיה זמין במהלך תקופת המקור לניסיון בתוך מרחב שמות "ניסיוני" נפרד.
איך מודדים FID
אז מה זה בדיוק FID? כך הוא מוגדר בפוסט השהיה לאחר קלט ראשוני בבלוג:
'השהיה לאחר קלט ראשוני' (FID) הוא מדד שמודד את הזמן שעובר מהרגע שבו משתמש מקיים אינטראקציה ראשונה עם האתר (כלומר, מקליק על קישור, מקישים על לחצן או משתמש בפקד מותאם אישית שמופעל על ידי JavaScript) ועד הזמן שבו הדפדפן מסוגל להגיב לאותה אינטראקציה.
הדבר דומה למדידת הזמן שעובר מהרגע שמישהו מצלצל בפעמון הדלת ועד שהוא עונה על הדלת. אם התהליך נמשך זמן רב, יכולות להיות לכך הרבה סיבות. לדוגמה, יכול להיות שהאדם רחוק מהדלת או שהוא לא יכול לזוז במהירות. באופן דומה, דפי אינטרנט עשויים להיות עמוסים בעבודה אחרת או שהמכשיר של המשתמש עלול לפעול באיטיות.
סקירת FID בדוח חוויית המשתמש ב-Chrome
עם חודש אחד של נתוני FID ממיליוני מקורות, יש שפע של תובנות מעניינות שעלינו לגלות. בואו נבחן כמה שאילתות שמדגימות איך להפיק את התובנות האלה מדוח חוויית המשתמש של Chrome ב-BigQuery.
נתחיל להריץ שאילתה לגבי אחוז חוויות ה-FID המהירות באתר developers.google.com. אפשר להגדיר חוויה מהירה שבה FID הוא פחות מ-100 אלפיות השנייה. לפי המלצות של RAIL, אם העיכוב הוא של 100 אלפיות השנייה או יותר, הוא אמור להיראות מיד למשתמש.
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
origin = 'https://developers.google.com'
התוצאות מראות ש-95% מחוויות FID במקור הזה נתפסות כפעולות מיידיות. זה נראה ממש טוב, אבל איך זה בהשוואה לכל המקורות במערך הנתונים?
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
התוצאות של השאילתה הזו מראות ש-84% מחוויות FID הן באורך של פחות מ-100 אלפיות השנייה. לפיכך, הכתובת Developers.google.com היא מעל הממוצע.
בשלב הבא ננסה לפלח את הנתונים כדי לראות אם יש הבדל בין שיעור ה-FID המהיר במחשב לבין אחוז ה-FID המהיר. השערה אחת היא שלמכשירים ניידים יש ערכי FID איטיים יותר, כנראה בגלל חומרה איטית יותר בהשוואה למחשבים שולחניים. אם המעבד (CPU) פחות חזק, הוא עלול להיות עמוס יותר למשך זמן ארוך יותר וחוויית FID איטית יותר.
SELECT
form_factor.name AS form_factor,
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
form_factor
| form_factor | fast_fid |
|---|---|
| desktop, שולחן עבודה, דסקטופ | 96.02% |
| טלפון | 79.90% |
| טאבלט | 76.48% |
התוצאות מחזקות את ההשערה שלנו. במחשבים שולחניים יש צפיפות מצטברת גבוהה יותר של חוויות FID מהירות לעומת גורמי צורה של טלפון וטאבלטים. כדי להבין למה קיימים ההבדלים האלה, כמו הביצועים של המעבד (CPU), תצטרכו לבצע בדיקות A/B שלא נכללות בדוח חוויית המשתמש ב-Chrome.
אחרי שראינו איך לזהות אם למקור יש ניסיון FID מהיר, עכשיו נבחן כמה מקורות שמניבים ביצועים טובים מאוד.
דוגמה 1: http://secretlycanadian.com
במקור הזה יש 98% מחוויות FID באורך של פחות מ-100 אלפיות השנייה. איך עושים את זה? אנחנו מנתחים את העיצוב של האתר ב-WebPageTest כדי לראות שהוא דף WordPress עם הרבה תמונות, אבל יש בו 168 KB של JavaScript שפועל במשך כ-500 אלפיות השנייה במכשיר ה-Lab שלנו. לפי ארכיון HTTP, לא מדובר ביותר מדי JavaScript, ולכן הדף נמצא באחוזון ה-28.
העמודה הוורודה שנמשכת 2.7 עד 3.0 שניות היא שלב ניתוח HTML. במהלך פרק הזמן הזה הדף לא אינטראקטיבי ונראה שהוא לא שלם (ראו '3.0 שניות' ברצועת התמונות שלמעלה). לאחר מכן, כל המשימות הארוכות שצריך לעבד יפוצלו כדי להבטיח שה-thread הראשי יישאר רציף. הקווים הוורודים בשורה 11 מדגימים איך עבודת ה-JavaScript מתחלקת ברצפים מהירים.
דוגמה 2: https://www.wtfast.com
במקור הזה יש 96% חוויות FID מיידיות. תתבצע טעינה של 267KB של JavaScript (המאון ה-38 בארכיון HTTP) ועיבודו למשך 900 אלפיות שנייה במחשב בשיעור ה-Lab. רצועת התמונות מראה שנדרשות לדף כ-5 שניות כדי לצבוע את הרקע, וכ-2 שניות נוספות כדי לצבוע את התוכן.
מה שהכי מעניין בתוצאות הוא ששום דבר אינטראקטיבי לא גלוי אפילו כשה-thread הראשי עמוס בין 3 ל-5 שניות. למעשה, האיטיות של ה-FCP של הדף הזה היא שמשפרת את ה-FID. זו דוגמה טובה לחשיבות של שימוש בערכים רבים לייצוג חוויית המשתמש.
יש הרבה מה לגלות
תוכלו לקבל מידע נוסף על FID בפרק השבוע של The State of the Web:
השימוש ב-FID בדוח חוויית המשתמש ב-Chrome מאפשר לנו ליצור בסיס של חוויות אינטראקטיביות. על סמך רמת הבסיס הזו, אפשר לראות את השינוי בגרסאות עתידיות או בדוח על מקורות ספציפיים של בנצ'מרק. אם אתם רוצים להתחיל לאסוף FID במדידות השדות באתר שלכם, תוכלו להירשם לגרסת המקור לניסיון בכתובת bit.ly/event-timing-ot ולבחור בתכונה 'תזמון אירוע'. וכמובן, התחילו לחקור את מערך הנתונים כדי לקבל תובנות מעניינות על מצב האינטראקטיביות באינטרנט. המדד הזה עדיין ניסיוני, אז נשמח לקבל ממך משוב ולשתף את הניתוח בקבוצת הדיון של דוח חוויית המשתמש של Chrome או ב-@ChromeUXReport ב-Twitter.