איסוף נתונים על מדדי חוויית המשתמש באתר (Web Vitals) הוא הצעד הראשון לשיפור שלהם. באמצעות ניתוח מקיף היטב, המערכת תאסוף נתוני ביצועים גם מסביבות בעולם האמיתי וגם בסביבות שיעורי Lab. כדי למדוד את מדדי Web Vitals נדרשים שינויים מינימליים בקוד, ואפשר לעשות זאת באמצעות כלים חינמיים.
מדידת Web Vitals באמצעות נתוני RUM
נתוני Real User Monitoring (RUM), שנקראים גם נתוני שדות, מתעדים את הביצועים שחוו משתמשים בפועל באתר. Google משתמשת בנתוני RUM כדי לקבוע אם אתר עומד בערכי הסף המומלצים של מדדי ליבה לבדיקת חוויית המשתמש באתר.
איך מתחילים
אם אין לך הגדרת RUM, הכלים הבאים יספקו לך במהירות נתונים על ביצועי האתר שלך בפועל. כל הכלים האלה מבוססים על אותה קבוצת נתונים בסיסית (הדוח לגבי חוויית המשתמש ב-Chrome), אבל יש להם תרחישים שונים מעט:
- PageSpeed Insights (PSI): דוחות של PageSpeed Insights מפרטים את הביצועים המצטברים ברמת הדף וברמת המקור במהלך 28 הימים האחרונים. בנוסף, הוא כולל הצעות לשיפור הביצועים. אם אתם מחפשים פעולה אחת לביצוע כדי להתחיל במדידה ובשיפור של מדדי חוויית המשתמש באתר, מומלץ להשתמש ב-PSI כדי לבדוק את האתר. PSI זמין באינטרנט וכAPI.
- Search Console: Search Console מדווח על נתוני ביצועים על בסיס כל דף בנפרד. כך הדף הזה מתאים לזיהוי דפים ספציפיים שזקוקים לשיפור. בשונה מ-PageSpeed Insights, הדיווח ב-Search Console כולל נתונים היסטוריים של ביצועים. ניתן להשתמש ב-Search Console רק באתרים שבבעלותכם ושאימתתם את הבעלות עליהם.
- לוח הבקרה של CrUX: לוח הבקרה של CrUX הוא לוח בקרה שנוצר מראש, ומוצגים בו נתוני CrUX לבחירתכם. היא מבוססת על Data Studio ותהליך ההגדרה נמשך כדקה. בהשוואה ל-PageSpeed Insights ול-Search Console, הדיווח במרכז הבקרה של CrUX כולל יותר מאפיינים. לדוגמה, אפשר לחלק את הנתונים לפי מכשיר וסוג חיבור.
חשוב לציין: על אף שהכלים המפורטים למעלה מתאימים מאוד למדידת חוויית המשתמש של Web Vitals, הם יכולים להועיל לכם גם בהקשרים אחרים. באופן ספציפי, גם CrUX וגם PSI זמינים כ-API וניתן להשתמש בהם כדי ליצור מרכזי בקרה ודוחות אחרים.
איסוף נתוני RUM
למרות שכלים מבוססי CrUX הם נקודת התחלה טובה לבדיקת הביצועים של מדדי חוויית המשתמש באתר, מומלץ מאוד להוסיף להם RUM משלכם. נתוני RUM שאתם אוספים בעצמכם יכולים לספק משוב מפורט ומיידי יותר לגבי ביצועי האתר. כך קל יותר לזהות בעיות ולבדוק פתרונות אפשריים.
תוכלו לאסוף נתוני RUM משלכם באמצעות ספק RUM ייעודי, או על ידי הגדרת כלים משלכם.
ספקי RUM ייעודיים מתמחים באיסוף נתוני RUM ודיווח עליהם. כדי להשתמש במדדי ליבה לבדיקת חוויית המשתמש באתר בשירותים האלה, צריך לבקש מספק ה-RUM להפעיל מעקב אחר מדדי ליבה לבדיקת חוויית המשתמש באתר.
אם אין לכם ספק של RUM, תוכלו להרחיב את ההגדרה הקיימת של ניתוח הנתונים כדי לאסוף את המדדים האלה ולדווח עליהם באמצעות ספריית JavaScript של web-vitals. שיטה זו מוסברת בפירוט בהמשך.
ספריית JavaScript של מאפייני אינטרנט
אם אתם מטמיעים הגדרת RUM משלכם למדדי Web Vitals, הדרך הקלה ביותר לאסוף מדידות של Web Vitals היא להשתמש בספריית ה-JavaScript web-vitals. web-vitals היא ספרייה מודולרית קטנה (כ-1KB) שמספקת ממשק API נוח לאיסוף ולדיווח על כל אחד מהמדדים של Web Vitals המדדים לשדות.
המדדים שמרכיבים את מדדי חוויית המשתמש באתר לא נחשפים באופן ישיר על ידי ממשקי ה-API המובנים של הדפדפן לשיפור הביצועים, אלא הם מבוססים על המדדים האלה. לדוגמה, Cumulative Layout Shift (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 משתמשת באחוז של חוויות "טובות", ולא בנתונים סטטיסטיים כמו חציון או ממוצעים, כדי לקבוע אם אתר או דף עומדים בערכי הסף המומלצים. באופן ספציפי, כדי שאתר או דף ייחשבו כעומדים בערכי הסף של דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), 75% מהביקורים בדף צריכים להגיע לסף 'טוב' בכל מדד.
מדידת Web Vitals באמצעות נתוני מעבדה
נתוני שיעור ה-Lab, שנקראים גם נתונים סינתטיים, נאספים מסביבה מבוקרת, ולא ממשתמשים בפועל. בניגוד לנתוני RUM, את הנתונים של שיעור ה-Lab אפשר לאסוף מסביבות טרום-ייצור, ולכן לשלב אותם בתהליכי העבודה של המפתחים ובתהליכי אינטגרציה רציפים. דוגמאות לכלים שאוספים נתונים סינתטיים: Lighthouse ו-WebPageTest.
לתשומת ליבכם
תמיד יהיו אי-התאמות בין נתוני RUM לבין נתוני שיעור Lab, במיוחד אם תנאי הרשת, סוג המכשיר או המיקום של סביבת שיעור ה-Lab שונים באופן משמעותי מאלו של המשתמשים. עם זאת, כשמדובר באיסוף נתונים של שיעורי Lab במיוחד במדדים של Web Vitals, יש שני שיקולים ספציפיים שחשוב לציין:
- Cumulative Layout Shift (CLS): הערך של Cumulative Layout Shift (CLS) שנמדד בסביבות מעבדה יכול להיות נמוך באופן מלאכותי מה-CLS שנמדד בנתוני RUM. CLS מוגדר כ "סך הכולל של כל הציונים הנפרדים של שינויי הפריסה עבור כל שינוי פריסה לא צפוי שמתרחש במהלך כל משך החיים של הדף". עם זאת, משך החיים של דף בדרך כלל שונה מאוד, תלוי אם הוא נטען על ידי משתמש אמיתי או על ידי כלי למדידת ביצועים סינתטית. כלים רבים לשיעור ה-Lab רק טוענים את הדף, ולא מקיימים איתו אינטראקציה. כתוצאה מכך, הם מתעדים רק שינויים בפריסה שמתרחשים במהלך הטעינה הראשונית של הדף. לעומת זאת, נתוני ה-CLS שנמדדים על ידי כלי RUM מתעדים שינויים לא צפויים בפריסה שמתרחשים בכל משך החיים של הדף.
- עיכוב בקלט ראשון (FID): לא ניתן למדוד עיכוב בקלט ראשון בסביבות שיעור Lab, כי נדרשת אינטראקציה של המשתמש עם הדף. כתוצאה מכך, Total block Time (זמן החסימה הכולל) הוא שרת ה-proxy המומלץ ל-FID לשיעור ה-Lab. השיטה TBT מודדת את 'משך הזמן הכולל בין הצגת התוכן הראשוני לבין הזמן עד לפעילות מלאה שבמהלכו הדף חסום לתגובה לקלט של משתמשים'. FID ו-TBT מחושבים באופן שונה, אבל שניהם משקפים של thread ראשי חסום במהלך תהליך האתחול. כשה-thread הראשי חסום, הדפדפן מתעכב בתגובה לאינטראקציות של המשתמשים. FID מודד את העיכוב, אם יש, המתרחש בפעם הראשונה שהמשתמש מנסה לבצע אינטראקציה עם דף כלשהו.
כלים
תוכלו להשתמש בכלים הבאים כדי לאסוף מדידות מעבדה של Web Vitals:
- תוסף Web Vitals ל-Chrome: התוסף ל-Chrome Web Vitals מודד את מדדי הליבה לבדיקת חוויית המשתמש באתר (LCP, FID ו-CLS) לגבי דף נתון, ומדווח עליהם. הכלי הזה מיועד לספק למפתחים משוב על הביצועים בזמן אמת כשהם מבצעים שינויים בקוד.
- Lighthouse: Lighthouse דוחות על LCP, CLS ו-TBT, וגם מדגישים שיפורים אפשריים בביצועים. Lighthouse זמין בכלי הפיתוח ל-Chrome, כתוסף ל-Chrome וכחבילת npm. אפשר לשלב את Lighthouse בתהליכי עבודה של אינטגרציה רציפה (CI) באמצעות Lighthouse CI.
- WebPageTest:WebPageTest כולל מדדי Web Vitals כחלק מהדוחות הרגילים. WebPageTest שימושי לאיסוף מידע על מדדי חוויית המשתמש באתר בתנאים מסוימים של מכשיר ורשת.