מידע ולמידה על הסיבות לכך שנתוני RUM יכולים להציג מספרים שונים של Core Web Vitals מ-CrUX.
פורסם: 15 באוגוסט 2022, עדכון אחרון: 17 בדצמבר 2025
הדוח על חוויית המשתמש ב-Chrome (CrUX) מספק מדדים של חוויית המשתמש לגבי האופן שבו משתמשי Chrome בפועל חווים יעדים פופולריים באינטרנט. הנתונים האלה נאספים באופן אוטומטי על ידי Chrome ממשתמשים שהביעו הסכמה, והם זמינים על סמך הקריטריונים לזכאות של CrUX.
לכן נתוני CrUX זמינים למיליוני אתרים. לבעלי אתרים רבים לא הייתה גישה לנתוני שדה בעבר, ו-CrUX אפשר להרבה אתרים לראות את הערך של הנתונים האלה בפעם הראשונה. מכיוון ש-CrUX הוא קבוצת נתונים ציבורית, אפשר להשתמש בו גם לניתוח תחרותי ולהשוואה לשוק של מדדי חוויית שימוש.
מעקב אחר משתמשים אמיתיים (RUM) דומה ל-CrUX, אבל במקום ש-Chrome יאסוף באופן אוטומטי מדדים של חוויית המשתמש, הקוד נכלל באתרים כדי לבצע את האיסוף הזה ולהעביר אותו לספק RUM או לפתרון ניתוח נתונים לצורך ניתוח נוסף.
שני הפתרונות מודדים מדדים של חוויית המשתמש, ולכן טבעי להניח שהם אמורים להיות זהים. ההבדלים האלה יכולים לבלבל. במדריך הזה נסביר למה זה קורה ונציע מה לעשות כשהמספרים לא תואמים.
היתרונות של הוספת פתרון RUM ל-CrUX
CrUX הוא כלי מצוין לקבלת תצוגה עקבית באתרים, וכקבוצת הנתונים של Google לתוכנית Core Web Vitals – סביר להניח שבעלי אתרים ירצו לעקוב אחרי מה שמוצג בו. המטרה של CrUX היא לספק סקירה כללית רלוונטית מבחינה סטטיסטית של מיליוני אתרים לצורך השוואה ביניהם.
עם זאת, כדי להבין לעומק למה הנתונים מציגים את המספרים האלה, כדאי להשקיע בפתרון RUM מלא שישלים את CrUX. כך תוכלו לקבל גישה למידע מפורט יותר מזה שזמין במערך נתונים שניתן לשלוח אליו שאילתות באופן ציבורי. המידע הזה יכול לעזור לכם להסביר ולשפר את המדדים בכמה דרכים.
ניתוח מעמיק יותר כדי לחקור בעיות
במקרים רבים, אפשר להשתמש ב-CrUX כדי לזהות אם יש בעיה באתר, אבל לא בהכרח איפה בדיוק הבעיה נמצאת באתר או מה הסיבה לה. פתרונות RUM – בין אם הם פותחו באופן עצמאי באמצעות ספריית web-vitals או מוצרים מסחריים רבים אחרים – יכולים לעזור לגשר על הפער הזה.
שימוש בפתרון RUM מאפשר לכם לגשת לנתונים הרבה יותר מפורטים לגבי כל הדפים שלכם, ובכל הדפדפנים. הוא גם מאפשר לפלח ולנתח את הנתונים האלה בדרכים שאינן אפשריות ב-CrUX, וכך להתעמק ולחקור אזורים בעייתיים באתר. האם הם מושפעים מפלח מסוים של משתמשים? או משתמשים שמבצעים פעולות מסוימות? מתי בדיוק הבעיה התחילה? אלה שאלות שהרבה יותר קל לענות עליהן בעזרת הנתונים הנוספים שכלי RUM יכול לספק.
התאמה למדדים עסקיים אחרים
בנוסף, RUM מאפשר לכם להשוות את מדדי הביצועים של האתר ישירות לכל מדד עסקי, להראות את הערך של ההשקעה בביצועים, ולקבוע אילו פעולות אחרות לשיפור הביצועים כדאי לתעדף. יש לנו הרבה מקרי בוחן של עסקים שביצעו את ההתאמה הזו, כמו Farfetch או The Economic Times.
איסוף נתוני ביצועים אחרים
פתרון RUM מאפשר לאסוף מדדים מותאמים אישית אחרים, שקשורים ישירות לעסק הספציפי שלכם. אחת הדוגמאות המוכרות ביותר היא המדד "הזמן עד לציוץ הראשון" של טוויטר. לאחר מכן אפשר לקשר בין המדדים הספציפיים לאתר לבין השיפורים ב-Core Web Vitals ובמדדים העסקיים.
ההבדלים בין שתי קבוצות של נתוני שדה
אדם עם שעון אחד יודע מה השעה. אדם עם שני שעונים אף פעם לא בטוח.
חוק סגל
כשמשתמשים בשני מקורות נתונים, לפעמים קשה להבין למה יש הבדלים ביניהם. כמו שחשוב להבין את ההבדל בין מדדי מעבדה למדדי שטח, יכולים להיות גם הבדלים בין שני מקורות של נתוני שטח. בעולם אידיאלי הנתונים היו זהים, אבל יש הרבה סיבות לכך שהם שונים.
נתוני מעבדה לעומת נתונים מהשטח
הדבר הראשון שצריך לבדוק הוא אם אתם מסתכלים על מדדי מעבדה (סינתטיים) או על מדדי שדה (RUM). אמנם טבעי להניח שמוצרי RUM בודקים רק נתוני שדה, אבל רבים מהם מציעים גם רכיב מעבדה.
נתוני מעבדה הם שימושיים מאוד, בדיוק בגלל התנאים הקבועים שבהם הם נמדדים. אפשר להשתמש בו כדי לעקוב אחרי שינויים בלתי צפויים או רגרסיות בסביבת ייצור, בלי הרעש של אוכלוסיית שדה משתנה. עם זאת, יכול להיות שנתוני המעבדה לא ייצגו את חוויית המשתמש בפועל, ולכן המדדים בשטח יכולים להציג תוצאות שונות לגמרי.
אוכלוסיות
יכול להיות שקבוצות הנתונים שמשמשות את פתרונות CrUX ו-RUM יהיו שונות בגלל הבדלים בביקורים בדפים שנמדדים, בהתאם לדפדפנים, למשתמשים, לאתרים ולמכשירים שמשווים ביניהם.
דפדפנים כלולים
הדוח לגבי חוויית המשתמש ב-Chrome, כפי ששמו מרמז, מיועד ל-Chrome בלבד. יש הרבה דפדפנים שמבוססים על Chromium (למשל Edge, Opera ו-Brave) שחולקים חלק גדול מבסיס הקוד של Chrome, אבל רק משתמשי 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, אבל יכול להיות שקבוצת המדדים שלהם תהיה מוגבלת יותר. לדוגמה, שינוי פריסה מצטבר (CLS) זמין רק בדפדפנים שמבוססים על Chromium. מדדים אחרים שמבוססים על רינדור, כמו LCP, INP ואפילו הצגת תוכן ראשוני (FCP), יכולים להימדד בצורה שונה לגמרי (ראו בהמשך).
משתמשים שהביעו הסכמה
בנוסף לכך שהנתונים מוגבלים למשתמשי Chrome, הם מוגבלים עוד יותר כי הם מודדים רק קבוצת משנה של משתמשי Chrome שהביעו הסכמה לשתף את נתוני CrUX כשהדפדפן הותקן.
בנוסף, ספקי RUM בודקים רק קבוצת משנה של משתמשים, בדרך כלל בגלל בקשות בהודעות על שימוש בקובצי Cookie – שבהן המשתמשים מתבקשים להביע הסכמה לאיסוף נתוני RUM – או בגלל חסימות מעקב. זה יכול להשפיע לרעה על חלק מ<b>טעינות הדף</b> הראשוניות אם האישור לא ניתן עד לדף השני או לדפים הבאים, כשחלק מהנכסים של האתר כבר נשמרו במטמון מדפים קודמים. אם זה קורה לעיתים קרובות, יכול להיות שהמדדים ייראו טובים יותר ב-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:
הבדלים במדדים
יש הרבה מדדים שמשמשים למדידת ביצועים באינטרנט, לכן כשמשווים בין שתי קבוצות שונות של נתונים, חשוב להבין אילו מדדים נמדדים ואיך משתמשים בהם.
המדדים שנמדדים
נתוני CrUX הם קבוצת הנתונים של Google במסגרת יוזמת Core Web Vitals, והם מודדים בעיקר את המדדים הבאים (LCP, CLS ו-INP), עם כמה מדדים נוספים שמשלימים אותם.
כלי RUM כוללים בדרך כלל את מדדי Core Web Vitals, אבל לעיתים קרובות הם כוללים גם מדדים רבים אחרים. חלק מספקי ה-RUM גם מודדים את חוויית המשתמש באמצעות שילוב משלהם של כל המדדים האלה, אולי כדי לספק "מדד שביעות רצון" או משהו דומה. כשמשווים בין נתוני RUM ל-CrUX, חשוב לוודא שמשווים בין נתונים דומים.
כלים שמעריכים את סטטוס המעבר או הכישלון של Core Web Vitals צריכים להחשיב דף כעובר אם הוא עומד ביעדים המומלצים באחוזון ה-75 לכל מדדי הליבה לבדיקת חוויית המשתמש באתר. אם אין נתוני INP בדפים ללא אינטראקציות, רק LCP ו-CLS צריכים לעבור.
הבדלים במדדים בין דפדפנים שונים
CrUX מודד רק בדפדפני Chrome, ואפשר לעיין ביומני השינויים של Web Vitals כדי לראות איך הם משתנים בכל גרסה של Chrome.
לעומת זאת, פתרונות RUM ימדדו ממגוון רחב יותר של דפדפנים. דפדפנים שמבוססים על Chromium (כמו Edge, Opera וכו') כנראה יהיו דומים ל-Chrome, אלא אם Chrome מיישם שינויים חדשים כפי שצוין ביומן השינויים.
בדפדפנים שאינם מבוססי Chromium, ההבדלים יכולים להיות בולטים יותר. לדוגמה, מדדים שמבוססים על רינדור כמו LCP, INP ו-FCP זמינים ב-Safari וב-Firefox, אבל נמדדים בצורה שונה. זה יכול לגרום להבדלים משמעותיים בזמנים שמדווחים. כמו שציינו קודם, אם אתם רוצים להשוות בין RUM ל-CrUX, מומלץ לסנן רק את משתמשי Chrome כדי לאפשר השוואה בין נתונים דומים.
תזמון המדדים
מדדי Core Web Vitals מסופקים על ידי ממשקי API של דפדפני אינטרנט, אבל זה לא אומר שאין פוטנציאל להבדלים בערכים שמדווחים באמצעותם. הבדלים יכולים לנבוע גם מהמועד שבו נמדד המדד – בזמן טעינת הדף או לאורך כל מחזור החיים של הדף. כלי RUM לא תמיד מודדים את המדדים באותו אופן, גם אם הם משתמשים באותם שמות ובאותם ממשקי API של הדפדפן כדי לקבל את הנתונים, וזה יכול להיות מבלבל.
המהירות שבה נטען רכיב התוכן הכי גדול (LCP) היא מדד של טעינת דף. אם אלמנטים גדולים יותר נטענים אחרי הרינדור הראשוני, יכול להיות ש-Web API ידווח על כמה אלמנטים של LCP. הרכיב הסופי של ה-LCP הוא כשהדף מסיים להיטען או כשהמשתמש יוצר אינטראקציה עם הדף. לכן, יכולים להיות הבדלים אם רכיב ה-LCP מדווח לפני שני האירועים האלה.
בנוסף, בנתוני השדה, רכיב ה-LCP יכול להיות שונה בהתאם לאופן שבו הדף נטען. בטעינת דף כברירת מחדל שבה מוצג החלק העליון של תוכן הדף, רכיב ה-LCP יהיה תלוי בעיקר בגודל המסך. עם זאת, אם הדף נפתח באמצעות קישור לכותרת בהמשך המסמך, או נפתח באופן דומה באמצעות קישור עומק לאפליקציה של דף יחיד (SPA) – עוד על כך בהמשך – רכיב ה-LCP יכול להיות שונה.
אל תניחו שזמני ה-LCP שמופיעים ב-CrUX או ב-RUM מבוססים על אותו רכיב כמו בכלי המעבדה. בעוד ש-CrUX ייתן לכם את ערך ה-LCP הכולל לכל דף או מקור, RUM יכול לפלח את הנתונים האלה עוד יותר כדי לזהות סשנים ספציפיים עם בעיות ב-LCP.
מדד היציבות החזותית (CLS) נמדד לאורך כל משך החיים של הדף, כך שייתכן שה-CLS הראשוני של טעינת הדף לא מייצג דפים שגורמים לתזוזות גדולות יותר בהמשך, אחרי שהדף נטען והמשתמש קיים איתו אינטראקציה. לכן, אם מודדים את ערך ה-CLS רק אחרי טעינת הדף (כמו שקורה בהרבה מוצרי RUM), מקבלים תוצאה שונה מאשר אם מודדים את ערך ה-CLS אחרי שהמשתמש מסיים את הפעילות בדף.
כדי למדוד את מדד הרספונסיביות מהירות התגובה לאינטראקציה באתר (INP), נדרש קלט. המדד בודק את כל האינטראקציות של קליקים, הקשות ומקלדת לאורך כל חיי הדף, באופן דומה ל-CLS. לכן, הערך המדווח של INP עשוי להיות שונה מאוד אם הוא נמדד אחרי שהמשתמש ביצע מספר אינטראקציות בדף.
CrUX יפעל לפי המסמכים של Core Web Vitals וימדוד את המדדים האלה לאורך כל משך החיים של הדף. מסיבות שונות, ספקי RUM רבים בוחרים למדוד את המדדים האלה אחרי טעינת הדף או במועד אחר (לדוגמה, כשלוחצים על קריאה מרכזית לפעולה).
אם אתם רואים הבדלים לא מוסברים בין שני מקורות הנתונים, חשוב שתבינו מספק ה-RUM מתי נמדדים נתוני Core Web Vitals.
אפליקציות דף יחיד
אפליקציות דף יחיד (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, אבל ההבדלים העיקריים מצוינים גם בקטעים הבאים.
מטמון לדף הקודם/הבא (bfcache)
ב-CrUX, שחזורים של מטמון לדף הקודם/הבא (או bfcache) נחשבים לניווטים בדפים, למרות שהם לא גורמים לטעינת דף רגילה. ממשקי ה-API לאינטרנט לא מתייחסים למקרים האלה כטעינת דף, ולכן פתרונות RUM צריכים לבצע שלבים נוספים כדי שהדפים האלה ייספרו אם הם רוצים להתאים ל-CrUX. הדפים האלה נטענים הרבה יותר מהר, ולכן הם יכולים לשפר את הביצועים הכוללים שמדווחים על האתר. אם לא תכללו אותם, יכול להיות שהמדדים הכוללים של ביצועי הדפים יהיו פחות טובים. כדאי לבדוק אם פתרון ה-RUM שלכם מטפל בדפים ששוחזרו מ-bfcache.
מסגרות iframe
מטעמי אבטחה ופרטיות, לדפים ברמה העליונה אין גישה לתוכן בתוך רכיבי iframe (אפילו לא לרכיבי iframe מאותו מקור). המשמעות היא שאפשר למדוד את מדדי הביצועים של התוכן ב-iframe רק באמצעות ה-iframe עצמו, ולא באמצעות ממשקי ה-API לאינטרנט בדף שמכיל את ה-iframe. אם תוכן ה-iframe כולל את רכיב ה-LCP, או תוכן שמשפיע על ה-CLS או ה-INP שהמשתמש חווה, הוא לא יהיה זמין לפתרונות RUM (כולל ספריית JavaScript של Google web-vitals).
לעומת זאת, CrUX נמדד על ידי דפדפן Chrome עצמו ולא על ידי JavaScript בדף, ולכן אין לו את המגבלות האלה והוא מודד מדדים בתוך רכיבי iframe כשמדווחים על Core Web Vitals. השיטה הזו משקפת בצורה מדויקת יותר את חוויית המשתמש, אבל היא יכולה להיות סיבה נוספת להבדלים באתרים שמשתמשים ב-iframe.
דוגמה קונקרטית לאופן שבו זה יכול להוביל להבדלים בין נתוני LCP ב-CrUX וב-RUM היא רכיבי <video> מוטמעים. הפריים הראשון שצויר של רכיב <video> שמופעל אוטומטית בתוך השורה יכול להיחשב כמועמד ל-LCP, אבל הטמעות של שירותי סטרימינג פופולריים של וידאו עשויות להציב את הרכיבים האלה ב-<iframe>. CrUX יכול להביא את זה בחשבון, כי יש לו גישה לתוכן של <iframe>, אבל לפתרונות RUM אין גישה כזו.
משאבים ממקורות שונים
יכול להיות שמדיה של LCP שמוצגת מדומיינים אחרים לא תספק זמן רינדור ב-PerformanceObserver API, אלא אם צוין הכותרת Timing-Allow-Origin (TAO), בגלל הגבלות אבטחה של הדפדפן שנועדו לצמצם התקפות תזמון. במקרה כזה, הדפדפן משתמש בזמן הטעינה של המשאב, אבל יכול להיות שהזמן הזה שונה מאוד מהזמן שבו התוכן צויר בפועל.
זה יכול להוביל למצב שנראה בלתי אפשרי, שבו ממשקי API לאינטרנט מדווחים על LCP מוקדם יותר מ-FCP. זה לא המצב, אבל זה נראה כך בגלל מגבלת האבטחה הזו.
הבעיה הזו נפתרה בסוף 2024, וזמן רינדור מעט פחות מדויק זמין החל מגרסה 133 של Chrome גם כשלא מספקים את 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 משפיעים על המדדים שלכם בצורה חיובית או שלילית? האם זה נותן לך יותר תובנות לגבי המקומות שבהם יש בעיות בביצועים שניתן לתעדף?
אם משתמשים בדפדפנים אחרים מקבלים תוצאות שונות, אתם יכולים להשתמש בתובנה החשובה הזו שקיבלתם מ-RUM כדי לבצע אופטימיזציה בצורה אחרת. לדוגמה, ממשקי API מסוימים לא זמינים בדפדפנים מסוימים, אבל אתם יכולים לשקול חלופות לדפדפנים לא נתמכים כדי לשפר גם את החוויה שלהם. אפשר גם לספק חוויה שונה, אבל עם ביצועים טובים יותר, למשתמשים במכשירים או ברשתות עם מגבלות. הדוח על חוויית המשתמש ב-Chrome מוגבל לנתונים מ-Chrome, אבל כדאי להביא בחשבון את החוויות של כל המבקרים באתר כדי לתעדף את השיפורים. נתוני RUM יכולים למלא את הפער הזה.
אחרי שתבינו את הסיבות להבדלים, שני הכלים יוכלו לעזור לכם להבין את חוויית המשתמש באתר ולשפר אותה, גם אם המספרים לא זהים. אתם יכולים להשתמש בנתוני RUM כדי להשלים את נתוני CrUX, ולפלח את התנועה כדי להבין לעומק את הנתונים הכלליים שמוצגים ב-CrUX. כך תוכלו לזהות אם יש אזורים מסוימים באתר או בבסיס המשתמשים שדורשים התייחסות.
בדרך כלל, חשוב יותר לבחון את המגמות כדי לראות אם השיפורים שביצעתם מניבים את ההשפעות החיוביות הצפויות, מאשר לוודא שכל מספר תואם בדיוק בין שני מקורות הנתונים. כמו שציינו קודם, RUM מאפשר לכם לבחון מסגרות זמן שונות כדי לקבל תצוגה מקדימה של ציוני CrUX ל-28 ימים. עם זאת, מסגרות זמן קצרות מדי יכולות להוביל לנתונים רועשים, ולכן CrUX משתמש ב-28 ימים.
בדרך כלל אין תשובה "נכונה" או "שגויה" במדדים השונים האלה – הם פשוט מספקים נקודת מבט שונה על המשתמשים ועל החוויה שלהם באתר. כל עוד אתם מבינים למה ההבדלים האלה קורים ואיך הם יכולים להשפיע על קבלת ההחלטות שלכם, זה מה שחשוב כדי לשפר את חוויית המבקרים באתר.