למה כלים שעוקבים אחר מדדי הליבה לבדיקת חוויית המשתמש באתר עשויים לדווח על מספרים שונים, ואיך לפרש את ההבדלים האלה.
Google מספקת כמה כלים שעוזרים לבעלי אתרים לעקוב אחרי הציונים שלהם במדדי הליבה לבדיקת חוויית המשתמש באתר. הכלים האלה שייכים לשתי קטגוריות עיקריות:
- כלים שמדווחים על נתוני שיעור Lab – נתונים שנאספים בסביבה מבוקרת עם הגדרות מוגדרות מראש של מכשירים ורשתות.
- כלים שמדווחים על נתוני שטח – נתונים שנאספים ממשתמשים אמיתיים שמבקרים באתר.
הבעיה היא שלפעמים הנתונים שמדווחים על ידי כלי מעבדה יכולים להיות די שונים מאלה שמדווחים על ידי הכלים שבשטח! נתוני שיעור ה-Lab עשויים להצביע על כך שהאתר שלכם מניב ביצועים טובים, אבל נתוני השטח מצביעים על כך שצריך לשפר אותו. לחלופין, נתוני השטח עשויים לציין שכל הדפים שלכם טובים, אבל בנתוני שיעור ה-Lab עלול להופיע ציון נמוך מאוד.
הדוגמה האמיתית הבאה של דוח PageSpeed Insights מ-web.dev מראה שבמקרים מסוימים, נתוני המעבדה והנתונים מהשדות יכולים להיות שונים בכל מדדי הליבה לבדיקת חוויית המשתמש באתר:
ההבדלים בין כלים הם מקור מובן לבלבול אצל המפתחים. בפוסט הזה נסביר את הסיבות העיקריות להבדלים האלה, כולל דוגמאות ספציפיות שמתייחסות לכל אחד מהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר, ומה לעשות אם הבחנתם בהבדלים בדפים.
נתוני מעבדה לעומת נתוני שטח
כדי להבין למה כלים של מעבדה ושדות עשויים לדווח על ערכים שונים – גם אם מדובר באותו דף אינטרנט בדיוק – צריך להבין את ההבדל בין נתוני השיעורים לבין נתוני השדות.
נתוני מעבדה
נתוני שיעור ה-Lab נקבעים על ידי טעינת דף אינטרנט בסביבה מבוקרת עם קבוצה מוגדרת מראש של תנאי הרשת והמכשיר. התנאים האלה ידועים כסביבת Lab, ולפעמים נקראת גם סביבה סינתטית.
בדרך כלל, כלי Chrome שמדווחים על נתונים משיעור Lab מריצים את Lighthouse.
מטרת הבדיקה במעבדה היא לשלוט בכמה שיותר גורמים, כך שהתוצאות יהיו עקביות (עד כמה שאפשר) שניתן יהיה לחזור עליהן מהרצה ועד ריצה.
נתוני שדה
נתוני השדות נקבעים על ידי מעקב אחרי כל המשתמשים שמבקרים בדף, ומדידה של מדדי ביצועים ביחס לכל אחת מחוויית המשתמשים. נתוני השדות מבוססים על ביקורים של משתמשים אמיתיים, ולכן הם משקפים את המכשירים בפועל, את תנאי הרשת ואת המיקומים הגיאוגרפיים של המשתמשים.
נתוני השדות נקראים גם נתוני Real User Monitoring (RUM); שני המונחים ניתנים להחלפה.
כלי Chrome שמדווחים על נתוני שדות בדרך כלל מקבלים את הנתונים האלה מדוח חוויית המשתמש ב-Chrome (CrUX). בנוסף, מקובל (ומומלץ) לבעלי אתרים לאסוף נתוני שדות בעצמם, כי זה יכול לספק תובנות פרקטיות יותר מאשר רק שימוש ב-crUX בלבד.
הדבר שהכי חשוב להבין לגבי נתוני שדות הוא לא רק מספר אחד, אלא התפלגות של מספרים. כלומר, ייתכן שעבור חלק מהאנשים שמבקרים באתר שלכם הוא ייטען במהירות רבה, ואחרים עשויים להיטען לאט מאוד. נתוני השדות של האתר הם הקבוצה המלאה של כל נתוני הביצועים שנאספים מהמשתמשים.
לדוגמה, דוחות CrUX מציגים התפלגות של מדדי ביצועים ממשתמשי Chrome אמיתיים על פני תקופה של 28 ימים. אם תסתכלו כמעט על כל דוח של CrUX, תוכלו לראות שמשתמשים מסוימים שמבקרים באתר עשויים ליהנות מחוויה טובה מאוד, בעוד שמשתמשים אחרים עלולים לחוות חוויה גרועה מאוד.
אם הכלי מדווח על מספר אחד למדד מסוים, הוא בדרך כלל משקף נקודה ספציפית בהתפלגות. כלים שמדווחים על ציונים בשדות של מדדי ליבה לבדיקת חוויית המשתמש באתר עושים זאת באמצעות האחוזון ה-75.
כשבודקים את ה-LCP מנתוני השדה בצילום המסך שלמעלה, אפשר לראות התפלגות שבה:
- ב-88% מהביקורים היה ערך LCP של 2.5 שניות או פחות (טוב).
- ב-8% מהביקורים הוצג LCP בין 2.5 ל-4 שניות (דרוש שיפור).
- ב-4% מהביקורים הוצג LCP במשך יותר מ-4 שניות (חלש).
במאון ה-75, מדד ה-LCP היה 1.8 שניות:
בנתוני Lab מאותו דף מוצג ערך LCP של 3.0 שניות. הערך הזה גדול מ-1.8 השניות שמוצגות בנתוני השדה, אבל הוא עדיין ערך LCP תקין לדף הזה – הוא אחד מהערכים הרבים שמרכיבים את ההתפלגות המלאה של חוויות הטעינה.
למה הנתונים מהמעבדה ומהשדות שונים
כמו שמוסבר בקטע שלמעלה, נתוני מעבדה ונתוני שדות מודדים בפועל דברים שונים מאוד.
נתוני השדות כוללים מגוון רחב של תנאי רשת ומכשירים, וגם מגוון סוגים שונים של התנהגות משתמשים. הוא כולל גם גורמים אחרים שמשפיעים על חוויית המשתמש, כמו אופטימיזציה של הדפדפן כמו המטמון לדף הקודם/הבא (bfcache), או אופטימיזציה של פלטפורמה כמו מטמון AMP.
לעומת זאת, נתונים של שיעור Lab מגבילים באופן מכוון את מספר המשתנים שמעורבים. בדיקת מעבדה כוללת:
- מכשיר יחיד...
- מחובר לרשת אחת...
- שפועלים ממיקום גיאוגרפי אחד.
הפרטים של כל בדיקת מעבדה נתונה עשויים לייצג באופן מדויק את האחוזון ה-75 של נתוני השדות לדף או לאתר נתון.
סביבה מבוקרת בשיעור ה-Lab שימושית לניפוי באגים או לבדיקת תכונות לפני הפריסה לסביבת הייצור, אבל כשמבצעים שליטה בגורמים האלה לא מציינים במפורש את השונות בעולם האמיתי, בכל סוגי הרשתות, יכולות המכשירים או המיקומים הגיאוגרפיים. בדרך כלל אתם גם לא מתעדים את ההשפעה על הביצועים של התנהגות המשתמשים בפועל, כמו גלילה, בחירת טקסט או הקשה על רכיבים בדף.
בנוסף לניתוק האפשרי בין תנאי שיעור ה-Lab והתנאים של רוב המשתמשים בפועל, יש גם כמה הבדלים קלים שחשוב להבין כדי להפיק את המקסימום מהנתונים של שיעור ה-Lab והשדה, וגם את ההבדלים שאתם עשויים לגלות.
בקטעים הבאים נפרט את הסיבות הנפוצות ביותר שיכולות לגרום להבדלים בין נתוני שיעור ה-Lab לבין נתוני השטח של כל אחד מערכי הליבה של חוויית המשתמש באתר:
- המהירות שבה נטען רכיב התוכן הכי גדול (LCP)
- אינטראקציה עם הצגת התמונה הבאה (INP)
- Cumulative Layout Shift (CLS)
LCP
רכיבי LCP שונים
ייתכן שרכיב ה-LCP שזוהה בבדיקת מעבדה לא אותו רכיב LCP שמשתמשים רואים כשהם נכנסים לדף שלך.
אם מריצים דוח Lighthouse על דף מסוים, הוא יחזיר את אותו אלמנט LP בכל פעם. אבל כשבוחנים את נתוני השדות של אותו הדף, בדרך כלל אפשר למצוא מגוון רכיבי LCP שונים, שתלויים במספר נסיבות שספציפיות לכל ביקור בדף.
לדוגמה, כל הגורמים הבאים יכולים לתרום לקביעת רכיב LCP שונה באותו הדף:
- בגלל גדלים שונים של מסכים במכשיר, אלמנטים שונים מופיעים באזור התצוגה.
- אם המשתמש מחובר לחשבון, או אם תוכן מותאם אישית מוצג באופן מסוים, רכיב ה-LCP עשוי להיות שונה מאוד ממשתמש למשתמש.
- בדומה לנקודה הקודמת, אם בדיקת A/B פועלת בדף, ייתכן שיוצגו רכיבים שונים מאוד.
- קבוצת הגופנים שמותקנים במערכת של המשתמש יכולה להשפיע על גודל הטקסט בדף (ולכן איזה רכיב הוא רכיב ה-LCP).
- בדיקות מעבדה פועלות בדרך כלל בכתובת ה-URL ה'בסיסית' של דף – בלי להוסיף פרמטרים של שאילתה או קטעי גיבוב (hash). אבל בעולם האמיתי, משתמשים בדרך כלל משתפים כתובות URL שמכילות מזהה מקטע או מקטע טקסט, לכן יכול להיות שאלמנט ה-LCP הוא למעשה באמצע או החלק התחתון של הדף (במקום 'בחלק העליון והקבוע').
מאחר ש-LCP בשדה מחושב כאחוזון ה-75 של כל הכניסות של המשתמשים לדף, אם לאחוז גדול מהמשתמשים האלה היה רכיב LCP שנטען במהירות רבה, למשל פסקה של טקסט שמעובדת עם גופן המערכת — אז גם אם לחלק מהמשתמשים האלה הייתה תמונה גדולה שנטענת לאט בתור אלמנט ה-LCP שלהם, ייתכן שזה לא ישפיע על הציון של אותו דף אם הוא היה נמוך מ-2%.
יכולים להיות גם ההפך. בדיקת מעבדה עשויה לזהות בלוק של טקסט כרכיב ה-LCP, כי הוא מבצע אמולציה של טלפון Moto G4 עם אזור תצוגה קטן יחסית, והתמונה הראשית של הדף מוצגת בהתחלה מחוץ למסך. עם זאת, נתוני השטח עשויים לכלול בעיקר משתמשי Pixel XL עם מסכים גדולים יותר, ולכן עבורם תמונה ראשית (Hero) שנטענת לאט היא אלמנט ה-LCP שלהם.
ההשפעות של מצב המטמון ב-LCP
בדרך כלל, בדיקות מעבדה טוענים דף עם מטמון קר, אבל כשמשתמשים אמיתיים מבקרים בדף הזה, יכול להיות שחלק מהמשאבים שלו כבר שמורים במטמון.
בפעם הראשונה שמשתמש יטען דף, יכול להיות שהוא ייטען לאט, אבל אם מוגדרת בו שמירה מתאימה במטמון, יכול להיות שבפעם הבאה שהמשתמש יחזיר את הדף הוא ייטען מיד.
חלק מהכלים לשיעור ה-Lab תומכים במספר הפעלות של אותו דף (כדי לדמות את החוויה למבקרים חוזרים), אבל אין אפשרות שכלי ה-Lab יוכל לדעת איזה אחוז מהביקורים בפועל מתרחשים ממשתמשים חדשים לעומת משתמשים חוזרים.
אתרים עם הגדרות מטמון שעברו אופטימיזציה והרבה מבקרים חוזרים עשויים לגלות שה-LCP בעולם האמיתי שלהם הרבה יותר מהיר ממה שמוצג בנתוני המעבדה.
אופטימיזציה של AMP או Signed Exchange
אתרי אגרגטור של תוכן כמו חיפוש Google יכולים לטעון מראש אתרים שנוצרו באמצעות AMP או אתרים שמשתמשים ב-Signed Exchange (SXG). התוצאה יכולה לשפר משמעותית את ביצועי הטעינה למשתמשים שמבקרים בדפים שלכם מהפלטפורמות האלה.
בנוסף לטעינה מראש של מקורות שונים, האתרים עצמם יכולים לטעון מראש תוכן בדפים הבאים באתר, וזה יכול לשפר את ה-LCP גם בדפים האלה.
כלי Lab לא מדמים את הרווחים שמתקבלים מהאופטימיזציות האלה, וגם אם הם היו עושים זאת, הם לא היו יכולים לדעת איזה אחוז מתנועת הגולשים מגיע מפלטפורמות כמו חיפוש Google בהשוואה למקורות אחרים.
ההשפעות של מטמון לדף הקודם/הבא על LCP
כשדפים משוחזרים מהמטמון לדף הקודם/הבא, חוויית הטעינה מתבצעת כמעט מיד והחוויות האלה נכללות בנתוני השדה.
בבדיקות מעבדה לא נלקחו בחשבון bfcache, כך שאם הדפים שלכם ידידותיים למטמון, סביר להניח שהם יגרמו לציוני LCP מהירים יותר שידווחו בשדה.
השפעות של אינטראקציה משתמש על LCP
LCP מזהה את זמן הרינדור של התמונה או גוש הטקסט הגדולים ביותר באזור התצוגה, אבל הרכיב הגדול ביותר יכול להשתנות במהלך טעינת הדף או כשתוכן חדש נוסף באופן דינמי לאזור התצוגה.
בשיעור ה-Lab, הדפדפן ימתין עד שהדף ייטען במלואו לפני שיוכל לקבוע מהו רכיב ה-LCP. אבל בשדה, הדפדפן יפסיק לעקוב אחרי רכיבים גדולים יותר אחרי שהמשתמש גולל בדף או יוצר איתו אינטראקציה.
זה הגיוני (והכרחי) כי בדרך כלל משתמשים ימתינו לאינטראקציה עם הדף עד שהוא "מופיע", וזה בדיוק מה שמדד ה-LCP נועד לזהות. בנוסף, לא כדאי להחשיב רכיבים שנוספו לאזור התצוגה אחרי אינטראקציה של משתמש, כי יכול להיות שהרכיבים האלה נטענו רק בגלל פעולה כלשהי שהמשתמש ביצע.
עם זאת, המשמעות היא שנתוני השדות של הדף עשויים להופיע מהר יותר ב-LCP, בהתאם להתנהגות המשתמשים בדף.
INP
ל-INP נדרשת אינטראקציה עם משתמשים אמיתיים
מדד INP מודד את מידת הרספונסיביות של הדף לאינטראקציות של משתמשים, במועד שבו המשתמשים בחרו בפועל ליצור איתו אינטראקציה.
החלק השני של המשפט הזה הוא קריטי, כי בדיקות מעבדה, אפילו כאלה שתומכות בהתנהגות המשתמשים בסקריפט, לא יכולות לחזות במדויק מתי משתמשים יבחרו לקיים אינטראקציה עם דף, ולכן הן לא יכולות למדוד במדויק את FID.
ב-TBT לא נלקחים בחשבון התנהגות המשתמשים
המדד זמן חסימה כולל (TBT) עוזר לאבחן בעיות ב-INP כי הוא מכמת את מידת החסימה של ה-thread הראשי במהלך טעינת הדף.
הרעיון הוא שיש סיכוי גבוה יותר ש-thread ראשי חסום בדפים עם הרבה JavaScript סינכרוני או משימות עיבוד אינטנסיביות אחרות בזמן האינטראקציה הראשונה של המשתמש. עם זאת, אם המשתמשים ימתינו לאינטראקציה עם הדף עד לסיום הפעלת ה-JavaScript, ייתכן שה-INP יהיה נמוך מאוד.
מקרים שבהם משתמשים יבחרו לבצע אינטראקציה עם דף מסוים תלויים במידה רבה בשאלה אם הדף ייראה אינטראקטיבי, ואי אפשר למדוד זאת באמצעות TBT.
TBT לא מתייחס להשהיה של הקשה
אם האתר לא עבר אופטימיזציה לצפייה בנייד, הדפדפנים יוסיפו עיכוב של 300 אלפיות השנייה אחרי כל הקשה לפני שיפעילו רכיבי handler של אירועים. הן עושות זאת כי הן צריכות לקבוע אם המשתמש מנסה להקיש הקשה כפולה כדי לשנות את מרחק התצוגה לפני שהוא יכול לירות עכבר או ללחוץ על אירועים.
העיכוב הזה נכלל ב-INP של הדף, כי הוא תורם לזמן האחזור האמיתי של הקלט שמשתמשים חווים. אבל מכיוון שעיכוב זה אינו משימה ארוכה מבחינה טכנית, הוא לא משפיע על ה-TBT של הדף. כלומר, לדף יש INP נמוך למרות שציוני ה-TBT שלו טובים מאוד.
ההשפעות של מצב המטמון ו-bfcache ב-INP
בדיוק כמו ששמירה נכונה במטמון יכולה לשפר את ה-LCP בשדה, היא יכולה גם לשפר את ה-INP.
בעולם האמיתי, יכול להיות שה-JavaScript של אתר כבר קיים במטמון של משתמש, כך שהעיבוד שלו יכול לקחת פחות זמן ולגרום לעיכובים קטנים יותר.
הדבר נכון גם לגבי דפים ששוחזרו ממטמון לדף הקודם/הבא. במקרים כאלה, קוד ה-JavaScript משוחזר מהזיכרון, כך שזמן העיבוד עשוי להיות קצר או אפסי.
CLS
השפעות של אינטראקציית משתמשים על CLS
ב-CLS שנמדדים בשיעור ה-Lab, נלקחים בחשבון רק שינויים בפריסה שמתרחשים בחלק העליון והקבוע ובמהלך הטעינה, אבל זוהי רק תת-קבוצה של מה שנמדד בפועל ב-CLS.
בשדה, הכלי CLS מביא בחשבון את כל השינויים הלא צפויים בפריסה שמתרחשים במהלך משך החיים של הדף, כולל תוכן שמשתנה בזמן שהמשתמש גולל או בתגובה לבקשות איטיות ברשת בעקבות אינטראקציה של משתמש.
לדוגמה, בהרבה דפים מתבצעת טעינה מדורגת של תמונות או מסגרות iframe ללא מאפיינים, וזה עלול לגרום לתנודות בפריסה כשמשתמש גולל לקטעים האלה בדף. אבל השינויים האלה יכולים להתרחש רק אם המשתמש גולל למטה, פעולה שבדרך כלל לא נספרת בבדיקת מעבדה.
תוכן מותאם אישית
תוכן מותאם אישית — כולל מודעות ממוקדות ובדיקות A/B — משפיע על הרכיבים שנטענים בדף. היא גם משפיעה על אופן הטעינה שלהם, כי לעיתים קרובות תוכן מותאם אישית נטען מאוחר יותר ומוכנס לתוכן הראשי של הדף, וכתוצאה מכך תיווצר תזוזה.
בשיעור ה-Lab, בדרך כלל נטען דף ללא תוכן מותאם אישית או עם תוכן ל'משתמש בדיקה' כללי, וזה יכול לגרום לשינויים שהמשתמשים האמיתיים רואים, אבל לא בהכרח.
מכיוון שנתוני השדות כוללים את החוויות של כל המשתמשים, כמות (והתואר) של השינויים בפריסה בכל דף נתון תלויים מאוד בתוכן שנטען.
ההשפעות של מצב המטמון ו-bfcache על CLS
שתיים מהסיבות הנפוצות ביותר לתנודות בפריסה במהלך הטעינה הן תמונות ומסגרות iframe ללא מימדים (כמו למעלה) וטעינה איטית של גופנים באינטרנט. יש סיכוי גבוה יותר ששתי הבעיות האלה משפיעות על החוויה בפעם הראשונה שמשתמשים נכנסים לאתר, כשהמטמון שלו ריק.
אם המשאבים של דף מסוים נשמרים במטמון, או אם הדף עצמו שוחזר ממטמון לדף הקודם/הבא, הדפדפן יכול בדרך כלל לעבד תמונות וגופנים מיד, בלי להמתין להורדה. כתוצאה מכך, ערכי ה-CLS בשדה יהיו נמוכים יותר מאלה שכלי שיעור ה-Lab עשוי לדווח עליהם.
מה לעשות כשהתוצאות שונות
באופן כללי, אם יש לכם גם נתוני שטח וגם נתוני שיעור Lab לדף נתון, כדאי להשתמש בנתוני השדות כדי לתעדף את המאמצים. נתוני השטח מייצגים את החוויה של משתמשים אמיתיים, ולכן זו הדרך המדויקת ביותר להבין במה המשתמשים מתקשים ומה צריך לשפר.
מצד שני, אם נתוני השדות מראים ציונים טובים באופן כללי, אבל הנתונים משיעור ה-Lab מצביעים על כך שיש עדיין מקום לשיפור, חשוב להבין אילו פעולות אופטימיזציה נוספות אפשר לבצע.
בנוסף, נתוני השדות אכן משקפים את החוויות של המשתמשים בפועל, אבל הם רק רלוונטיים למשתמשים שהצליחו לטעון את האתר. לפעמים נתוני Labs יכולים לעזור בזיהוי הזדמנויות להרחבת פוטנציאל החשיפה של האתר, ולהפוך אותו לנגיש יותר למשתמשים עם רשתות איטיות יותר או מכשירים פחות מתקדמים.
באופן כללי, גם נתונים ממעבדה וגם נתונים מהשטח הם חלקים חשובים במדידת ביצועים יעילה. לשניהם יש יתרונות ומגבלות, ואם אתם משתמשים רק באחד מהם, ייתכן שאתם מחמיצים הזדמנות לשפר את החוויה של המשתמשים.