למה נתוני CrUX שונים מנתוני RUM?

הסיבות לכך שנתוני RUM יכולים להציג ערכים שונים של מדדי הליבה לבדיקת חוויית המשתמש באתר (Core Web Vitals) מאשר CrUX.

הדוח לגבי חוויית המשתמש ב-Chrome ‏ (CrUX) מספק מדדי חוויית משתמש לגבי חוויית המשתמשים בפועל ב-Chrome ביעדים פופולריים באינטרנט. הנתונים האלה נאספים באופן אוטומטי על ידי Chrome ממשתמשים שהביעו הסכמה, והם זמינים על סמך קריטריונים הסף של CrUX.

לכן, נתוני CrUX זמינים למיליונים של אתרים. לבעלי אתרים רבים לא הייתה גישה לנתוני שדה בעבר, ונתוני CrUX אפשרו לאתרים רבים לראות את הערך שלהם בפעם הראשונה. כמערך נתונים ציבורי, אפשר להשתמש ב-CrUX גם לניתוח תחרותי ולביצוע השוואות למדדי חוויית המשתמש.

מעקב אחר משתמשים אמיתיים (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 מאפשר איסוף של מדדים מותאמים אישית אחרים, שמקושרים ישירות לעסק הספציפי שלכם. אחת הדוגמאות המוכרות יותר היא המדד Time to first Tweet (זמן לעדכון הטוויטר הראשון) של Twitter. לאחר מכן אפשר למצוא מתאם בין המדדים הספציפיים לאתר לבין השיפורים במדדי הליבה לבדיקת חוויית המשתמש באתר ולמדדים העסקיים.

הבדלים בין שתי קבוצות של נתוני שדה

גבר עם שעון יודע מה השעה. גבר עם שני שעונים אף פעם לא בטוח.

חוק סגל

כשיש שני מקורות נתונים, לרוב קשה להבין למה יש הבדלים ביניהם. בדומה לחשיבות של הבנת ההבדל בין מדדים במעבדה לבין מדדים בשטח, יכולים להיות גם הבדלים בין שני מקורות של נתוני שטח. בעולם אידיאלי, הנתונים היו זהים, אבל יש הרבה סיבות לכך שהם עשויים להיות שונים.

נתונים מהמעבדה לעומת נתונים מהשטח

הדבר הראשון שצריך לבדוק הוא אם מדובר במדדים מעבדתיים (סינתטיים) או במדדים בשטח (RUM). מובן שאפשר להניח שמוצרי RUM בודקים רק נתונים מהשדה, אבל רבים מהם מציעים גם רכיב מעבדה.

נתוני המעבדה שימושיים מאוד, במיוחד בגלל התנאים הקבועים שבהם הם נמדדים. אפשר להשתמש בה כדי לעקוב אחרי שינויים לא צפויים או רגרסיות בסביבת הייצור, בלי רעשי רקע של אוכלוסיית שדות משתנה. עם זאת, יכול להיות שנתוני המעבדה לא מייצגים את חוויית המשתמש בפועל, ולכן יכול להיות שיהיו הבדלים משמעותיים בין התוצאות של מדדי השטח לבין התוצאות של מדדי המעבדה.

אוכלוסיות

ייתכן שקבוצות הנתונים שבהן נעשה שימוש בפתרונות CrUX ו-RUM יהיו שונות, בגלל הבדלים במדידה של ביקורים בדפים, בהתאם לדפדפנים, למשתמשים, לאתרים ולמכשירים שנערכת ביניהם השוואה.

הדפדפנים הכלולים

הדוח לגבי חוויית המשתמש ב-Chrome, כפי ששמו מרמז, מיועד ל-Chrome בלבד. יש הרבה דפדפנים מבוססי-Chromium (Edge, ‏ Opera ו-Brave, בין היתר) שתומכים באותם מדדים כמו Chrome בגלל קוד הליבה המשותף, אבל רק משתמשי Chrome מספקים נתונים ל-CrUX. ההגבלה הזו גם מובילה לכך שמשתמשי Chrome ב-iOS לא נכללים, כי הדפדפן שלהם מבוסס על מנוע הדפדפן Webkit. גם Android WebViews לא נספרים כ'Chrome', ולכן הנתונים מהמשתמשים האלה לא נכללים – אבל כרטיסי Chrome מותאמים אישית נכללים.

Chrome הוא אחד מהדפדפנים הפופולריים ביותר בעולם, ולכן סביר להניח שהוא יספק ייצוג רחב של ביצועי האתר ברוב המקרים. עם זאת, מדידה של הדפדפן הזה בלבד לא מייצגת את כל המשתמשים שלכם. זה עשוי להסביר את ההבדל העיקרי בין RUM לבין CrUX. זה נכון במיוחד לגבי שיטות לשיפור הביצועים שמסתמכות על ממשקי API או פורמטים של תמונות שזמינים רק ב-Chrome, למשל.

גם חוסר הנתונים מ-iOS עלול להוביל לנטייה. לדוגמה, מכיוון שמשתמשי iOS משתמשים בדרך כלל במכשירים עם ביצועים טובים יותר או מגיעים ממדינות רבות יותר עם תשתית רשת טובה יותר, ההכללה שלהם יכולה להוביל למדדי ביצועים כוללים גבוהים. לעומת זאת, החרגה שלהם – כפי שמתבצע ב-CrUX – עלולה להוביל לנתונים שסובלים מהטיה לכיוון הקצה הנמוך של המבקרים באתר (מקרה לדוגמה). משתמשי Android בדרך כלל משתמשים במגוון רחב יותר של מכשירים, יכולות מכשירים ושווקים.

פתרונות RUM יכולים לקבל נתונים מדפדפנים שאינם Chrome, ובמיוחד מדפדפנים שמבוססים על Chromium, שבהם לרוב מובנים אותם מדדים (כמו Core Web Vitals). גם בדפדפנים שאינם מבוססי Chromium מתבצעת מדידה באמצעות פתרונות RUM, אבל יכול להיות שהם כוללים קבוצה מוגבלת יותר של מדדים. לדוגמה, הזזות Cumulative Layout Shift (CLS) וזמן אינטראקציה עד התוכן הבא (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 לגבי גודל המדגם המתאים לאתר שלכם.

צבירת נתונים

מטבעם, נתוני שטח יכללו הרבה מאוד נקודות נתונים של אותם מדדים, בהשוואה לנתוני מעבדה שיספקו ערך יחיד. אם הנתונים האלה נצברים באופן שונה לצורך דיווח, זה יכול להוביל לסיבה נוספת להבדלים בין 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:

צילום מסך של PageSpeed Insights שבו מוצגות היסטוגרמות של טעינות דפים עם דירוג LCP
ב-PageSpeed Insights מוצגים נתונים של האחוזון ה-75 ב-CrUX ונתונים של תרשים היסטוגרמה

הבדלים במדדים

יש הרבה מדדים שאפשר להשתמש בהם כדי למדוד את ביצועי האתר, ולכן כשמשווים בין שתי קבוצות נתונים שונות, חשוב להבין אילו מדדים נמדדים ואיך משתמשים במדדים האלה.

המדדים שנמדדים

נתוני CrUX הם מערך הנתונים הרשמי של היוזמה מדדים בסיסיים של חוויית המשתמש, והם מודדים בעיקר את המדדים הבאים (LCP, ‏ CLS ו-INP), עם כמה מדדים נוספים כתוספת.

כלים למעקב אחר ביצועי משתמשים באתר בדרך כלל כוללים את מדדי Core Web Vitals האלה, אבל לרוב הם כוללים גם מדדים רבים אחרים. ספקים מסוימים של RUM מודדים גם את חוויית המשתמש באמצעות שילוב משלהם של כל המדדים האלה, אולי כדי לספק 'מדד שביעות רצון' או משהו כזה. כשמשווים בין נתוני RUM לנתוני CrUX, חשוב לוודא שמדובר בהשוואה בין נתונים דומים.

כלים שמעריכים את הסטטוס 'עובר' או 'נכשל' של מדדי הליבה לבדיקת חוויית המשתמש צריכים להתייחס לדף כ'עומד בדרישות' אם הוא עומד ביעדים המומלצים ב-75% העליונים של כל מדדי הליבה לבדיקת חוויית המשתמש. אם המדד INP לא קיים בדפים ללא אינטראקציות, רק המדדים LCP ו-CLS צריכים לעמוד בדרישות.

הבדלים במדדים בין דפדפנים

מדד CrUX מודד רק בדפדפני Chrome, ואפשר לעיין ביומני השינויים של מדדי Web Vitals כדי לראות איך הם משתנים בכל גרסת Chrome.

עם זאת, פתרונות RUM מודדים מגוון רחב יותר של דפדפנים. סביר להניח שדפדפנים המבוססים על Chromium (Edge,‏ Opera וכו') יהיו דומים ל-Chrome, אלא אם ב-Chrome יושמו שינויים חדשים כפי שמצוין ביומן השינויים.

בדפדפנים שאינם Chromium, ההבדלים עשויים להיות בולטים יותר. לדוגמה, הצגת תוכן ראשוני (FCP) זמינה ב-Safari וב-Firefox, אבל היא נמדדת בדרך שונה. כתוצאה מכך, יכולים להיות הבדלים משמעותיים בין השעות שמדווחות. כפי שצוין קודם, אם רוצים להשוות בין RUM ל-CrUX, עדיף לסנן רק משתמשי Chrome כדי לאפשר השוואה בין נתונים דומים.

תזמון המדדים

מדדי הליבה לבדיקת חוויית המשתמש באתר ניתנים על ידי ממשקי API לדפדפני אינטרנט, אבל זה לא אומר שאין פוטנציאל להבדלים בין הערכים שמדווחים באמצעותם. ההבדלים יכולים לנבוע מהמועד שבו מתבצעת מדידת המדד – בטעינת הדף או במהלך מחזור החיים המלא של הדף. ייתכן שכלי RUM לא תמיד מודדים מדדים באותו אופן – גם אם הם משתמשים באותם שמות – וגם לא את אותם ממשקי API לדפדפנים כדי לקבל את הנתונים, מה שעלול לבלבל.

Largest Contentful Paint ‏ (LCP) הוא מדד של טעינת דף. אם רכיבים גדולים יותר נטענים מאוחר יותר אחרי הרינדור הראשוני, Web API יכול לדווח על מספר רכיבי LCP. רכיב ה-LCP הסופי הוא כשהדף מסיים להיטען או כשהמשתמש יוצר אינטראקציה עם הדף. לכן, יכולים להיות הבדלים אם הדיווח על רכיב ה-LCP מתבצע לפני שני האירועים האלה.

בנוסף, בנתוני השדה, רכיב ה-LCP יכול להיות שונה בהתאם לאופן שבו הדף נטען. בטעינת דף שמוגדרת כברירת מחדל ומוצג בה החלק העליון של תוכן הדף, אלמנט ה-LCP יהיה תלוי בעיקר בגודל המסך. עם זאת, אם הדף נפתח באמצעות קישור עוגן שנמצא בהמשך המסמך, או באופן דומה באמצעות קישור עומק לאפליקציית דף יחיד (SPA) – נרחיב על כך בהמשך – רכיב ה-LCP יכול להיות שונה.

אל תניחו שהזמנים של LCP שמוצגים ב-CrUX או ב-RUM מבוססים על אותו רכיב כמו בכלים של Lab. ב-CrUX מוצג הערך הכולל של LCP לכל דף או מקור, אבל RUM מאפשר לפלח את הערך הזה עוד יותר כדי לזהות סשנים ספציפיים עם בעיות ב-LCP.

מדד יציבות חזותית (CLS) נמדד במהלך כל משך החיים של הדף, כך שמדד ה-CLS הראשוני בזמן הטעינה של הדף עשוי שלא לייצג דפים שגורמים לתנודות גדולות יותר בשלב מאוחר יותר, אחרי שהדף נטען והמשתמש קיים איתו אינטראקציה. לכן, מדידת הערך של CLS רק אחרי טעינת הדף – כפי שמתבצע במוצרים רבים של RUM – תיתן תוצאה שונה מאשר מדידת הערך של CLS אחרי שהמשתמש מסיים את השימוש בדף.

כדי למדוד את מדד הרספונסיביות מאינטראקציה ועד הצגת התגובה (INP), צריך להזין קלט. המדד מתעד את כל האינטראקציות שמתרחשות מקליקים, מהקשות וממקלדת במהלך חיי הדף, באופן דומה ל-CLS. לכן, הערך שמדווח של INP עשוי להיות שונה מאוד אם המדד נמדד אחרי שהמשתמש ביצע מספר אינטראקציות בדף.

מערכת CrUX תפעל בהתאם למסמכי התיעוד של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) ותמדוד את המדדים האלה לאורך כל מחזור החיים של הדף. מסיבות שונות, ספקי RUM רבים בוחרים למדוד את המדדים האלה אחרי טעינת הדף או בזמן אחר (לדוגמה, כשלוחצים על קריאה חשובה לפעולה).

אם אתם רואים הבדלים לא מוסברים בין שני מקורות הנתונים, חשוב לברר מול ספק ה-RUM מתי מתבצעת מדידת מדדי חוויית המשתמש הבסיסיים.

אפליקציות בדף יחיד

אפליקציות בדף יחיד (SPA) פועלות על ידי עדכון התוכן בדף הנוכחי, במקום לבצע ניווטים בפועל בדפים ברמת הדפדפן. כלומר, הדפדפן לא רואה את האירועים האלה כניווט בדפים, למרות שהמשתמשים חווים אותם ככאלה. ממשקי ה-API של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) שסופקו על ידי הדפדפן לא ייקחו בחשבון את הנתונים האלה, ולכן CrUX לא תומך בניווטים האלה בדפים. אנחנו עובדים על פתרון הבעיה הזו. מידע נוסף זמין בפוסט ניסוי במדידת ניווטים חלקיים.

חלק מספקי RUM מנסים לזהות 'ניווטים רכים' ב-SPA, אבל אם הם משייכים גם מדדי Core Web Vitals ל'ניווטים הרכים' האלה, יהיו הבדלים בנתונים ב-CrUX כי ממשקי ה-API הבסיסיים לא תומכים בכך לגבי רבים מהמדדים.

ההבדלים בין CrUX לבין Web API

בנוסף להבדלים בתצוגות הדפים שנמדדות ובמה שנמדד, יש כמה תרחישים מורכבים יותר שחשוב לדעת עליהם כי הם עלולים להוביל להבדלים בנתוני CrUX ובנתוני RUM. חלק מההבדלים האלה נובעים מהגבלות של ממשקי ה-API לאינטרנט המשמשים למדידת המדדים, וחלק מהם נובעים מהצורך לטפל בתוצאות שמוחזרות על ידי ה-API באופן שונה בתרחישים מסוימים. במסמכי העזרה של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) מפורטים ההבדלים האלה לגבי LCP ו-CLS, אבל ההבדלים העיקריים מפורטים גם בקטעים הבאים.

