השלב הראשון בשיפור מדדי ה-Web Vitals הוא איסוף נתונים לגביהם באתר. כדי לקבל ניתוח מקיף, צריך לאסוף נתוני ביצועים גם מסביבות אמיתיות וגם מסביבות מעבדה. כדי למדוד את מדדי הליבה לביצועי אתרים, צריך לבצע שינויים מינימליים בקוד, ואפשר לעשות זאת באמצעות כלים חינמיים.
מדידת מדדי חוויית המשתמש הבסיסיים (Core Web Vitals) באמצעות נתוני RUM
נתונים של ניטור משתמשים אמיתיים (RUM), שנקראים גם נתוני שטח, מתעדים את הביצועים של האתר כפי שהם נחווים על ידי משתמשים אמיתיים. נתוני RUM הם הנתונים ש-Google משתמשת בהם כדי לקבוע אם אתר עומד בסף המומלץ של מדדי הליבה של חוויית המשתמש.
תחילת העבודה
אם לא הגדרתם RUM, תוכלו להשתמש בכלים הבאים כדי לקבל במהירות נתונים על הביצועים של האתר שלכם בפועל. כל הכלים האלה מבוססים על אותו מערך נתונים (הדוח לגבי חוויית המשתמש ב-Chrome), אבל יש להם תרחישי שימוש שונים במקצת:
- כלי הפיתוח ל-Chrome משולבים עם מערך הנתונים של CrUX בתצוגת המדדים בזמן אמת של חלונית הביצועים. השוואה בין חוויית המשתמש המקומית לבין חוויות של משתמשים אמיתיים באותו דף מאפשרת לכם לקבל החלטה מושכלת יותר לגבי המקומות שבהם כדאי להתמקד במאמצי הניפוי. אם אתם מחפשים פעולה אחת שתעזור לכם להתחיל למדוד ולשפר את מדדי חוויית המשתמש הבסיסיים באתר, מומלץ להשתמש בחלונית'ביצועים' בכלי הפיתוח ל-Chrome.
- PageSpeed Insights (PSI) מדווח על הביצועים המצטברים ברמת הדף וברמת המקור ב-28 הימים האחרונים. בנוסף, מוצגות בו הצעות לשיפור הביצועים. PSI זמין באינטרנט וגם כ-API.
- בדוחות של Search Console מוצגים נתוני ביצועים ברמת הדף. לכן הוא מתאים במיוחד לזיהוי דפים ספציפיים שצריך לשפר. בניגוד ל-PageSpeed Insights, הדוחות של Search Console כוללים נתוני ביצועים היסטוריים. אפשר להשתמש ב-Search Console רק באתרים שבבעלותכם ושהבעלות עליהם אומתה.
- CrUX Vis הוא לוח בקרה מוכן מראש שמציג נתוני היסטוריה של CrUX לגבי כתובת URL או מקור שתבחרו (אם הם זמינים במערך הנתונים של CrUX). הוא מבוסס על CrUX History API ותהליך ההגדרה נמשך בערך דקה. בהשוואה ל-PageSpeed Insights ול-Search Console, ב-CrUX Vis יש יותר נתונים, למשל חלקי משנה של LCP, סוגי ניווט וכו'.
- CrUX Vis הוא לוח בקרה היסטורי שמציג נתוני CrUX לגבי מקור או כתובת URL שתבחרו. הוא מבוסס על CrUX History API. בהשוואה ל-PageSpeed Insights ול-Search Console, דוחות CrUX Vis כוללים יותר פרטים – לדוגמה, סוגי ניווט ונתוני LCP ו-RTT זמינים ב-CrUX Vis.
חשוב לציין שאף על פי שהכלים שצוינו קודם מתאימים ל"תחילת העבודה" עם מדידת מדדי הליבה של מהירות האתר, הם יכולים להיות שימושיים גם בהקשרים אחרים. בפרט, גם 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 היא ספרייה קטנה ומודולרית (בגודל של כ-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 חושפים לעיתים קרובות שהביצועים משתנים באופן משמעותי – חלק מהמשתמשים נהנים מחוויה מהירה, ואחרים מחוויה איטית. עם זאת, שימוש בחציון לסיכום הנתונים עלול להסתיר את ההתנהגות הזו.
בנוגע למדדים לבדיקת חוויית המשתמש באתר, Google משתמשת באחוז חוויות המשתמש שמוגדרות כ'טובות', ולא בנתונים סטטיסטיים כמו ערכי חציון או ממוצעים, כדי לקבוע אם אתר או דף עומדים בספי המומלצים. באופן ספציפי, כדי שאתר או דף ייחשבו כעומדים בסף של מדדי הליבה לבדיקת חוויית המשתמש באתר, 75% מהביקורים בדף צריכים לעמוד בסף 'טוב' לכל מדד.
מדידת Web Vitals באמצעות נתוני מעבדה
נתוני מעבדה, שנקראים גם נתונים סינתטיים, נאספים מסביבה מבוקרת ולא ממשתמשים בפועל. בניגוד לנתוני RUM, אפשר לאסוף נתוני מעבדה מסביבות לפני שלב הייצור, ולכן אפשר לשלב אותם בתהליכי עבודה של מפתחים ובתהליכי שילוב רציף. דוגמאות לכלים שאוספים נתונים סינתטיים הם Lighthouse ו-WebPageTest.
לתשומת ליבכם
תמיד יהיו הבדלים בין נתוני RUM לבין נתוני מעבדה – במיוחד אם תנאי הרשת, סוג המכשיר או המיקום של סביבת המעבדה שונים באופן משמעותי מאלה של המשתמשים. עם זאת, כשמדובר באיסוף נתוני מעבדה על מדדי Web Vitals, חשוב לזכור כמה נקודות ספציפיות:
- Largest Contentful Paint (LCP) שנמדד בסביבות מעבדה יכול להיות שונה מזה שנמדד בשטח באמצעות נתוני RUM, בגלל עיכובים בטעינת הדף (דרך הפניות אוטומטיות, זמן אחזור בחיבור לשרת או נתונים שלא נשמרו במטמון), תוכן שונה שמוצג למשתמשים שונים בהתאם למסך או בגלל סיבות אחרות (כולל באנרים של קובצי Cookie, התאמה אישית).
- מדד יציבות חזותית (CLS) שנמדד בסביבות מעבדה יכול להיות נמוך באופן מלאכותי בהשוואה ל-CLS שנצפה בנתוני RUM. הרבה כלים במעבדה רק טוענים את הדף – הם לא מבצעים בו אינטראקציה. כתוצאה מכך, הם מתעדים רק שינויים בפריסה שמתרחשים במהלך הטעינה הראשונית של הדף. לעומת זאת, ה-CLS שנמדד על ידי כלי RUM מתעד שינויי פריסה בלתי צפויים שמתרחשים במהלך משך החיים של הדף.
- אי אפשר למדוד את מהירות התגובה לאינטראקציה באתר (INP) בסביבות מעבדה, כי המדד הזה דורש אינטראקציות של משתמשים עם הדף. לכן, זמן החסימה הכולל (TBT) הוא מדד ה-Proxy המומלץ ל-INP. המדד TBT מודד את "משך הזמן הכולל בין הצגת התוכן הראשוני לבין הזמן עד לפעילות מלאה, שבמהלכו הדף נחסם ולא מגיב לקלט של משתמשים". למרות שהחישוב של INP ו-TBT מתבצע בצורה שונה, שניהם משקפים חסימה של ה-thread הראשי במהלך תהליך האתחול. כשהשרשור הראשי חסום, יש עיכוב בתגובה של הדפדפן לאינטראקציות של המשתמשים.
כלים
אפשר להשתמש בכלים האלה כדי לאסוף מדידות של מדדי הליבה של מהירות האתר במעבדה:
- כלי הפיתוח ל-Chrome מודדים את מדדי ה-Core Web Vitals של דף מסוים ומדווחים עליהם בתצוגת המדדים הפעילים בחלונית הביצועים. בתצוגה הזו, מפתחים מקבלים משוב על הביצועים בזמן אמת כשהם מבצעים שינויים בקוד.
- Lighthouse מדווח על LCP, CLS ו-TBT, ומדגיש גם שיפורים אפשריים בביצועים. הכלי Lighthouse זמין בכלי הפיתוח ל-Chrome, כחבילת npm, ואפשר גם לשלב אותו בתהליכי עבודה של אינטגרציה רציפה באמצעות Lighthouse CI.
- WebPageTest כולל את מדדי הליבה של מהירות האתר כחלק מהדיווח הסטנדרטי שלו. כלי WebPageTest שימושי לאיסוף מידע על מדדי הליבה של מהירות האתר בתנאי מכשיר ורשת מסוימים.