איסוף נתונים על מדדי Web Vitals באתר הוא הצעד הראשון לשיפורם. ניתוח מקיף יכלול איסוף של נתוני ביצועים גם מסביבה אמיתית וגם מסביבת מעבדה. כדי למדוד את מדדי Web Vitals נדרשים שינויים מינימליים בקוד, וניתן לעשות זאת באמצעות כלים בחינם.
מדידת מדדי Web Vitals באמצעות נתוני RUM
נתוני מעקב אחר משתמשים אמיתיים (RUM), שנקראים גם נתוני שדה, מתעדים את הביצועים של משתמשים אמיתיים באתר. Google משתמשת בנתוני RUM כדי לקבוע אם אתר עומד בערכי הסף המומלצים של מדדי חוויית המשתמש הבסיסיים (Core Web Vitals).
תחילת העבודה
אם לא הגדרתם RUM, הכלים הבאים יספקו לכם במהירות נתונים על הביצועים בפועל של האתר. כל הכלים האלה מבוססים על אותו מערך נתונים בסיסי (הדוח לגבי חוויית המשתמש ב-Chrome), אבל יש להם תרחישים לדוגמה שונים במקצת:
- כלי הפיתוח של Chrome משולבים עם מערך הנתונים של CrUX בתצוגת המדדים החיים בחלונית 'ביצועים'. השוואה בין החוויה המקומית שלכם לבין חוויות של משתמשים אמיתיים באותו דף תאפשר לכם לקבל החלטה מושכלת יותר לגבי המקום שבו כדאי למקד את מאמצי ניפוי הבאגים. אם אתם מחפשים פעולה אחת שתוכלו לבצע כדי להתחיל למדוד ולשפר את מדדי חוויית המשתמש הבסיסיים (Core Web Vitals) באתר, מומלץ להשתמש בחלונית'ביצועים' של Chrome DevTools.
- PageSpeed Insights (PSI) מדווח על הביצועים המצטברים ברמת הדף וברמת המקור ב-28 הימים האחרונים. בנוסף, מוצגות הצעות לשיפור הביצועים. PSI זמין באינטרנט וכAPI.
- Search Console מדווח על נתוני הביצועים לפי דף. לכן, הוא מתאים במיוחד לזיהוי דפים ספציפיים שצריך לשפר. בניגוד ל-PageSpeed Insights, הדוחות של Search Console כוללים נתוני ביצועים היסטוריים. אפשר להשתמש ב-Search Console רק באתרים שבבעלותכם ואתם מוודאים את הבעלות שלכם עליהם.
- לוח הבקרה של CrUX הוא לוח בקרה מובנה שמציג נתוני CrUX של מקור לבחירתכם. הוא מבוסס על Data Studio ותהליך ההגדרה נמשך בערך דקה. בהשוואה ל-PageSpeed Insights ול-Search Console, הדוחות בלוח הבקרה של CrUX כוללים מאפיינים נוספים. לדוגמה, אפשר לפלח את הנתונים לפי מכשיר וסוג חיבור.
חשוב לציין שלמרות שהכלים שצוינו למעלה מתאימים במיוחד ל'תחילת העבודה' עם מדידת מדדי Web Vitals, הם יכולים להיות שימושיים גם בהקשרים אחרים. במיוחד, גם CrUX וגם PSI זמינים כ-API, וניתן להשתמש בהם כדי ליצור מרכזי בקרה ולצורך דיווח נוסף.
איסוף נתוני RUM
אמנם כלים שמבוססים על CrUX הם נקודת התחלה טובה לבדיקה של ביצועי מדדי Web Vitals, אבל מומלץ מאוד להשלים אותם באמצעות RUM משלכם. נתוני RUM שאתם אוספים בעצמכם יכולים לספק משוב מפורט ומידי יותר לגבי ביצועי האתר. כך קל יותר לזהות בעיות ולבדוק פתרונות אפשריים.
אתם יכולים לאסוף נתוני RUM משלכם באמצעות ספק RUM ייעודי, או להגדיר כלים משלכם.
ספקי RUM ייעודיים מתמחים באיסוף נתוני RUM ובדיווח עליהם. כדי להשתמש ב-Core Web Vitals עם השירותים האלה, צריך לפנות לספק RUM ולבקש ממנו להפעיל מעקב אחר מדדי הליבה לבדיקת חוויית המשתמש באתר.
אם אין לכם ספק RUM, יכול להיות שתוכלו להשתמש בספריית JavaScript של web-vitals כדי להרחיב את הגדרת ניתוח הנתונים הקיימת שלכם, כך שתהיה לכם אפשרות לאסוף את המדדים האלה ולדווח עליהם. בהמשך מוסבר בהרחבה על השיטה הזו.
ספריית JavaScript של מדדי ה-Web Vitals
אם אתם מטמיעים הגדרה משלכם של RUM ל-Web Vitals, הדרך הקלה ביותר לאסוף מדידות של Web Vitals היא להשתמש בספריית JavaScript web-vitals. web-vitals היא ספרייה מודולרית קטנה (כ-2KB) שמספקת ממשק API נוח לאיסוף ולדיווח על כל אחד מהמדדים של Web Vitals שניתנים למדידה בשטח.
לא כל המדדים שמרכיבים את מדדי Web Vitals נחשפים ישירות על ידי ממשקי ה-API המובנים של הביצועים בדפדפן, אלא נבנים על גביהם. לדוגמה, מדד יציבות חזותית (CLS) מוטמע באמצעות Layout Instability API. כשמשתמשים ב-web-vitals, אין צורך לדאוג להטמעה של המדדים האלה בעצמכם. בנוסף, המערכת מבטיחה שהנתונים שאתם אוספים תואמים לשיטה ולשיטות המומלצות לכל מדד.
מידע נוסף על הטמעת web-vitals זמין במסמכי התיעוד ובמדריך שיטות מומלצות למדידת מדדי Web Vitals בשטח.
צבירת נתונים
חשוב מאוד לדווח על המדידות שנאספו על ידי web-vitals. אם הנתונים האלה נמדדים אבל לא מדווחים, אף פעם לא תראו אותם. במסמכי העזרה של web-vitals יש דוגמאות להעברת הנתונים לנקודת קצה גנרית ל-API, ל-Google Analytics או ל-Google Tag Manager.
אם כבר יש לכם כלי דיווח מועדף, כדאי להשתמש בו. אם לא, אפשר להשתמש ב-Google Analytics בחינם למטרה הזו.
כשבודקים באיזה כלי להשתמש, כדאי לחשוב למי תהיה צורך בגישה לנתונים. בדרך כלל, העסקים משיגים את השיפורים המשמעותיים ביותר בביצועים כשכל החברה, ולא רק מחלקה אחת, מעוניינת לשפר את הביצועים. במאמר שיפור מהירות האתר באופן פונקציונלי מוסבר איך לקבל תמיכה מחלקות שונות.
פרשנות נתונים
כשמנתחים נתוני ביצועים, חשוב לשים לב לקצוות התחתונים של ההתפלגות. נתוני RUM בדרך כלל חושפים שינויים משמעותיים בביצועים – למשתמשים מסוימים יש חוויה מהירה, ולמשתמשים אחרים חוויה איטית. עם זאת, שימוש במדד החציוני כדי לסכם נתונים עלול להסתיר את ההתנהגות הזו.
בנוגע ל-Web Vitals, Google משתמשת באחוז החוויה 'הטובה', ולא בנתונים סטטיסטיים כמו חציון או ממוצע, כדי לקבוע אם אתר או דף עומדים בערכי הסף המומלצים. באופן ספציפי, כדי שאתר או דף ייחשבו כעומדים בערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר, 75% מהביקורים בדף צריכים לעמוד בערך הסף 'טוב' לכל מדד.
מדידת מדדי Web Vitals באמצעות נתוני מעבדה
נתוני מעבדה, שנקראים גם נתונים סינתטיים, נאספים מסביבה מבוקרת ולא ממשתמשים אמיתיים. בניגוד לנתוני RUM, אפשר לאסוף נתונים מסביבת הניסוי מסביבות טרום-ייצור, ולכן אפשר לשלב אותם בתהליכי העבודה של המפתחים ובתהליכי השילוב המתמשך. דוגמאות לכלים שאוספים נתונים סינתטיים הם Lighthouse ו-WebPageTest.
לתשומת ליבכם
תמיד יהיו אי-התאמות בין נתוני RUM לנתוני המעבדה – במיוחד אם תנאי הרשת, סוג המכשיר או המיקום של סביבת המעבדה שונים באופן משמעותי מאלה של המשתמשים. עם זאת, כשמדובר באיסוף נתוני מעבדה לגבי מדדי Web Vitals בפרט, יש כמה שיקולים ספציפיים שחשוב לשים לב אליהם:
- הזמן שבו נטען רכיב התוכן הכי גדול (LCP) שנמדד בסביבות מעבדה עשוי להיות שונה מהזמן שנמדד בשטח באמצעות נתוני RUM, בגלל עיכובים בחיוב הדף (דרך הפניות אוטומטיות, זמן אחזור להתחברות לשרת או נתונים שלא אוחסנו במטמון), תוכן שונה שמוצג למשתמשים שונים בהתאם למסך או מסיבות אחרות (כולל מודעות באנר עם קובצי cookie, התאמה אישית).
- מדד יציבות חזותית (CLS) שנמדד בסביבות מעבדה יכול להיות נמוך באופן מלאכותי ממדד ה-CLS שנצפה בנתוני RUM. כלים רבים ב-Lab רק טוענים את הדף – הם לא יוצרים איתו אינטראקציה. כתוצאה מכך, הם מתעדים רק שינויים בפריסה שמתרחשים במהלך הטעינה הראשונית של הדף. לעומת זאת, ה-CLS שנמדד באמצעות כלים למעקב אחר ביצועי האתר מתעד שינויי פריסה בלתי צפויים שמתרחשים במהלך כל משך החיים של הדף.
- אי אפשר למדוד את המדד מהירות התגובה לאינטראקציה באתר (INP) בסביבות מעבדה כי הוא מחייב אינטראקציות של משתמשים עם הדף. לכן, Total Blocking Time (TBT) הוא שרת ה-proxy המומלץ ל-INP במעבדה. המדד TBT מודד את "משך הזמן הכולל בין הצגת התוכן הראשוני לבין הזמן עד לפעילות מלאה, שבמהלכו הדף חסום ולא יכול להגיב לקלט של משתמשים". אמנם החישוב של INP ו-TBT שונה, אבל שניהם משקפים פעילות של שרשור ראשי חסום במהלך תהליך האתחול. כשהשרשור הראשי חסום, הדפדפן מגיב לאינטראקציות של משתמשים באיחור.
כלים
אפשר להשתמש בכלים האלה כדי לאסוף מדידות מעבדה של מדדי Web Vitals:
- כלי הפיתוח של Chrome מודדים את מדדי Core Web Vitals של דף נתון ומדווחים עליהם בתצוגת המדדים החיים בחלונית 'ביצועים'. התצוגה הזו מספקת למפתחים משוב בזמן אמת על הביצועים בזמן שהם מבצעים שינויים בקוד.
- Lighthouse דוח Lighthouse כולל נתונים על LCP, CLS ו-TBT, וגם מדגיש שיפורים אפשריים בביצועים. Lighthouse זמין בכלי הפיתוח של Chrome, כחבילת npm, ואפשר גם לשלב אותו בתהליכי עבודה של אינטגרציה רציפה באמצעות Lighthouse CI.
- WebPageTest כולל את מדדי Web Vitals כחלק מהדיווח הרגיל שלו. כלי WebPageTest שימושי לאיסוף מידע על מדדי Web Vitals בתנאים מסוימים של מכשיר ורשת.