הסיבות לכך שנתוני 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. לאחר מכן ניתן להתאים את המדדים האלה, שספציפיים לאתר, לשיפורי הליבה לבדיקת חוויית המשתמש באתר ולמדדים העסקיים.
הבדלים בין שתי קבוצות של נתוני שדה
גבר עם שעון יודע מה השעה. איש עם שני שעונים אף פעם לא בטוח.
חוק סגל
כשיש שני מקורות נתונים, לרוב קשה להבין למה יש הבדלים ביניהם. בדומה לחשיבות ההבנה של ההבדל בין מדדים במעבדה לבין מדדים בשטח, יכולים להיות גם הבדלים בין שני מקורות של נתוני שטח. בעולם אידיאלי, הנתונים היו זהים, אבל יש הרבה סיבות לכך שהם עשויים להיות שונים.
נתוני שיעור Lab לעומת נתוני שטח
הדבר הראשון שצריך לבדוק הוא אם מדובר במדדים מעבדתיים (סינתטיים) או במדדים בשטח (RUM). הגיוני להניח שמוצרי RUM בודקים רק נתונים מהשדה, אבל רבים מהם מציעים גם רכיב מעבדה.
נתוני שיעור ה-Lab שימושיים במיוחד בזכות התנאים הקבועים שבהם הם מודדים. אפשר להשתמש בה כדי לעקוב אחרי שינויים לא צפויים או רגרסיות בסביבת הייצור, בלי רעשי רקע של אוכלוסיית שדות משתנה. עם זאת, יכול להיות שנתוני שיעור ה-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, שבהם לרוב מובנים אותם מדדים (כמו 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:
הבדלים במדדים
יש הרבה מדדים שמשמשים למדידת הביצועים באינטרנט, ולכן כשמשווים בין שתי קבוצות נתונים שונות, חשוב להבין אילו מדדים נמדדים ואיך נעשה שימוש במדדים האלה.
המדדים שנמדדים
נתוני 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.
Cumulative Layout Shift (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, אבל ההבדלים העיקריים מפורטים גם בקטעים הבאים.
מטמון לדף הקודם/הבא
ב-CrUX, שחזור של מטמון לדף הקודם/הבא (או bfcache) נחשב לניווט בדפים, גם אם הוא לא מוביל לטעינה רגילה של דף. ממשקי ה-API באינטרנט לא מתייחסים למקרים האלה כטעינת דף, ולכן פתרונות RUM צריכים לבצע פעולות נוספות כדי שהדפים האלה ייספרו אם הם תואמים ל-CrUX. מדובר בטעינות דפים מהירות יותר באופן משמעותי, שעשויות להוביל לדיווח על ביצועים טובים יותר באופן כללי באתר. לכן, אם לא תכללו אותן, מדדי הביצועים הכוללים של הדפים עשויים להיות גרועים יותר. צריך לבדוק בפתרון ה-RUM שבו אתם משתמשים כדי לבדוק אם הוא מטפל בדפים משוחזרים במטמון לדף הקודם/הבא.
מסגרות iframe
מטעמי אבטחה ופרטיות, לדפים ברמה העליונה אין גישה לתוכן בתוך מסגרות iframe (אפילו מסגרות iframe מאותו מקור). המשמעות היא שמדדי הביצועים של התוכן בפריימים האלה ניתנים למדידה רק על ידי ה-iframe עצמו, ולא באמצעות ממשקי ה-API של האינטרנט בדף שמכיל את ה-iframe. אם תוכן ה-iframe כולל את רכיב ה-LCP או תוכן שמשפיע על ה-CLS או ה-INP של המשתמש, הוא לא יהיה זמין לפתרונות RUM (כולל ספריית JavaScript של מדדי ה-Web Vitals של Google).
עם זאת, ב-CrUX נמדדת באמצעות דפדפן Chrome עצמו ולא באמצעות JavaScript בדף, המגבלות האלו לא חלות, וכך גם המדדים במסגרות iframe מדווחים על מדדי ליבה לבדיקת חוויית המשתמש באתר. הנתון הזה משקף בצורה מדויקת יותר את חוויית המשתמש, אבל הוא יכול להיות סיבה נוספת להבדלים בין אתרים שמשתמשים ב-iframes.
דוגמה קונקרטית אחת לאופן שבו המצב הזה יכול להוביל להבדלים בין נתוני LCP ב-CrUX לבין נתוני LCP ב-RUM מפורטת בקטע <video>. הפריים הראשון שצויר של רכיב <video> שפועל בהפעלה אוטומטית ב-playsinline יכול להיחשב כ-LCP פוטנציאלי, אבל הטמעות של שירותי סטרימינג פופולריים של וידאו עשויות למקם את הרכיבים האלה ב-<iframe>. המערכת של CrUX יכולה להביא בחשבון את הנתונים האלה כי יש לה גישה לתוכן של <iframe>, אבל פתרונות RUM לא יכולים לעשות זאת.
משאבים ממקורות שונים
מדיה מסוג LCP שמוצגת מדומיינים אחרים לא מספקת זמן עיבוד ב-PerformanceObserver API, אלא אם הכותרת Timing-Allow-Origin (TAO) מסופקת – בגלל הגבלות אבטחה בדפדפן שנועדו לצמצם התקפות תזמון. במקרה כזה, המערכת חוזרת לזמן הטעינה של המשאב, אבל יכול להיות שהזמן הזה יהיה שונה מאוד מהזמן שבו התוכן נצבע בפועל.
מצב כזה עלול להוביל למצב שנראה בלתי אפשרי, שבו זמן הטעינה של התוכן הוויזואלי המשמעותי (LCP) מדווח על ידי ממשקי API לאינטרנט מוקדם יותר מזמן הטעינה הראשונית של דף הנחיתה (FCP). זה לא המצב, אלא רק בגלל הגבלת האבטחה הזו.
שוב, מערכת 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