איסוף נתונים במדדי האינטרנט של האתר הוא הצעד הראשון לשיפור. ניתוח מקיף יכלול איסוף של נתוני ביצועים גם מסביבה אמיתית וגם מסביבת מעבדה. כדי למדוד את מדדי 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 של 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 יש דוגמאות שממחישות איך לשלוח את הנתונים לנקודת קצה (endpoint) גנרית של API, ל-Google Analytics או ל-Google Tag Manager.
אם כבר יש לכם כלי דיווח מועדף, כדאי להשתמש בו. אם לא, אפשר להשתמש ב-Google Analytics בחינם למטרה הזו.
כשבודקים באיזה כלי להשתמש, כדאי לחשוב למי תהיה צורך בגישה לנתונים. כשכל מחלקה מעוניינת לשפר את הביצועים, עסקים בדרך כלל משיגים את השיפורים הגדולים ביותר בביצועים. במאמר שיפור מהירות האתר באופן פונקציונלי מוסבר איך לקבל תמיכה מחלקות שונות.
פרשנות נתונים
כשמנתחים נתוני ביצועים, חשוב לשים לב לקצוות התחתונים והעליונים של ההתפלגות. נתוני RUM בדרך כלל חושפים שהביצועים משתנים מאוד – למשתמשים מסוימים יש חוויה מהירה, ולמשתמשים אחרים חוויה איטית. עם זאת, שימוש במדד החציוני כדי לסכם נתונים עלול להסתיר את ההתנהגות הזו.
כדי לקבוע אם אתר או דף עומדים בערכי הסף המומלצים, Google משתמשת באחוז של חוויות 'טובות' ולא בנתונים סטטיסטיים כמו חציון או ממוצעים. באופן ספציפי, כדי שאתר או דף ייחשבו כעומדים בערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר, 75% מהביקורים בדף צריכים לעמוד בערך הסף 'טוב' בכל מדד.
מדידת מדדי Web Vitals באמצעות נתוני מעבדה
נתוני שיעור ה-Lab, שנקראים גם נתונים סינתטיים, נאספים מסביבה מבוקרת, ולא ממשתמשים אמיתיים. בניגוד לנתוני RUM, אפשר לאסוף נתונים מסביבת הניסוי מסביבות טרום-ייצור, ולכן אפשר לשלב אותם בתהליכי העבודה של המפתחים ובתהליכי השילוב המתמשך. דוגמאות לכלים שאוספים נתונים סינתטיים הם Lighthouse ו-WebPageTest.
לתשומת ליבכם
תמיד יהיו חוסר התאמה בין נתוני RUM לנתוני שיעור ה-Lab, במיוחד אם תנאי הרשת, סוג המכשיר או המיקום של סביבת שיעור ה-Lab שונים באופן משמעותי מזה של המשתמשים. עם זאת, כשמדובר באיסוף נתונים של שיעור Lab על מדדים של Web Vitals, יש כמה שיקולים ספציפיים שחשוב לשים לב אליהם:
- המהירות שבה נטען רכיב התוכן הכי גדול (LCP) שנמדדת בסביבות של שיעור Lab יכולה להיות שונה מאלה שנמדדות בשטח בעזרת נתוני RUM בגלל עיכובים בטעינת הדף (דרך הפניות אוטומטיות, זמן אחזור של התחברות לשרת או נתונים שלא נשמרו במטמון), תוכן שונה שמוצג למשתמשים שונים בהתאם למסך או מסיבות אחרות (כולל מודעות באנר של קובצי cookie, התאמה אישית).
- מדד יציבות חזותית (CLS) שנמדד בסביבות מעבדה יכול להיות נמוך באופן מלאכותי ממדד ה-CLS שנצפה בנתוני RUM. הרבה כלים ב-Lab רק טוענים את הדף – הם לא יוצרים איתו אינטראקציה. כתוצאה מכך, הם מתעדים רק שינויים בפריסה שמתרחשים במהלך הטעינה הראשונית של הדף. לעומת זאת, ה-CLS שנמדד על ידי כלי RUM מתעד שינויי פריסה בלתי צפויים שמתרחשים במהלך כל משך החיים של הדף.
- לא ניתן למדוד את מהירות התגובה לאינטראקציה הבאה (INP) בסביבות של שיעור Lab כי נדרשות אינטראקציות של המשתמש עם הדף. כתוצאה מכך, Total Block Time (זמן החסימה הכולל) (TBT) הוא שרת ה-Proxy המומלץ לשיעור ה-Lab ל-INP. התכונה TBT מודדת את 'משך הזמן הכולל שעבר מ'מהירות התגובה הראשונה' ועד 'זמן התגובה' ל'אינטראקטיבי', שבמהלכו הדף חסום ולא ניתן להגיב לקלט של משתמשים'. למרות ש-INP ו-TBT מחושבים באופן שונה, הן משקפות שרשור ראשי חסום בתהליך האתחול. כשהשרשור הראשי חסום, הדפדפן מתעכב בתגובה לאינטראקציות של משתמשים.
כלים
אפשר להשתמש בכלים הבאים כדי לאסוף מדידות Lab של מדדי Web Vitals:
- כלי הפיתוח של Chrome מודדים את מדדי Core Web Vitals של דף נתון ומדווחים עליהם בתצוגת המדדים החיים בחלונית 'ביצועים'. התצוגה הזו מספקת למפתחים משוב בזמן אמת על הביצועים בזמן שהם מבצעים שינויים בקוד.
- Lighthouse דוח Lighthouse כולל נתונים על LCP, CLS ו-TBT, וגם מדגיש שיפורים אפשריים בביצועים. Lighthouse זמין בכלי הפיתוח של Chrome, כחבילת npm, ואפשר גם לשלב אותו בתהליכי עבודה של אינטגרציה רציפה באמצעות Lighthouse CI.
- הבדיקה של WebPageTest כוללת את מדדי חוויית המשתמש באתר כחלק מהדיווח הרגיל. כלי WebPageTest שימושי לאיסוף מידע על מדדי Web Vitals בתנאים מסוימים של מכשיר ורשת.