הסיבות לכך שבנתוני RUM מוצגים מספרים שונים של מדדי ליבה לבדיקת חוויית המשתמש באתר CrUX.
דוח חוויית המשתמש ב-Chrome (CrUX) מספק מדדים של חוויית משתמש לגבי האופן שבו משתמשי Chrome בעולם האמיתי חווים יעדים פופולריים באינטרנט. הנתונים האלה נאספים באופן אוטומטי על ידי Chrome ממשתמשים שהביעו הסכמה. הם זמינים בהתאם לקריטריונים לזכאות ל-CrUX.
לכן, נתוני CrUX זמינים במיליוני אתרים. לבעלי אתרים רבים לא הייתה גישה לנתוני השדות בעבר, ו-CrUX מאפשר לאתרים רבים לראות את הערך הזה בפעם הראשונה. כמערך נתונים ציבורי, אפשר להשתמש ב-CrUX גם לניתוח תחרותי ולהשוואה לשוק של מדדי חוויית המשתמש.
התכונה Real User Monitoring (RUM) דומה ל-CrUX, אבל במקום Chrome איסוף אוטומטי של מדדים של חוויית המשתמש, קוד נכלל באתרים כדי לבצע את האיסוף הזה ולהעביר אותו לספק RUM או לפתרון ניתוח נתונים לצורך ניתוח נתונים נוסף.
בשני הפתרונות למדידת מדדים של חוויית משתמש, טבעי להניח שהם אמורים להיות זהים. ההבדלים עשויים להיות מבלבלים. במדריך הזה תסביר למה זה יכול לקרות, ונציע הצעות לפעולות שאפשר לבצע כאשר הנתונים לא תואמים.
יתרונות השימוש בפתרון CrUX עם פתרון RUM
CrUX הוא כלי מצוין לתצוגה עקבית בכל האתרים, וגם – בתור מערך הנתונים הרשמי של תוכנית Core Web Vitals – סביר להניח שאתרים ירצו לעקוב אחרי מה שהם מוצגים. המטרה של CrUX היא לספק סקירה כללית רלוונטית מבחינה סטטיסטית של מיליוני אתרים לצורך השוואה בין מודלים.
עם זאת, כדי להתעמק בחקירה של הסיבות לכך שבנתונים מוצגים המספרים האלו, השקעה בפתרון RUM מלא כתוספת משלימה ל-CrUX תאפשר לכם לקבל גישה למידע מפורט יותר מזה שניתן לקבל במערך נתונים ציבורי שניתן להריץ עליו שאילתות. המידע הזה יכול לעזור לכם להסביר את המדדים ולשפר אותם בכמה דרכים.
ניתוח מעמיק יותר כדי לחקור בעיות
לעיתים קרובות ניתן להשתמש ב-CrUX כדי לציין אם יש בעיה באתר, אבל לא בהכרח היכן בדיוק הבעיה באתר או למה היא קיימת. פתרונות RUM – כאלה שהם תוצרת בית דרך כמו ספריית ה-Web-vitals או חלק מהמוצרים המסחריים הרבים – יכולים לעזור לגשר על הפער הזה.
שימוש בפתרון RUM מאפשר גישה לנתונים מפורטים הרבה יותר בכל הדפים שלכם ובכל הדפדפנים. הוא גם מאפשר לפלח ולנתח את הנתונים האלה בדרכים שונות מ-CrUX, וכך להציג פירוט ולחקור אזורים בעייתיים באתר. האם הם מושפעים מפלח מסוים של משתמשים? או משתמשים שמבצעים פעולות מסוימות? מתי בדיוק הבעיה התחילה? אלה שאלות שקל יותר לענות עליהן באמצעות הנתונים הנוספים שכלי ה-RUM יכול לספק.
התאמה למדדים עסקיים אחרים
בעזרת RUM אפשר גם להשוות ישירות את מדדי הביצועים באינטרנט לכל מדד עסקי, ולראות את הערך בהשקעה בביצועים ואילו ביצועים אחרים כדאי לתעדף. יש לנו מספר מקרים לדוגמה שעסקנו בהם לגבי הקורלציה הזו, כמו Farfetch או The Economic Times.
איסוף של נתוני ביצועים אחרים
פתרון RUM מאפשר לאסוף מדדים מותאמים אישית אחרים שקשורים ישירות לעסק הספציפי שלכם. אחת הדוגמאות המוכרות יותר היא "הזמן עד הציוץ הראשון של Twitter. מדד. לאחר מכן ניתן להתאים את המדדים האלה, שספציפיים לאתר, לשיפורי הליבה לבדיקת חוויית המשתמש באתר ולמדדים העסקיים.
הבדלים בין שתי קבוצות של נתוני שדות
גבר עם שעון יודע מה השעה. אדם עם שני שעונים אף פעם לא בטוח.
החוק של סגל
בכל פעם שיש לכם שני מקורות נתונים, ההבדלים ביניהם עלולים להיות מבלבלים ומתסכלים. בדיוק כמו שחשוב להבין את ההבדל בין מדדים של מעבדה לבין מדדי שדות, יכולים להיות גם הבדלים בין שני מקורות של נתוני שדות. במצב אידיאלי, הנתונים יהיו זהים, אבל יש סיבות רבות להבדלים ביניהם.
נתוני שיעור Lab לעומת נתוני שטח
הדבר הראשון שצריך לבדוק הוא אם אתם מסתכלים על מדדי מעבדה (סינתטי) או מדדי שדות (RUM). טבעי להניח שמוצרי RUM מסתכלים רק על נתוני שטח, ורבים מהם מציעים גם רכיב של שיעור Lab.
נתוני שיעור ה-Lab שימושיים במיוחד בזכות התנאים הקבועים שבהם הם מודדים. אפשר להשתמש בו כדי לעקוב אחרי שינויים או רגרסיות לא צפויים בסביבת ייצור, ללא הרעש של אוכלוסיית השדה המשתנה. עם זאת, יכול להיות שנתוני שיעור ה-Lab לא ישקפו את חוויית המשתמש האמיתית, כך שמדדי השדות עשויים להראות תוצאות שונות למדי.
אוכלוסיות
מערכי הנתונים שבהם משתמשים בפתרונות CrUX ו-RUM עשויים להיות שונים, עקב הבדלים באופן המדידה של הביקורים בדף, בהתאם לדפדפנים, למשתמשים, לאתרים ולמכשירים שמבצעים השוואה.
דפדפנים כלולים
הדוח על חוויית המשתמש ב-Chrome, כפי שמרמז השם, מיועד ל-Chrome בלבד. יש דפדפנים רבים המבוססים על Chromium (Edge, Opera ו-Brave, ועוד כמה מהם) שתומכים באותם מדדים כמו Chrome בהתחשב ב-codebase המשותף, אבל רק משתמשי Chrome מזינים נתונים ב-CrUX. המשמעות היא גם שמשתמשי Chrome ב-iOS לא כלולים, כי הם משתמשים במנוע הדפדפן הבסיסי (Webkit). גם רכיבי WebView של Android לא נחשבים כ-Chrome, ולכן נתונים מהמשתמשים האלה לא נכללים. עם זאת, הם כוללים כרטיסיות מותאמות של Chrome.
Chrome הוא אחד מהדפדפנים הפופולריים ביותר בעולם – ולכן סביר להניח שהוא יספק ייצוג רחב של ביצועי האתר שלכם ברוב המקרים – כך שום מצב שבו הדפדפן לא מייצג בהכרח את כל המשתמשים שלכם. זה יכול להסביר את ההבדל העיקרי בין RUM ל-CrUX. הדבר נכון במיוחד לגבי טכניקות ביצועים שמסתמכות על ממשקי API או על פורמטים של תמונות שזמינים רק ב-Chrome.
גם מחסור בנתונים לגבי iOS יכול להוביל להטיה. לדוגמה, מכיוון שמשתמשי iOS בדרך כלל משתמשים במכשירים שמניבים ביצועים טובים יותר או מבקרים ממדינות נוספות עם תשתית רשת טובה יותר, כולל אלה, יכולות להוביל למדדי ביצועים כוללים גבוהים. מצד שני, החרגה שלהם, כפי שמתרחשת ב-CrUX, עלולה להוביל לנתונים שנוהים כלפי מטה בקרב המבקרים באתר (דוגמה לדוגמה). בדרך כלל, משתמשי Android מתאימים למגוון רחב יותר של מכשירים, יכולות מכשירים ושווקים.
פתרונות RUM יכולים לקבל נתונים מדפדפנים שאינם Chrome, ובמיוחד מדפדפנים המבוססים על Chromium שלרוב יש בהם מדדים מובנים (כמו Core Web Vitals) זהים. דפדפנים שאינם מבוססים על Chromium נמדדים גם הם על ידי פתרונות RUM, אבל ייתכן שקבוצת המדדים שלהם תהיה מוגבלת יותר. לדוגמה, Cumulative Layout Shift (CLS) ו-Interaction to Next Paint (INP) זמינים רק בדפדפנים המבוססים על Chromium. יש מדדים אחרים, כמו הצגת תוכן ראשוני (FCP), שאפשר למדוד בצורה שונה למדי (ראו מאוחר יותר).
משתמשים שהביעו הסכמה
נוסף לכך שהיא מוגבלת למשתמשי Chrome, קיימת הגבלה נוספת על CrUX ולכן היא מודדת רק קבוצת משנה של משתמשי Chrome שהסכימו לשתף נתוני CrUX כשהדפדפן מותקן.
ספקי RUM גם בודקים רק קבוצה מצומצמת של משתמשים, בדרך כלל בגלל הנחיות שנשלחו בהודעה על שימוש בקובצי Cookie, שמבקשים מהמשתמשים להביע הסכמה לאיסוף נתוני RUM — או לחסימת מעקב. מצב כזה יכול להשפיע לרעה על חלק מהטעינות הראשוניות של הדפים אם האישור לא ניתן עד הדף השני או אחרי הדף, כשחלק מנכסי האתר כבר נשמרו במטמון מדפים קודמים. אם זה קורה לעיתים קרובות, המדדים עשויים להיראות טובים יותר ב-RUM מאשר בפועל, אם טעינות ראשוניות איטיות יותר של דפים מוחרגות במספר מספיק של מקרים.
אתרים שנכללו
CrUX מיועד לדיווח רק באתרים ציבוריים. לכן, קיימים קריטריונים נוספים לזכאות שעשויים לגרום לכך שהנתונים לא יירשמו ב-CrUX. הקריטריונים הבולטים ביותר הם שהאתר חייב להיות גלוי לציבור הרחב ופופולרי מספיק כדי להבטיח גודל דגימה מינימלי שממנו ניתן להסיק מסקנות משמעותיות. ברוב המקרים, כתוצאה מכך לא יהיו נתונים זמינים ב-CrUX. זה פחות הבדל מבלבל בהשוואה לנתונים הזמינים אבל שונים, אבל למה זה קורה.
עם זאת, אם דפים ספציפיים באתר מסומנים כדפים שאפשר להוסיף לאינדקס, אבל אחרים לא מסומנים, יכול להיות שתראו רק קבוצת משנה של כתובות URL ב-CrUX. אם המקור גלוי באופן ציבורי, כל הצפיות בדפים של המקור הזה ייכללו בנתונים ברמת המקור, אבל יכול להיות שהנתונים ברמת כתובת ה-URL לא יהיו זמינים.
מכשירים
CrUX מפלחת את הנתונים לפי מכשירים ניידים, מחשבים וטאבלטים. על אף שכלים רבים מתמקדים בשניים הראשונים, ייתכן שהם לא חושפים נתונים של טאבלטים, או עשויים לכלול אותם בניידים או במחשבים. מאפייני הביצועים בנייד לעומת במחשב יכולים להיות שונים לגמרי - גם מבחינת התוכן שמועבר וגם מבחינת היכולות של המכשירים שבהם מוצגים הסרטונים.
נתוני RUM יאפשרו לפלח תנועה באופן דומה, אבל לעיתים קרובות מוצגים נתונים מאוחדים כברירת מחדל. RUM יכול לאפשר פילוח רק לפי סוג מכשיר (לדוגמה, נייד) או דפדפן (למשל, Chrome), אבל לא לשניהם כדי לראות רק תנועה ב-Chrome במכשירים ניידים. כשמשווים לנתוני CrUX, חשוב לוודא שאתם משווים נתונים דומים. לשם כך, ניתן לסנן לפי סוג מכשיר וגם לפי דפדפן Chrome.
דגימות
פתרונות RUM בדרך כלל מאפשרים לשנות את קצב הדגימה של מבקרים שהביעו הסכמה לאיסוף נתונים. אפשר להשתמש באפשרות הזו כדי להפחית את נפח הנתונים שדרושים לניתוח ולצמצם את העלויות של שירותי RUM מסחריים. אם גודל המדגם קטן מדי ולא מייצג את האוכלוסייה הרחבה, גם המדדים שיתקבלו יהיו מוטים באופן דומה. יש לפנות לספק ה-RUM ולברר מהו גודל הדגימה המתאים לאתר.
צבירת נתונים
נתוני שדות מעצם טבעם יכללו הרבה מאוד נקודות נתונים של אותם מדדים, בהשוואה לנתוני שיעור ה-Lab, שיופקו ערך אחד. אם הנתונים האלה נצברים באופן שונה לצורכי דיווח, זה יכול להוביל לסיבה נוספת להבדלים בין CrUX לבין RUM.
טווח הזמן
נתוני CrUX מבוססים על חלון הזזה של 28 ימים, ואי אפשר לשנות את מסגרת הזמן הזו. אבל נתוני CrUX ב-BigQuery מאוחסנים לכל חודש, כך שניתן לראות חודשים קודמים, ו-CrUX History API מספק נתונים היסטוריים על פני תקופה שבועית. שתיהן עדיין מספקות נתונים על סמך חלון ההזזה של 28 ימים.
נתוני RUM בדרך כלל מאפשרים רמת פירוט גבוהה יותר שמאפשרת לראות את ההשפעה של השינויים הרבה יותר מהר. עם זאת, כשבוחרים תקופות קטנות יותר, נתוני ה-RUM עשויים להיות מושפעים במידה רבה מתנודות בתנועת הגולשים באתר ובמבקרים. כשמשווים נתוני RUM לנתוני CrUX, חשוב תמיד לוודא שבודקים את הביצועים לאורך יותר מ-28 ימים. אם מרוצים מהנתונים דומים, אפשר לבחון מסגרות זמן אחרות כדי להתעמק בנתוני ה-RUM.
צבירת נתונים סטטיסטיים
מדדי CrUX נמדדים באחוזון ה-75 – כלומר, בוחנים את הערך ש-75% מהצפיות בדפים השיגו. יהיו נתונים קיצוניים בנתונים בשטח, ו 25% החוויות הגרועות ביותר יוסרו, והמטרה היא לספק ערך שסביר להניח שרוב המבקרים ישיגו.
לעיתים קרובות, מוצרי RUM מספקים מספר רחב יותר של אפשרויות לצבירת מדדים, כולל האחוזון ה-75, חציון ואחוזונים אחרים. אם משווים ערכי RUM לנתוני CrUX, יש לוודא שאתם בוחנים את נתוני האחוזון ה-75 כדי להשוות ערכים דומים.
נתוני ההיסטוגרמה ב-CrUX כוללים את כל הנתונים הזמינים — לא רק האחוזון ה-75 — ומציגים את מספר הצפיות בדפים בכל דירוג. עם זאת, הציון המצטבר יתבסס על האחוזון ה-75. נתוני CrUX האלה מוצגים בכלים כמו PageSpeed Insights:
הבדלים במדדים
יש הרבה מדדים שמשמשים למדידת הביצועים באינטרנט, ולכן כשמשווים בין שתי קבוצות נתונים שונות, חשוב להבין אילו מדדים נמדדים ואיך נעשה שימוש במדדים האלה.
מדדים שנמדדים
נתוני CrUX הם מערך הנתונים הרשמי של יוזמת מדדי הליבה לבדיקת חוויית המשתמש באתר, שמודדים בעיקר את המדדים האלה (LCP, CLS ו-INP), עם כמה מדדים נוספים להשלמתם.
כלי RUM בדרך כלל כוללים את מדדי הליבה לבדיקת חוויית המשתמש באתר, אבל לעיתים קרובות הם כוללים גם הרבה מדדים אחרים. חלק מספקי ה-RUM מודדים את חוויית המשתמש גם באמצעות שילוב משלהם בין כל המדדים האלה, אולי כדי לספק 'מדד שביעות רצון' או כאלה. כשמשווים נתוני RUM ל-CrUX, צריך לוודא שמשווים נתונים דומים.
באמצעות כלים שמעריכים את סטטוס המעבר או הכשל של מדדי הליבה לבדיקת חוויית המשתמש באתר, דף כלשהו צריך לעבור בהצלחה את הבדיקה אם הוא עומד ביעדים המומלצים באחוזון ה-75 בכל מדדי הליבה לבדיקת חוויית המשתמש באתר. אם אין INP בדפים ללא אינטראקציות, רק ערכים LCP ו-CLS צריכים לעבור בהצלחה.
הבדלים במדדים בין דפדפנים
CrUX נמדדת רק בדפדפני Chrome. אפשר לעיין ביומני השינויים של Web Vitals כדי לראות איך השינויים האלה משתנים בכל גרסה של Chrome.
עם זאת, פתרונות RUM ימדדו מתוך מגוון רחב יותר של דפדפנים. דפדפנים המבוססים על Chromium (Edge, Opera וכן הלאה) יהיו דומים ל-Chrome, אלא אם Chrome יטמיע את השינויים החדשים כפי שמצוין ביומן השינויים.
בדפדפנים שאינם Chromium, ההבדלים מודגשים יותר. לדוגמה, First Contentful Paint (FCP) זמין ב-Safari וב-Firefox, אבל נמדד בדרך אחרת. הדבר עשוי להוביל להבדלים משמעותיים במועדים שמדווחים. כפי שצוין קודם, אם רוצים להשוות בין RUM ל-CrUX, עדיף לסנן רק משתמשים ב-Chrome כדי לבצע השוואה דומה.
תזמון המדדים
המדדים של Core Web Vitals מסופקים על ידי ממשקי API לדפדפני אינטרנט, אבל זה לא אומר שאין פוטנציאל להבדלים בערכים שמדווחים עליהם. בדיוק ברגע שבו מתבצעת מדידת המדד – בזמן טעינת הדף או במהלך מחזור החיים המלא של הדף – יכולים להוביל להבדלים. כלי RUM לא תמיד מודדים מדדים באותו אופן – גם אם משתמשים באותם שמות – ובאותם ממשקי API של דפדפן כדי לקבל את הנתונים, דבר שעלול לבלבל.
המהירות שבה נטען רכיב התוכן הכי גדול (LCP) הוא מדד של טעינת דף. יש מספר אלמנטים של LCP שה-Web API יכול לדווח עליהם אם רכיבים גדולים יותר נטענים בשלב מאוחר יותר אחרי העיבוד הראשוני. רכיב ה-LCP הסופי נוצר כשטעינת הדף מסתיימת או כשהמשתמש מקיים אינטראקציה עם הדף. לכן יכולים להיווצר הבדלים אם רכיב ה-LCP מדווח בשלב מוקדם יותר משני האירועים האלה.
בנוסף, בנתונים בשדות, רכיב ה-LCP יכול להיות שונה בהתאם לאופן הטעינה של הדף. לטעינת דף כברירת מחדל שבה מוצג החלק העליון של תוכן הדף, רכיב ה-LCP יהיה תלוי בעיקר בגודל המסך. עם זאת, אם הדף נפתח באמצעות קישור עוגן בהמשך המסמך, או נפתח באופן דומה באמצעות קישור עומק לאפליקציה בדף יחיד (SPA), ולפרטים נוספים בהמשך, רכיב ה-LCP יכול להיות שונה.
אל תניחו שתזמוני ה-LCP שסופקו ב-CrUX או ב-RUM מבוססים על אותו רכיב כמו כלים לשיעור Lab. ב-CrUX ניתן לקבל את ערך ה-LCP הכולל לכל דף או מקור, אבל ב-RUM אפשר לפלח את הנתונים האלה עוד יותר כדי לזהות סשנים נפרדים של בעיות LCP.
Cumulative Layout Shift (CLS) נמדד במהלך כל משך החיים של הדף, לכן יכול להיות שה-CLS של טעינת הדף הראשונית לא מייצג דפים שגורמים לשינויים גדולים יותר מאוחר יותר אחרי שהדף נטען והמשתמש קיים אינטראקציה עם הדף. לכן, אם לוקחים את ערך ה-CLS רק אחרי טעינת הדף, כמו בכל מוצרי RUM, מקבלים תוצאה שונה מזו שלוקחת את ערך ה-CLS אחרי שהמשתמש מסיים לקרוא את הדף.
כדי להשתמש במדד הרספונסיביות מהירות התגובה לאינטראקציה באתר הבא (INP) צריך למדוד קלט, והוא עוקב אחרי כל האינטראקציות של קליקים, הקשה ומקלדת לאורך חיי הדף, באופן דומה ל-CLS. לכן, הערך המדווח של INP עשוי להיות שונה מאוד אם הוא נמדד לאחר שהמשתמש ביצע מספר אינטראקציות בדף.
CrUX תעקוב אחר מסמכי התיעוד בנושא Core Web Vitals ותמדוד אותם לאורך כל משך החיים של הדף. ספקי RUM רבים בוחרים במקום זאת למדוד את המדדים האלה אחרי טעינת דף או במועד אחר (לדוגמה, כשמשתמש לוחץ על קריאה חשובה לפעולה) מסיבות שונות.
כשמודדים הבדלים לא מוסברים בין שני מקורות הנתונים, חשוב לקבל תובנות מספק ה-RUM לגבי מתי נמדדים מדדי הליבה לבדיקת חוויית המשתמש באתר.
אפליקציות בדף יחיד
אפליקציות עם דף יחיד (SPA) פועלות על ידי עדכון התוכן של הדף הנוכחי, במקום לבצע ניווטים בפועל בדפים ברמת הדפדפן. כלומר, הדפדפן לא רואה אותן כניווטים בדפים, למרות שהמשתמשים נתקלים בהן ככאלה. ממשקי ה-Core Web Vitals של הדפדפן לא מביאים בחשבון את הנתונים האלה, ולכן CrUX לא תומך בניווטים כאלה בדפים. אנחנו עושים מאמצים כדי לפתור את הבעיה הזו. מידע נוסף זמין בפוסט ניסויים במדידה של ניווטים עם יכולת ניווט.
חלק מספקי ה-RUM מנסים לזהות 'ניווטים קלים' באפליקציות SP, אבל אם הם גם משייכים את מדדי הליבה לבדיקת חוויית המשתמש באתר של המשתמשים הרלוונטיים זה יגרום להבדלים עם CrUX, כי ממשקי ה-API הבסיסיים לא תומכים בכך בהרבה מהמדדים.
הבדלים ב-CrUX וב-Web API
נוסף על ההבדלים באילו צפיות בדפים נמדדים ומה נמדד, יש עוד כמה תרחישים מורכבים ומורכבים נוספים שיכולים להוביל להבדלים בנתוני CrUX ו-RUM. חלק מהגורמים האלה נובעים מהמגבלות של ממשקי ה-API באינטרנט שמשמשים למדידת המדדים, ובחלקם צריך לטפל באופן שונה בתוצאות שה-API מחזיר בתרחישים מסוימים. במסמכי התיעוד בנושא Core Web Vitals, ההבדלים האלה בין המדדים LCP ו-CLS מפורטים גם ההבדלים העיקריים בסעיפים הבאים.
מטמון לדף הקודם/הבא
ב-CrUX, המערכת מתייחסת למטמון לדף הקודם/הבא (או במטמון לדף הקודם/הבא) שחזורים כניווט בדף, למרות שהם לא מובילים לטעינת דף רגילה. ממשקי ה-API באינטרנט לא מתייחסים למקרים האלה כטעינת דף, ולכן פתרונות RUM צריכים לבצע פעולות נוספות כדי שהדפים האלה ייספרו אם הם תואמים ל-CrUX. אלו טעינות מהירות יותר משמעותית של דפים, שיכולות להוביל לדיווח על ביצועים טובים יותר של האתר באופן כללי. לכן, אם לא תכללו אותן, ייתכן שיתקבלו מדדים כוללים פחות טובים של ביצועים של דפים. צריך לבדוק בפתרון ה-RUM שבו אתם משתמשים כדי לבדוק אם הוא מטפל בדפים משוחזרים במטמון לדף הקודם/הבא.
מסגרות iframe
מטעמי אבטחה ופרטיות, לדפים ברמה העליונה אין גישה לתוכן בתוך iframes (אפילו לא לרכיבי iframe ממקור זהה). המשמעות היא שניתן למדוד את מדדי הביצועים של התוכן ברכיבים האלה רק באמצעות ה-iframe עצמו, ולא באמצעות ממשקי ה-API באינטרנט בדף הפריים. אם תוכן ה-iframe כולל רכיב LCP או תוכן שמשפיע על ה-CLS או ה-INP שהמשתמש נתקל בהם, הם לא יהיו זמינים לפתרונות RUM (כולל ספריית ה-JavaScript של vitals באינטרנט של Google).
עם זאת, ב-CrUX נמדדת באמצעות דפדפן Chrome עצמו ולא באמצעות JavaScript בדף, המגבלות האלו לא חלות, וכך גם המדדים במסגרות iframe מדווחים על מדדי ליבה לבדיקת חוויית המשתמש באתר. העובדה הזו משקפת בצורה מדויקת יותר את חוויית המשתמש, אבל יכולה להיות סיבה נוספת להבדלים באתרים שמשתמשים ב-iframes.
בהטמעת <video> מוטמעת דוגמה קונקרטית לכך שזה יכול להוביל להבדלים בין נתוני LCP ב-CrUX וב-RUM. המסגרת המצוינת הראשונה של רכיב <video> שמופעל באופן אוטומטי יכולה להיחשב כמועמדת ל-LCP, אבל בהטמעות של שירותי וידאו בסטרימינג פופולריים יכול להיות שהרכיבים האלה יופיעו ב-<iframe>. CrUX יכולה להתמודד עם זה, כי יש לה גישה לתכנים של <iframe>, אבל פתרונות RUM לא יכולים לעשות זאת.
משאבים ממקורות שונים
מדיית LCP שמופעלת מדומיינים אחרים לא נמשכת זמן רינדור ב-PerformanceObserver API – אלא אם מסופקת הכותרת Schedule-Allow-Origin (TAO) – עקב מגבלות אבטחה של הדפדפן שמטרתן לצמצם את מספר ההתקפות. הערך הזה חוזר אל זמן הטעינה של המשאב, אבל זמן הטעינה הזה עשוי להיות שונה מהזמן שבו התוכן נצבע בפועל.
זה עלול להוביל למצב שנראה בלתי אפשרי שבו LCP מדווח על ידי ממשקי API באינטרנט מוקדם יותר מ-FCP. זה לא המצב, אלא נראה כך רק בגלל הגבלת האבטחה הזו.
שוב, CrUX מדווח על נתוני זמן העיבוד במדדי הליבה לבדיקת חוויית המשתמש באתר. אנחנו ממליצים לבעלי אתרים להגביל תוכן ממקורות שונים שמשפיע על המדדים של Core Web Vitals, ולהפעיל את TAO כשהדבר אפשרי אם רוצים למדוד את זה בצורה מדויקת יותר. משאבים אחרים ממקורות שונים עשויים להיות כפופים להגבלות דומות.
כרטיסיות ברקע
אם הדף לא נפתח בכרטיסיית רקע, עדיין יופיעו מדדים באמצעות ממשקי Web APIs. עם זאת, האירועים האלה לא מדווחים על ידי CrUX כי הם מספקים תזמונים שלא תואמים לחוויית המשתמש. כמו כן, פתרונות RUM צריכים להתעלם מהפתרונות האלה, או לפחות להסביר איך הם מתייחסים לצפיות בדפים האלה.
מה אפשר לעשות בעניין?
הסברנו למה יכולים להיות הבדלים בין נתוני CrUX לבין נתוני RUM. ההבדלים יכולים לנבוע מהבדלים במתודולוגיה שבהם כל אחד מהם משתמש, או לכך שהסיבה לכך היא שהמשתמשים והצפיות בדפים נכללים או לא נכללים. במצב אידיאלי, שתי קבוצות הנתונים עדיין ייצגו את ביצועי האתר שלכם כדי לספק לכם תוצאות מועילות, אבל הסיבות המוצגות צריכות להסביר למה קשה מאוד לצפות באותם מספרים בכל אחת מהן.
כשההבדלים הם קלים (לדוגמה, דיווח על מדד LCP של 2.0 שניות לעומת 2.2 שניות), שני מערכי הנתונים יהיו שימושיים ובדרך כלל אפשר להתייחס אליהם כסנכרון כללי.
אם יש הבדלים מודגשים שמטילים ספק על רמת הדיוק של הנתונים, מומלץ לנסות להבין את ההבדלים האלה. האם אפשר לסנן את נתוני ה-RUM כך שיתאימו יותר ל-CrUX (חיפוש של משתמשי Chrome בלבד, במחשב או בנייד, עם ערכי אחוזון 75 לאורך 28 ימים) כדי לצמצם את ההבדלים האלה?
אם כן, ואתם יכולים להתאים בצורה מדויקת יותר את הנתונים, עדיין צריך לשאול למה אתם רואים את ההבדלים האלה בנתונים הכוללים ומה המשמעות שלהם. האם משתמשים שלא משתמשים ב-Chrome מטים את המדדים בצורה חיובית או שלילית? האם התובנות האלה עוזרות לך להבין טוב יותר את הבעיות בביצועים שניתן לתעדף?
אם המשתמשים שלכם שלא משתמשים ב-Chrome מקבלים תוצאות שונות, אתם יכולים להשתמש בתובנה חשובה הזו שקיבלתם מ-RUM כדי לבצע אופטימיזציה באופן שונה. לדוגמה, ממשקי API מסוימים לא זמינים בדפדפנים מסוימים, אבל אפשר לבדוק חלופות לדפדפנים שאינם נתמכים כדי לשפר גם את חוויית המשתמש שלהם. לחלופין, אפשר להעניק חוויה שונה, אבל איכותית יותר למשתמשים ברשתות או במכשירים מוגבלים. CrUX מוגבל לנתוני Chrome, אבל צריך להביא בחשבון את כל המבקרים באתר כדי לתעדף שיפורים. נתוני RUM יכולים למלא את הפער הזה.
אחרי שתבינו את הסיבות להבדלים, שני הכלים יכולים להועיל מאוד לכם להבין את חוויות המשתמש באתר שלכם ולשפר את המצב הזה גם אם הנתונים לא זהים. נתוני ה-RUM משמשים כדי להשלים את נתוני CrUX ולאפשר לכם להתעמק בנתונים שמתקבלים מ-CrUX באמצעות פילוח של התנועה כדי לעזור לכם לזהות אם אלו אזורים ספציפיים באתר או בבסיס המשתמשים שלכם שדורשים התייחסות.
לעיתים קרובות חשוב יותר לבחון את המגמות כדי לראות שהשיפורים שביצעתם מניבים את ההשפעות החיוביות הצפויות מאשר התאמה מדויקת של כל מספר בין שני מקורות הנתונים. כפי שצוין קודם, RUM מאפשר לבחון מסגרות זמן שונות כדי לבחון מראש את ציוני ה-CrUX ב-28 הימים האחרונים. עם זאת, בדיקה של מסגרות זמן קצרות מדי עלולה להוביל להצגת נתונים עם רעש. לכן, ב-CrUX נעשה שימוש ב-28 ימים.
לעיתים קרובות אין או 'שגוי' את התשובה לגבי מדדים שונים אלה - הם פשוט מזווית שונה עבור המשתמשים שלך והדרך שבה הם חווים את האתר. כל עוד אתם מבינים את הסיבות להבדלים האלה ומה הם יכולים לעשות כדי להשפיע על קבלת ההחלטות שלכם, חשוב יותר לספק שירות טוב יותר למבקרים באתר.