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

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

פיליפ וולטון

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

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

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

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

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

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

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

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

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

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

import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אני לא רוצה ליצור משימות ארוכות

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

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

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

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

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

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

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

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

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