מטמון לדף הקודם/הבא

ב-CrUX, שחזור של מטמון לדף הקודם/הבא (או bfcache) נחשב לניווט בדפים, גם אם הוא לא מוביל לטעינה רגילה של דף. מאחר שממשקי ה-API של האינטרנט לא מתייחסים לאירועים האלה כאל טעינת דף, פתרונות RUM צריכים לבצע פעולות נוספות כדי שהדפים האלה ייכללו בספירה, אם הם רוצים להתאים ל-CrUX. אלה טעינת דפים מהירה יותר באופן משמעותי, שיכולה להוביל לדיווח על ביצועים טובים יותר באופן כללי באתר. לכן, אם לא תכללו אותם, מדדי הביצועים הכוללים של הדפים עשויים להיות גרועים יותר. כדאי לעיין בפתרון ה-RUM שלכם כדי להבין אם הוא מטפל בדפים ששוחזרו מ-bfcache.

מסגרות iframe

מטעמי אבטחה ופרטיות, לדפים ברמה העליונה אין גישה לתוכן בתוך מסגרות iframe (אפילו מסגרות iframe מאותו מקור). המשמעות היא שמדדי הביצועים של התוכן בפריימים האלה ניתנים למדידה רק על ידי ה-iframe עצמו, ולא באמצעות ממשקי ה-API של האינטרנט בדף שמכיל את ה-iframe. אם תוכן ה-iframe כולל את רכיב ה-LCP או תוכן שמשפיע על ה-CLS או ה-INP של המשתמש, הוא לא יהיה זמין לפתרונות RUM (כולל ספריית JavaScript של מדדי ה-Web Vitals של Google).

