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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תיעוד השינויים בגרסאות

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

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

הרצת ניסויים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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