שיטות מומלצות למדידת Web Vitals בשדה

איך מודדים את Web Vitals באמצעות הכלי הקיים לניתוח נתונים.

Philip Walton

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

מעקב אחר משתמשים אמיתיים (Real User Monitoring) (RUM) ספקי ניתוח נתונים כבר תומכים במדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר (וגם מדדים נוספים של Web Vitals). אם אתם באחד מהכלים האלה לניתוח נתונים של RUM, אתם מוכנים לבדוק עד כמה הדפים באתר עומדים במדדי הליבה לבדיקת חוויית המשתמש באתר (Core Web Vitals) המומלצים סכומי סף ולמנוע רגרסיות. הוא בעתיד.

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

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

שימוש במדדים או באירועים מותאמים אישית

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

בדרך כלל, מדידה של מדדים או אירועים מותאמים אישית בכלי לניתוח נתונים תהליך שמורכב משלושה שלבים:

  1. הגדרה או אוגר המדד המותאם אישית במנהל המערכת של הכלי (אם נדרש). (הערה: לא הכול ספקי ניתוח נתונים דורשים הגדרה מראש של מדדים מותאמים אישית.)
  2. מחשבים את ערך המדד בקוד JavaScript של הקצה הקדמי.
  3. שולחים את ערך המדד לקצה העורפי של ניתוח הנתונים, ומוודאים שהשם או המזהה שלו תואם למה שהוגדר בשלב 1 (שוב, אם צריך).

עבור שלבים 1 ו-3, ניתן לעיין במסמכים של הכלי לניתוח נתונים: הוראות להתאמה אישית. בשלב 2 אפשר להשתמש ספריית ה-JavaScript של web-vitals לחשב את הערך של כל אחד ממדדי הליבה לבדיקת חוויית המשתמש באתר.

דוגמת הקוד הבאה מראה עד כמה קל לעקוב אחר המדדים האלה ולשלוח אותם לשירות ניתוח נתונים.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

הימנעות מממוצעים

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

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

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

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

מוודאים שאפשר לדווח על התפלגות

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

כדי לוודא שאתם עומדים בדרישות המומלצות לגבי Core Web Vitals ערכי הסף, תצטרכו את הדוח כדי להציג את הערך של כל מדד באחוזון ה-75.

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

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

הדוח Web Vitals דוגמה לשיטה הזו שמשתמשת ב-Google Analytics. הקוד עבור הדוח הוא קוד פתוח, כדי שמפתחים יוכלו להתייחס אליה כדוגמה לשיטות שתוארו .

צילומי מסך של דוח ה-Web Vitals לדיווח

שליחת הנתונים בזמן הנכון

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

עם זאת, הדבר עלול להיות בעייתי, מכיוון שה-beforeunload וגם unload אירועים אינם מהימנים (במיוחד בנייד), והשימוש בהם מומלץ (מכיוון שהם יכולים למנוע מדף להיות כשיר להעברה מסוג אחורה מטמון).

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

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

מעקב אחר ביצועים לאורך זמן

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

גרסאות של השינויים

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

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

הפעלת ניסויים

אפשר לקחת את ניהול הגרסאות צעד אחד קדימה על ידי מעקב אחר מספר גרסאות (או ניסויים) בו-זמנית.

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

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

מוודאים שמדידה לא משפיעה על הביצועים

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

תמיד לפעול לפי העקרונות האלה כשפורסים קוד ניתוח RUM אתר ייצור:

דחיית ניתוח הנתונים

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

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

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

אין ליצור משימות ארוכות

הקוד של Analytics רץ בדרך כלל בתגובה לקלט של משתמשים, אבל אם הקוד שלכם לניתוח נתונים מבצע הרבה מדידות DOM או משתמש בממשקי API אחרים שצורכים הרבה מעבדים הקוד של ניתוח הנתונים עצמו עלול לגרום לתגובה נמוכה של קלט. בנוסף, אם קובץ ה-JavaScript שמכיל את קוד ניתוח הנתונים הוא גדול, והקובץ מופעל יכול לחסום את ה-thread הראשי ולהשפיע לרעה על האינטראקציה עד התגובה הבאה (INP) של דף.

שימוש בממשקי API ללא חסימה

ממשקי API כמו sendBeacon() וגם requestIdleCallback() הן תוכננו במיוחד להרצת משימות לא קריטיות, לחסום משימות קריטיות למשתמש.

ממשקי ה-API האלה הם כלים מעולים בספריית ניתוח נתונים של RUM.

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

אין צורך לעקוב אחר יותר ממה שצריך

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

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

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