עם זאת, בדוח CrUX, שנמדד על ידי דפדפן Chrome עצמו ולא על ידי JavaScript בדף, אין את המגבלות האלה, ולכן הוא מודד מדדים בתוך iframes כשמדווחים על מדדים בסיסיים של חוויית המשתמש. הנתון הזה משקף בצורה מדויקת יותר את חוויית המשתמש, אבל הוא יכול להיות סיבה נוספת להבדלים בין אתרים שמשתמשים ב-iframes.

דוגמה קונקרטית אחת לאופן שבו המצב הזה יכול להוביל להבדלים בין נתוני LCP ב-CrUX לבין נתוני LCP ב-RUM מפורטת בקטע <video>. הפריים הראשון שצויר של רכיב <video> שפועל בהפעלה אוטומטית ב-playsinline יכול להיחשב כ-LCP פוטנציאלי, אבל הטמעות של שירותי סטרימינג פופולריים של וידאו עשויות למקם את הרכיבים האלה ב-<iframe>. המערכת של CrUX יכולה להביא בחשבון את הנתונים האלה כי יש לה גישה לתוכן של <iframe>, אבל פתרונות RUM לא יכולים לעשות זאת.

משאבים מאתרים שונים

יכול להיות שמדדי LCP של מדיה שמוצגת מדומיינים אחרים לא יספקו זמן עיבוד ב-PerformanceObserver API – אלא אם הכותרת Timing-Allow-Origin (TAO) תסופק – בגלל הגבלות אבטחה בדפדפן שנועדו לצמצם התקפות תזמון. במקרה כזה, המערכת חוזרת לזמן הטעינה של המשאב, אבל יכול להיות שהזמן הזה יהיה שונה מאוד מהזמן שבו התוכן נצבע בפועל.

