נלמד למה כלים שעוקבים אחרי מדדים של Core Web Vitals עשויים לדווח על מספרים שונים, ואיך לפרש את ההבדלים האלה.
Google מספקת מספר כלים שעוזרים לבעלי אתרים לעקוב אחר הפעילות את דירוגי Core Web Vitals שלהם. הכלים האלה נכללים שתי קטגוריות עיקריות:
- כלים שמדווחים על נתוני שיעור Lab – נתונים שנאספים בסביבה מבוקרת עם הגדרות מראש של מכשיר ורשת.
- כלים שמדווחים על נתוני שטח – נתונים שנאספים ממשתמשים אמיתיים שמבקרים באתר שלך.
הבעיה היא שלפעמים הנתונים שמדווחים על ידי כלים של שיעור Lab יכולים להיות מעטים שונה מהנתונים שמדווחים על ידי הכלים בשטח! יכול להיות שנתוני שיעור ה-Lab שלכם יעידו שהאתר שלכם מניב ביצועים טובים, אבל נתוני השדות שלכם מצביעים על כך לשיפור. לחלופין, יכול להיות שנתוני השדות שלך יציינו שכל הדפים שלך טובים, אבל יכול להיות שנתוני שיעור ה-Lab ידווחו על ציון נמוך מאוד.
הדוגמה האמיתית הבאה לדוח PageSpeed Insights מ-web.dev מראה שבמקרים מסוימים הנתונים של שיעורי ה-Lab והנתונים בשדות יכולים להיות שונים, המדדים של Web Vitals:
ההבדלים בין הכלים הם מקור מובן לבלבול עבור למפתחים. בפוסט הזה מוסברות הסיבות העיקריות להבדלים האלה יש דוגמאות ספציפיות לכל אחד ממדדי הליבה לבדיקת חוויית המשתמש באתר. מה לעשות אם הבחנת בהבדלים בין הדפים.
נתוני שיעור Lab לעומת נתוני שטח
כדי להבין למה כלים לשיעור Lab עשויים לדווח ערכים שונים, גם בדיוק אותו דף אינטרנט – עליכם להבין את ההבדל בין שיעור Lab לבין .
נתוני Lab
נתוני ה-Lab נקבעים על ידי טעינת דף אינטרנט בסביבה מבוקרת עם קבוצה מוגדרת מראש של תנאים לרשת ולמכשיר. המצבים האלה נקראים lab, שנקראת גם סביבה סינתטית.
כלי Chrome שמדווחים על נתוני שיעור Lab פועלים בדרך כלל Lighthouse.
המטרה של בדיקת מעבדה היא לשלוט בכמה שיותר גורמים, התוצאות עקביות (ככל האפשר) עקביות וניתנות לשחזור מהרצה להרצה.
נתוני שדות
נתוני השדות נקבעים על ידי מעקב אחר כל המשתמשים שמבקרים בדף מסוים, ומדידת קבוצה נתונה של מדדי ביצועים לכל אחד מהמשתמשים האלה אדם פרטי לחוויות שונות. מאחר שנתוני השדות מבוססים על ביקורים של משתמשים אמיתיים, הם משקפים את המכשירים בפועל, תנאי הרשת והמיקומים הגיאוגרפיים של המשתמשים שלך.
נתוני השדות נקראים גם Real User Monitoring (RUM) נתונים. שני המונחים הם ניתנים להחלפה.
כלי Chrome שמדווחים על נתוני שטח בדרך כלל מקבלים את הנתונים האלה מChrome דוח חוויית המשתמש (CrUX). בנוסף, בעלי אתרים אוספים נתוני שדות לעיתים קרובות (ומומלץ) בעצמם כי הוא יכול לספק לקבל יותר תובנות פרקטיות מאשר שימוש ב-CrUX בלבד.
הדבר שהכי חשוב להבין לגבי נתוני שדות הוא לא רק מספר אחד, כלומר התפלגות של מספרים. כלומר, לחלק מהאנשים שמבקרים ייתכן שהוא ייטען במהירות רבה מאוד, בעוד שאחרים עשויים להיטען לאט מאוד. נתוני השטח של האתר הם הקבוצה המלאה של כל נתוני הביצועים שנאסף מהמשתמשים שלך.
לדוגמה, דוחות CrUX מציגים התפלגות של מדדי ביצועים ממקורות אמיתיים משתמשי Chrome בתקופה של 28 ימים. אם מסתכלים כמעט על כל דוח CrUX, אפשר יראו שחלק מהמשתמשים שמבקרים באתר כלשהו ייהנו מחוויה טובה מאוד, אחרים עלולים להיפגע מאוד.
אם כלי מדווח על מספר יחיד לגבי מדד נתון, בדרך כלל שמייצגים נקודה ספציפית בהתפלגות. כלים לדיווח על Core Web ציונים בשדות של מדדי ה- Vitals לעשות זאת באמצעות הציון ה-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 תקין ערך הדף הזה - הוא אחד מהערכים הרבים שמרכיבים את ההתפלגות המלאה של חוויות טעינה.
למה יש הבדל בין הנתונים בשיעור ה-Lab לנתונים שבשדה
כפי שמוסבר בקטע שלמעלה, נתוני Lab ונתוני שדות מודדים בפועל דברים שונים.
נתוני השטח כוללים מגוון רחב של תנאי רשת ומכשירים, וגם מגוון רחב של סוגים שונים של התנהגות משתמשים. הוא כולל גם גורמים אחרים שמשפיעים על חוויית המשתמש, כמו אופטימיזציות של דפדפנים כמו מטמון לדף הקודם/הבא (bfcache), או אופטימיזציות של פלטפורמה כמו מטמון AMP.
לעומת זאת, נתוני שיעור ה-Lab מגבילים במכוון את מספר המשתנים המעורבים. א' בדיקת המעבדה כוללת:
- מכשיר אחד...
- מחוברת לרשת יחידה...
- להציג מודעות ממיקום גיאוגרפי אחד.
הפרטים של כל בדיקת מעבדה נתונה עשויים לייצג או לא לשקף במדויק האחוזון ה-75 של נתוני שדות של דף או אתר נתונים.
הסביבה המבוקרת של שיעור ה-Lab שימושית לניפוי באגים או לבדיקה של בעיות לפני הפריסה בסביבת הייצור, אבל כשאתם שולטים בגורמים האלה אתם לא מייצגים בפירוש את השונות שאתם רואים בעולם האמיתי בכל סוגי הרשתות, יכולות המכשירים או המיקומים הגיאוגרפיים. שלך הם בדרך כלל גם לא מתעדים את ההשפעה של התנהגות המשתמשים בפועל על הביצועים, כגון גלילה, בחירת טקסט או הקשה על רכיבים בדף.
בנוסף לניתוק האפשרי בין תנאי מעבדה והתנאים של רוב המשתמשים בעולם האמיתי, יש גם כמה הבדלים קלים יותר שחשוב להבין כדי להפיק את המרב משיעור ה-Lab ונתוני השדות, כמו גם הבדלים אפשריים.
החלקים הבאים מפרטים את הסיבות הנפוצות ביותר למקרים כאלה יכולים להיות הבדלים בין נתוני שיעור ה-Lab לנתוני השדות בכל אחד מכלי הליבה מדדי תפקוד האפליקציה:
- המהירות שבה נטען רכיב התוכן הכי גדול (LCP)
- אינטראקציה עד התגובה הבאה (INP)
- Cumulative Layout Shift (CLS)
LCP
אלמנטים שונים של LCP
יכול להיות שרכיב ה-LCP שזוהה בבדיקת מעבדה לא יהיה אותו LCP הרכיבים שהמשתמשים רואים כשהם נכנסים לדף.
אם מריצים דוח Lighthouse על דף מסוים, הוא יחזיר את אותו הדבר רכיב LCP בכל פעם. אבל אם תסתכלו בנתוני השדות של אותו הדף, בדרך כלל אפשר למצוא מגוון של אלמנטים שונים של LCP, תלויים מספר הנסיבות הספציפיות לכל ביקור בדף.
לדוגמה, כל הגורמים הבאים יכולים לתרום למדד LCP שונה נקבע עבור אותו הדף:
- גדלים שונים של מסכי המכשירים גורמים להצגה של רכיבים שונים בתוך אזור התצוגה.
- אם המשתמש מחובר, או אם מוצג תוכן בהתאמה אישית בחלק רכיב ה-LCP יכול להיות שונה מאוד ממשתמש למשתמש.
- בדומה לנקודה הקודמת, אם מתבצעת בדיקת A/B בדף, ייתכן יובילו להצגה של רכיבים שונים מאוד.
- קבוצת הגופנים שמותקנת במערכת של המשתמש יכולה להשפיע על גודל הטקסט הדף (וכך גם האלמנט שהוא רכיב ה-LCP).
- בדיקות מעבדה פועלות בדרך כלל ב'בסיס הנתונים' של דף כתובת URL – ללא פרמטרים של שאילתה או קטעי hash שנוספו. אבל בעולם האמיתי, משתמשים משתפים בדרך כלל כתובות URL שמכיל מזהה שבר או קטע טקסט, כך שרכיב ה-LCP להיות מאמצע או מתחתית הדף (במקום 'מעל לקפל").
מכיוון שמדד LCP בשדה מחושב כאחוזון ה-75 של כל ביקורי המשתמשים לדף, אם לאחוז גדול מהמשתמשים האלה היה רכיב LCP שנטען מהר מאוד — לדוגמה, פסקת טקסט שמעובדת בגופן מערכת — ואז גם אם לחלק מהמשתמשים האלה הייתה תמונה גדולה שנטענה באיטיות בתור ה-LCP שלהם ייתכן שהוא לא ישפיע על הציון של הדף הזה אם הוא נמוך מ-25% מהמבקרים.
לחלופין, יכול להיות שההפך הוא הנכון. בדיקת מעבדה עשויה לזהות בלוק של בתור אלמנט ה-LCP כי הוא אמולציה של טלפון Moto G4 שיש לו אזור תצוגה קטן יחסית והתמונה הראשית (Hero) של הדף עוברת עיבוד ראשוני. אל מחוץ למסך. עם זאת, נתוני השדות שלך עשויים לכלול בעיקר משתמשי Pixel XL עם במסכים גדולים יותר, ולכן בשבילם, התמונה הראשית (Hero) שנטען באיטיות היא רכיב ה-LCP שלהם.
ההשפעות של מצב מטמון על LCP
בבדיקות מעבדה בדרך כלל טוענים דף עם מטמון קר, אבל כשמשתמשים אמיתיים נכנסים אותו דף, ייתכן שחלק מהמשאבים שלו כבר שמורים.
בפעם הראשונה שמשתמש טוען דף, הוא עשוי להיטען לאט, אבל אם הדף הוגדרה שמירה תקינה במטמון, בפעם הבאה שהמשתמש יחזיר את עשויה להיטען מיד.
למרות שחלק מהכלים לשיעור ה-Lab תומכים במספר הפעלות של אותו הדף (כדי לדמות עבור מבקרים חוזרים), כלי Lab לא יכול לדעת איזה אחוז של ביקורים בפועל מתרחשים ממשתמשים חדשים לעומת משתמשים חוזרים.
אתרים עם תצורות מטמון אופטימליות והרבה מבקרים חוזרים לגלות שמדד ה-LCP בעולם האמיתי מהיר בהרבה מכפי שהנתונים משיעור ה-Lab שלהם.
אופטימיזציות AMP או החלפה חתומה
אתרים שפותחו באמצעות AMP או המשתמשים בפלטפורמות חתומות של Exchange (SXG) יכול להיטען מראש על ידי אתרי אגרגטור של תוכן כמו Google חיפוש. כך ביצועי הטעינה עשויים להיות טובים יותר באופן משמעותי עבור המשתמשים שמבקרים בדפים שלכם מהפלטפורמות האלה.
בנוסף לטעינה מראש ממקורות שונים, האתרים עצמם יכולים לטעון מראש תוכן של הדפים הבאים באתר, מה שיכול לשפר את ה-LCP גם בדפים האלה.
הכלים לשיעור ה-Lab לא מדמה את היתרונות שנובעים מהאופטימיזציות האלה, וגם הם בדקו, הם לא יכלו לדעת מאיזה אחוז מהתנועה שלך מגיע בפלטפורמות כמו חיפוש Google בהשוואה למקורות אחרים.
ההשפעות של bfcache על LCP
כשדפים משוחזרים מהמטמון לדף הקודם/הבא, חוויית הטעינה קרובה באופן מיידי, והחוויות האלה נכללות בתחום .
בבדיקות מעבדה לא נלקחים בחשבון bfcache, לכן אם הדפים שלכם ידידותי לשמור במטמון, סביר להניח יובילו לדיווחים על תוצאות LCP מהירות יותר בשדה.
ההשפעות של אינטראקציית משתמש על LCP
LCP מזהה את זמן הרינדור של גוש התמונה או הטקסט הגדול ביותר אזור התצוגה, אבל הרכיב הגדול ביותר יכול להשתנות ככל שהדף נטען או כשהוא חדש התוכן מתווסף באופן דינמי לאזור התצוגה.
בשיעור ה-Lab, הדפדפן ימתין עד שהדף ייטען בצורה מלאה לפני כן שקובע מה היה אלמנט ה-LCP. אבל בשדה, הדפדפן יפסיק מעקב אחרי רכיבים גדולים יותר אחרי שהמשתמש גולל או מקיים אינטראקציה עם הדף.
זה הגיוני (ונדרש) מפני שהמשתמשים בדרך כלל ימתינו קיים אינטראקציה עם דף עד שהוא "מופיע" וזה בדיוק מה שה-LCP נועד לזהות. כמו כן, לא יהיה הגיוני להתחשב באלמנטים שנוספו אזור התצוגה אחרי אינטראקציה של משתמש, כי ייתכן שהרכיבים האלה נטענו בגלל משהו שהמשתמש ביצע.
עם זאת, המשמעות היא שנתוני השדות לגבי דף מסוים עשויים לדווח מהר יותר. זמני LCP, בהתאם להתנהגות המשתמשים בדף הזה.
INP
INP מחייב אינטראקציה של משתמש אמיתי
מדד INP מודד את מידת הרספונסיביות של דף מסוים לאינטראקציות של משתמשים, בשעה שבה המשתמשים בחרו בפועל ליצור איתו אינטראקציה.
החלק השני של המשפט הזה קריטי, כי בדיקות מעבדה, אפילו אלה תמיכה בהתנהגות משתמש בסקריפט, לא ניתן לחזות במדויק מתי משתמשים יבחרו לקיים אינטראקציה עם דף, ולכן לא ניתן למדוד את FID באופן מדויק.
TBT לא מביא בחשבון את התנהגות המשתמש
המדד סך כל זמן החסימה (TBT) נועד לעזור לכם לאבחן בעיות ב-INP, כי הוא מציין את כמות ה-thread הראשי שנחסם במהלך טעינת הדף.
הרעיון הוא שדפים עם הרבה JavaScript סינכרוני או קבצים אינטנסיביים אחרים למשימות רינדור תהיה סבירות גבוהה יותר שה-thread הראשי ייחסם כאשר יוצר אינטראקציה ראשונה. לעומת זאת, אם המשתמשים ימתינו לאינטראקציה עם הדף עד לסיום הרצת ה-JavaScript תסתיים, וה-INP עשוי להיות נמוך מאוד.
המועד שבו המשתמשים בוחרים לבצע אינטראקציה עם דף תלוי במידה רבה בשאלה אם הוא נראה אינטראקטיבי ואי אפשר למדוד אותו באמצעות TBT.
זמן ההקשה לא נלקח בחשבון במסגרת זמן ההקשה
אם אתר לא מותאם לצפייה בנייד, הדפדפנים יוסיפו 300 אלפיות השנייה עיכוב לאחר הקשה כלשהי לפני הרצת הגורמים שמטפלים באירועים. הם עושים זאת כי הם צריכים לקבוע אם המשתמש מנסה להקיש הקשה כפולה כדי להגדיל את התצוגה לפני שניתן יהיה להפעיל אותו אירועים של עכבר או לחיצה.
ההשהיה הזו נספרת כחלק מה-INP של הדף כי הוא תורמת לקלט האמיתי זמן האחזור שהמשתמשים חווים. אבל מכיוון שמבחינה טכנית העיכוב הזה לא ארוך משימה, היא לא משפיעה על TBT בדף. המשמעות היא שיכול להיות שה-INP של הדף יהיה נמוך, למרות שיש לו ציוני TBT טובים מאוד.
ההשפעות של מצב המטמון ושל המטמון לדף הקודם/הבא על INP
בדיוק כמו ששמירה נכונה במטמון יכולה לשפר את רמת ה-LCP בשדה, היא יכולה גם לשפר את INP.
בעולם האמיתי, ייתכן שלמשתמש יש את ה-JavaScript של אתר שכבר נמצא ולכן העיבוד שלו עשוי לדרוש פחות ועלולה לגרום לעיכובים קטנים יותר.
הכלל הזה נכון גם לגבי דפים ששוחזרו מהמטמון לדף הקודם/הבא. במקרים כאלה, JavaScript שוחזר מהזיכרון, כך שיכול להיות שהעיבוד יהיה מועט או לא יהיה כלל בכלל.
CLS
ההשפעות של אינטראקציית משתמשים על CLS
בחישוב של CLS שנמדד בשיעור ה-Lab, המערכת מביאה בחשבון רק שינויים בפריסה שקורים למעלה בחלק הנגלל ובמהלך הטעינה, אבל זו רק קבוצת משנה של ה-CLS נמדדים.
ב-CLS, המערכת מביאה בחשבון את כל הפריסות הלא צפויות האלה שינויים שמתרחשים לאורך משך החיים של הדף, כולל תוכן שמשתנה כאשר המשתמש גולל או נכנס תגובה לבקשות רשת איטיות לאחר אינטראקציה של המשתמש.
לדוגמה, לעתים קרובות בדפים נטענים תמונות או iframes באופן מדורג בלי מאפיינים, ועלולים לגרום לפריסה משתנה כאשר משתמש גולל אל הקטעים האלה בדף. אבל ייתכן שהשינויים האלה היא מתרחשת רק אם המשתמש גולל למטה, מה שבדרך כלל לא מזוהה בבדיקת מעבדה.
תוכן מותאם אישית
תוכן בהתאמה אישית – כולל מודעות מטורגטות ובדיקות A/B – משפיע על האלמנטים נטענים בדף. זה משפיע גם על האופן שבו הן נטענות, בדרך כלל נטען מאוחר יותר ומוכנס לתוכן הראשי של הדף, על ידי שינוי הפריסה.
בשיעור ה-Lab, דף נטען בדרך כלל ללא תוכן מותאם אישית, או עם תוכן עבור "משתמש בדיקה" כללי, שעשוי להוביל לשינויים או לא שמשתמשים אמיתיים רואים.
מאחר שנתוני השדות כוללים את החוויות של כל המשתמשים, הכמות (והדרגה) שינויי הפריסה בכל דף נתון תלויים מאוד בסוג התוכן נטען.
ההשפעות של מצב המטמון ומטמון לדף הקודם/הבא על CLS
שתיים מהסיבות הנפוצות ביותר לשינויי פריסה בזמן הטעינה הן תמונות ו מסגרות iframe ללא מאפיינים (כפי שהוזכר למעלה) וטעינה איטית באינטרנט גופנים, ושתי הבעיות האלה צפויות משפיעים על החוויה בפעם הראשונה שמשתמש מבקר באתר, כשהמטמון שלו ריק.
אם המשאבים של דף נשמרים במטמון, או אם הדף עצמו משוחזר מ- המטמון לדף הקודם/הבא, הדפדפן בדרך כלל יכול לעבד תמונות וגופנים באופן מיידי, שממתינים להורדה. כתוצאה מכך, ערכי ה-CLS עשויים להיות נמוכים יותר בשדה ממה שכלי Lab עשוי לדווח.
מה עושים כשהתוצאות שונות
ככלל, אם יש לכם גם נתוני שדות וגם נתוני שיעור Lab בדף מסוים, הנתונים בשדות האלה הם הנתונים שבהם צריך להשתמש כדי לתעדף את המאמצים. לנתוני השדות שמייצג את החוויה של משתמשים אמיתיים, זו הדרך המדויקת ביותר להבין באמת עם מה המשתמשים מתקשים ומה צריך לעשות משופר.
מצד שני, אם נתוני השדות שלכם מראים ציונים טובים לאורך הלוח, לפי נתוני שיעור ה-Lab, יש עדיין מקום לשיפור, כדי להבין אילו פעולות אופטימיזציה נוספות אפשר לבצע.
נוסף על כך, על אף שנתוני השדות מתעדים חוויות של משתמשים אמיתיים, הם כדי לעזור למשתמשים שיכולים לטעון את האתר שלכם. נתוני שיעור ה-Lab לפעמים עוזרות לזהות הזדמנויות להרחבת פוטנציאל החשיפה של האתר ולהפוך אותו נגיש יותר למשתמשים עם רשתות איטיות יותר או מכשירים פשוטים יותר.
באופן כללי, גם נתוני שיעור ה-Lab וגם נתוני השדות הם חלקים חשובים בתהליך מדידת ביצועים. לשניהם יש יתרונות ומגבלות, אתם משתמשים רק באחד מהם. ייתכן שאתם מחמיצים הזדמנות לשפר את עבור המשתמשים.