המטרה של הדוח על חוויית המשתמש ב-Chrome היא לעזור לקהילת האינטרנט להבין את ההתפלגות וההתפתחות של ביצועי משתמשים. עד היום התמקדנו במדדים של הצגת תוכן וטעינת דפים כמו First Contentful Paint (FCP) ו-Onload (OL), שעזרו לנו להבין את הביצועים ויזואליים של המשתמשים באתרים. מתחיל ב- במהדורת יוני 2018 אנחנו עורכים ניסוי עם מדד חדש שמתמקד במשתמשים מתמקד באינטראקטיביות של דפי אינטרנט: עיכוב בקלט הראשון (FID). המדד החדש יאפשר לנו להבין טוב יותר עד כמה הם צריכים להזין את הקלט של המשתמשים.
FID הפך לאחרונה לזמין ב-Chrome מקור לניסיון, כלומר, אתרים יכולים להביע הסכמה להתנסות בפלטפורמת האינטרנט החדשה הזו . באופן דומה, 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 איטיים יותר, כנראה בגלל חומרה איטית יותר בהשוואה ל- במחשבים שולחניים. אם המעבד (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 שמכיל הרבה תמונות, אבל יש בו 168KB JavaScript שרץ תוך 500 אלפיות השנייה במכונה לשיעור ה-Lab שלנו. זה לא מאוד כמות JavaScript גדולה, בהתאם לארכיון HTTP, שמציב את הדף הזה באחוזון ה-28.
הסרגל הוורוד באורך של 2.7 עד 3.0 שניות הוא השלב ניתוח HTML. במהלך הזמן שבו הדף לא אינטראקטיבי ונראה שהוא לא שלם (ראו 3.0 שניות). ברצועת השקפים שלמעלה). לאחר מכן, כל המשימות הארוכות שצריך לעבור עיבוד מחולקים כדי להבטיח שהשרשור הראשי יישאר במצב שקט. הקווים הוורודים שורה 11 ממחישה את הפריסה של עבודת JavaScript בפרקים מהירים.
דוגמה 2: https://www.wtfast.com
במקור הזה יש 96% FID מיידי לחוויות שונות. הוא טוען 267KB של JavaScript (האחוזון ה-38 ב-HTTP Archive) ומעבד אותו למשך 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.