מצב כזה עלול להוביל למצב שנראה בלתי אפשרי, שבו זמן הטעינה של התוכן הוויזואלי המשמעותי (LCP) מדווח על ידי ממשקי API לאינטרנט מוקדם יותר מזמן הטעינה הראשונית של דף הנחיתה (FCP). זה לא המצב, אלא רק בגלל הגבלת האבטחה הזו.

הבעיה נפתרה בסוף שנת 2024, וזמן העיבוד הגולמי זמין מגרסת Chrome 133 גם אם לא מציינים את Timing-Allow-Origin.

שוב, מערכת CrUX מדווחת על נתוני זמן הרינדור של מדדי Core Web Vitals. אם אתם רוצים למדוד את המדדים האלה בצורה מדויקת יותר, מומלץ להגביל את התוכן ממקורות שונים שמשפיע על המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) ולהפעיל את TAO כשהדבר אפשרי. יכול להיות שיהיו הגבלות דומות על משאבים אחרים ממקורות שונים.

כרטיסיות ברקע

גם אם דף לא נפתח בכרטיסייה ברקע, הוא עדיין ישדר מדדים באמצעות ממשקי Web API. עם זאת, אירועים כאלה לא מדווחים על ידי 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 יום.

לרוב אין תשובה 'נכונה' או 'שגויה' במדדים השונים האלה – הם פשוט משקפים נקודת מבט שונה על המשתמשים ועל חוויית השימוש שלהם באתר. העיקר להבין למה יש הבדלים כאלה, ואיך הם יכולים להשפיע על תהליך קבלת ההחלטות שלכם. זה הדבר החשוב ביותר כדי לספק שירות טוב יותר למבקרים באתר.

תודות

תמונה ממוזערת של Steven Lelham ב-Unsplash