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

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

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

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

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

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

היתרונות של השלמת CrUX באמצעות פתרון RUM

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

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

ניתוח מעמיק יותר לחקירת בעיות

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

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

התאמה למדדים עסקיים אחרים

RUM גם מאפשר לכם להשוות ישירות את מדדי הביצועים באינטרנט למדדים עסקיים כלשהם. כך תוכלו לראות איזה ערך יש בהשקעה בביצועים ואילו אחרים כדאי לתעדף. יש לנו מספר מקרים לדוגמה עם עסקים שעוסקים בהתאמה כזו, כמו Farfetch או The Economic Times.

איסוף נתוני ביצועים אחרים

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

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

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

חוק סגל

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

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

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

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

אוכלוסיות

מערכי הנתונים שמשמשים את הפתרונות של 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 שלעיתים קרובות יש בהם אותם מדדים (כמו מדדי ליבה לבדיקת חוויית המשתמש באתר) מובנים. גם דפדפנים שאינם מבוססי Chromium נמדדים על ידי פתרונות RUM, אבל ייתכן שסדר המדדים שלהם יהיה מוגבל יותר. לדוגמה, התכונות Cumulative Layout Shift (CLS) ו-Intraction to Next Paint (INP) זמינות כרגע רק בדפדפנים המבוססים על Chromium. מדדים אחרים, כמו הצגת תוכן ראשוני (FCP), עשויים להימדד באופן שונה (פרטים בהמשך).

משתמשים שהביעו הסכמה

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

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

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

תזמון המדדים

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

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

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

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

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

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

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

מסגרות iframe

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

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

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

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

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

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

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

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

אישורים

תמונה ממוזערת מאת סטיבן להאם ב-UnFlood