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

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

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

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

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

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

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

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

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

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

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

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