תהליכי עבודה בדוח ה-Web Vitals הבסיסיים עם הכלים של Google

אפשר לשלב בין כלי Google כדי לבצע ביקורת באתר, לשפר אותו ולעקוב אחריו בצורה יעילה.

תאריך פרסום: 28 במאי 2020

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

במדריך הזה נסביר על תהליך עבודה לשיפור מדדי הליבה לבדיקת חוויית המשתמש באתר. נקודת ההתחלה של תהליך העבודה הזה תלויה בשאלה אם אתם אוספים נתונים משדה משלכם. הנקודה שבה התהליך מסתיים תלויה בכלים של Google שיהיו לכם שימושיים לאבחון ולתיקון בעיות שקשורות לחוויית המשתמש.

הדרך הכי טובה למדוד את מדדי הליבה לבדיקת חוויית המשתמש באתר היא בשטח

המדדים הבסיסיים של חוויית המשתמש באתר נועדו במיוחד למדוד את חוויית המשתמשים באתר שלכם – הם מדדים שמתמקדים במשתמשים. כלים מבוססי-מעבדה כמו Lighthouse הם כלים לאבחון בעיות פוטנציאליות בביצועים ושיטות מומלצות. הכלים שמבוססים על מעבדה פועלים בתנאים מסוימים ומוגדרים מראש, ויכול להיות שהם לא ישקפו את המדידות של מדדי חוויית המשתמש הבסיסיים שמשתמשים חווים בפועל.

לדוגמה, Lighthouse הוא כלי מבוסס-מעבדה שמריץ בדיקות עם הגבלת מהירות מדומות בסביבת מחשב או נייד מדומות. סימולציות כאלה של תנאי רשת ומכשירים איטיים יותר עוזרות לאבחן בעיות בביצועים, אבל הן רק חלק קטן מהמגוון הרחב של תנאי הרשת ויכולות המכשיר, ולכן יכול להיות שהן לא משקפות את מה שהמשתמשים באתרים שלכם חווים.

בנוסף, כלים מבוססי-מעבדה כמו Lighthouse בדרך כלל מבצעים "טעינה קרה" של דף אינטרנט כאילו מדובר במבקר חדש לגמרי. זו בדרך כלל הטעינה הכי איטית, אבל במציאות, יכול להיות שלמבקרים באתר יש נכסים מסוימים במטמון אם הם ביקרו באתר בעבר, או כשהם גולשים באתר. גם מבקרים חדשים וכלים עשויים לחוות את האתר בצורה שונה, עם באנרים של קובצי Cookie או תוכן אחר שמוצג להם.

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

‫Google מודדת את המדדים הבסיסיים של חוויית המשתמש באמצעות הדוח על חוויית המשתמש ב-Chrome ‏ (CrUX). זהו מערך נתונים ציבורי שנאסף ממשתמשי Chrome אמיתיים. הוא הבסיס להרבה כלים של Google ושל צד שלישי שמדווחים על מדדי הליבה לבדיקת חוויית המשתמש באתר.

עם זאת, יש מגבלות ל-CrUX. לרוב, הוא יכול להגיד לכם מתי יש בעיה, אבל לרוב אין לו מספיק נתונים כדי להגיד לכם למה.

אם אפשר, כדאי לאסוף נתונים משדות משלכם

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

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

יכול להיות שאתם לא חלק מארגון גדול, או אפילו מארגון שיש לו את האמצעים לרכוש פתרון צד שלישי. במקרים כאלה, הספרייה של Google web-vitals תעזור לכם לאסוף את כל מדדי הליבה של מהירות האתר. עם זאת, אתם תהיו אחראים לאופן הדיווח, האחסון והניתוח של הנתונים האלה.

אם אתם כבר משתמשים ב-Google Analytics, אבל עדיין לא התחלתם לאסוף נתונים מהשטח, יכול להיות שכדאי לכם להשתמש בספרייה של web-vitals כדי לשלוח ל-Google Analytics את נתוני Web Vitals שנאספו מהשטח ולהשתמש בייצוא ל-BigQuery של נתוני GA4 כדי ליצור דוחות על הנתונים.

הסבר על הכלים של Google

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

הדוח לגבי חוויית המשתמש ב-Chrome ‏ (CrUX)

כמו שצוין קודם, CrUX הוא מערך נתונים ציבורי של נתוני שטח שנאספו מפלח של משתמשי Google Chrome אמיתיים ממיליוני אתרים. הוא כולל מדדים של Core Web Vitals ומדדים אחרים לאתרים עם תנועה מספקת.

נתוני CrUX זמינים כמערך נתונים חודשי ב-BigQuery ברמת המקור, או כAPI יומי ברמת כתובת ה-URL או המקור, בתנאי שיש מספיק דגימות של כתובת ה-URL או המקור במערך הנתונים של CrUX. נתוני CrUX זמינים דרך כלים שונים של CrUX, גם לגישה פרוגרמטית וגם לכלים ויזואליים לשימוש המשתמשים.

מתי כדאי להשתמש ב-CrUX

גם אם אתם אוספים נתונים משדה משלכם, CrUX עדיין שימושי. נתוני CrUX מייצגים קבוצת משנה של משתמשי Chrome, אבל כדאי להשוות את נתוני השדות של האתר שלכם לנתוני CrUX כדי לראות עד כמה הם תואמים. לכל אחת מהגישות יש יתרונות וחסרונות, שיכולים להוביל להבדלים. אם אתם לא אוספים אף נתון שטח לגבי האתר שלכם, דוח CrUX יכול לספק לכם סקירה כללית ברמה גבוהה – בתנאי שהאתר שלכם מיוצג במערך הנתונים שלו.

אפשר להשתמש ב-CrUX ישירות או באמצעות כלי אחר (כולל אלה שמוזכרים בהמשך). שימוש ישיר במערך הנתונים של CrUX, באמצעות BigQuery או ה-API, מאפשר לכם לחשוף נתונים שלא מוצגים בכלים אחרים – למשל, נתונים ברמת המדינה לרוב לא זמינים בכלים אחרים. בנוסף, תוכלו לראות את המדדים הנוספים ב-CrUX, שלרוב לא מוצגים בכלים אחרים.

באילו מקרים לא כדאי להשתמש ב-CrUX

נתוני CrUX מייצגים רק משתמשי Chrome, וגם אז, רק קבוצת משנה של משתמשי Chrome. פתרון RUM מלא יכול לכלול חוויות נוספות ב-Chrome ובדפדפנים אחרים שבהם יש תמיכה במדדי הליבה לבדיקת חוויית המשתמש באתר.

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

הנתונים ש-CrUX מספק הם ממוצע נע מ-28 הימים האחרונים, ולכן הוא לא כלי אידיאלי במהלך הפיתוח. ייקח זמן עד שהשיפורים יבואו לידי ביטוי במערך הנתונים של CrUX.

לבסוף, כמאגר נתונים ציבורי, יש מגבלות על כמות המידע ש-CrUX יכול לספק ועל האופן שבו אפשר לשלוף ממנו נתונים. איסוף נתוני RUM משלכם מאפשר לכם לקבל פרטים נוספים (לדוגמה, רכיב ה-LCP) ולפלח את הנתונים בצורה טובה יותר כדי לזהות בעיות. האם המדדים הבסיסיים של חוויית המשתמש באתר טובים יותר או גרועים יותר למשתמשים שמחוברים לחשבון בהשוואה למשתמשים שלא מחוברים לחשבון? האם למשתמשים עם LCP איטי יש רכיב LCP מסוים? אילו אינטראקציות גורמות לערכי FID ו-INP גבוהים?

PageSpeed Insights (PSI)

‫PSI הוא כלי שמדווח על נתוני שטח מ-CrUX וגם על נתוני בדיקה מ-Lighthouse לדף נתון. לפרטים נוספים, אפשר לעיין בסעיפים הרלוונטיים.

מתי כדאי להשתמש ב-PSI

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

בנוסף, PSI מספק נתונים מ-Lighthouse, שכוללים המלצות שימושיות לשיפור מדדי הליבה לבדיקת חוויית המשתמש באתר – אם המדדים תואמים. אם יש הבדלים בין ההגדרות, יכול להיות שההמלצות של Lighthouse יהיו פחות רלוונטיות.

מכיוון שהכלי Lighthouse מופעל מהשרת, הוא יכול ליצור בסיס השוואה עקבי יותר מאשר הפעלה של Lighthouse מ-DevTools.

באילו מקרים לא כדאי להשתמש ב-PSI

הכלי PSI זמין רק לכתובות URL ציבוריות. אי אפשר להשתמש בו באתרים בפיתוח שלא נגישים לציבור.

הנתונים של CrUX זמינים רק אם האתרים עומדים בקריטריונים מסוימים, כולל סף פופולריות של האתר. הכלי PSI פחות שימושי כשנתוני CrUX לא זמינים לגבי דף או מקור, כי במקרים כאלה הוא יכול להציג רק את נתוני המעבדה של Lighthouse.

באופן דומה, אם יש לכם רק נתוני CrUX ברמת המקור ולא ברמת כתובת ה-URL הספציפית שנבדקת, גם זה מגביל את היכולת להשתמש בנתוני השטח ברמת המקור כדי להסיק מסקנות לגבי האבחון במעבדה ברמת הדף. עדיין כדאי להשתמש בנתוני השדות ברמת המקור כסיכום של ביצועי האתר, וביקורות של Lighthouse יכולות לעזור, אבל במקרה הזה צריך לנקוט משנה זהירות.

לבסוף, אם נתונים ברמת הדף זמינים ב-CrUX, אבל שונים מנתוני המעבדה של Lighthouse, יכול להיות שההמלצות של Lighthouse לא יהיו שימושיות. זה יכול לקרות במיוחד בבעיות CLS אחרי טעינת הדף ובמדדי חוויית המשתמש הבסיסיים שקשורים לאינטראקטיביות (FID ו-INP), שבהם ביקורות שמבוססות על נתוני מעבדה פחות שימושיות.

Search Console

‫Search Console מאפשר למדוד את התנועה והביצועים של האתר ברשת החיפוש, כולל נתוני Core Web Vitals. היא זמינה רק לבעלי אתרים שאישרו את הבעלות שלהם על האתר.

תכונה חשובה של Search Console היא קיבוץ של דפים דומים (לדוגמה, דפים שמשתמשים באותו תבנית) להערכה אחת. ב-Search Console יש גם דוח בנושא מדדי ליבה לבדיקת חוויית המשתמש באתר שמבוסס על נתונים מהשטח מ-CrUX.

מתי כדאי להשתמש ב-Search Console

‫Search Console מתאים גם למפתחים וגם לבעלי תפקידים שאינם מפתחים, כדי להעריך את הביצועים בחיפוש ואת הביצועים של דפים בדרכים שכלים אחרים של Google לא מאפשרים. הצגת נתוני CrUX וקיבוץ הדפים לפי דמיון מאפשרים לקבל תובנות חדשות לגבי ההשפעה של שיפורי ביצועים על קטגוריות שלמות של דפים.

באילו מקרים לא כדאי להשתמש ב-Search Console

יכול להיות ש-Search Console לא מתאים לפרויקטים שמשתמשים בכלים שונים של צד שלישי שמקבצים דפים לפי דמיון, או אם אתר לא מיוצג במערך הנתונים של CrUX.

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

Lighthouse

‫Lighthouse הוא כלי מעבדה שמספק הזדמנויות ספציפיות לשיפור הביצועים של הדפים. תזרימי משתמשים ב-Lighthouse מאפשרים למפתחים גם לכתוב סקריפטים של תזרימי אינטראקציה לבדיקת ביצועים מעבר לטעינת הדף.

Lighthouse-CI הוא כלי קשור שמריץ את Lighthouse במהלך בנייה ופריסה של פרויקטים, כדי לעזור בבדיקות רגרסיה של ביצועים. הוא מציג דוח Lighthouse יחד עם בקשות משיכה, ועוקב אחרי מדדי הביצועים לאורך זמן.

מתי כדאי להשתמש ב-Lighthouse

‫Lighthouse הוא כלי מצוין לזיהוי הזדמנויות לשיפור הביצועים במהלך הפיתוח בסביבות מקומיות ובסביבות הכנה. ‫Lighthouse CI שימושי באופן דומה בשלבי הבנייה והפריסה של סביבות פיתוח וייצור, שבהן נדרשת בדיקת רגרסיה של הביצועים כדי לשמור על חוויית משתמש טובה.

באילו מקרים לא כדאי להשתמש ב-Lighthouse

‫Lighthouse (או Lighthouse CI) לא מחליף נתונים מהשטח. Lighthouse הוא בעיקר כלי אבחון שמציג בעיות פוטנציאליות ושיטות מומלצות מתוך טעינת דף מוגדרת מראש. יכול להיות שההמלצות שיוצגו לכם לא תמיד יתאימו לביצועים שהמשתמשים שלכם חווים.

אפשר להשתמש ב-Lighthouse כדי לאבחן אתרים בסביבת הייצור באמצעות כלים כמו PageSpeed Insights, אבל מומלץ להשתמש ב-Lighthouse בסביבות פיתוח ושילוב רציף כדי לטפל בבעיות ביצועים לפני שהן מגיעות לסביבת הייצור.

הבדיקות ש-Lighthouse מספק זמינות גם דרך 'תובנות' בחלונית הביצועים בכלי הפיתוח ל-Chrome, שבה אפשר לראות ניתוח מעמיק יותר של ביצועי הדף.

החלונית Performance בכלי הפיתוח ל-Chrome

כלי הפיתוח ל-Chrome הם אוסף של כלי פיתוח מובנים בדפדפן, כולל חלונית הביצועים. החלונית 'ביצועים' היא כלי מעבדה שכולל שני 'מצבים':

כשפותחים את חלונית הביצועים בפעם הראשונה, מוצג מסך עם מדדי Core Web Vitals הנוכחיים, עם אפשרות לייבא נתוני שטח מ-CrUX. הכלי הזה שימושי כי הוא מאפשר לראות את הביצועים בזמן אמת כשמבצעים אינטראקציה עם הדף כדי לנסות לגלות בעיות בביצועים – במיוחד בעיות שקשורות לטעינה שאולי רואים במדדים CLS ו-INP.

בנוסף, חלונית הביצועים מאפשרת למפתחים לתעד פרופיל (או מעקב) של כל פעילות הדף במהלך טעינת הדף או במהלך תקופה מתועדת. בתצוגה הזו אפשר לקבל תובנות מעמיקות לגבי כל מה שהכלי מזהה במאפיינים כמו רשת, רינדור, ציור ופעילות סקריפטים, וגם לגבי מדדי ה-Core Web Vitals של הדף. הוא כולל גם תובנות, בדומה לאלה שמופיעות ב-Lighthouse.

מתי כדאי להשתמש בחלונית הביצועים

מפתחים צריכים להשתמש בחלונית 'ביצועים' כדי לקבל תובנות מעמיקות לגבי הביצועים של דף מסוים.

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

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

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

חלונית הביצועים היא כלי למפתחים שמספק בעיקר נתוני בדיקה – אבל גם הקשר מסוים מהשטח מ-CrUX. הוא לא תחליף לנתוני שדות.

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

תהליך עבודה בן שלושה שלבים כדי לוודא שמדדי הליבה לבדיקת חוויית המשתמש באתר שלכם תקינים

כשפועלים לשיפור חוויית המשתמש, מומלץ לחשוב על התהליך כעל מחזור מתמשך. כדי לשפר את מדדי הליבה לבדיקת חוויית המשתמש באתר ומדדים אחרים לבדיקת ביצועים, אפשר לנסות את הגישה הבאה:

1. הערכת תקינות האתר וזיהוי נקודות בעייתיות.
2. מבצעים ניפוי באגים ואופטימיזציה.
3. כדאי להשתמש בכלים של אינטגרציה רציפה כדי לזהות רגרסיות ולמנוע אותן.

שלב 1: בדיקת התקינות של האתר וזיהוי הזדמנויות לשיפור

הדרך הכי טובה להעריך את תקינות האתר היא להתחיל עם נתוני שטח.

1. אפשר להשתמש ב-PageSpeed Insights כדי לראות את מדדי חוויית המשתמש הבסיסיים (Core Web Vitals) הכוללים במקור, ומידע ספציפי על כתובת URL מסוימת.
2. Search Console יכול להיות שימושי לזיהוי דפים שצריך לשפר, במקרים שבהם תכונת קיבוץ הדפים פועלת היטב באתר שלכם.
3. אם יש לכם נתוני RUM, לרוב זו האפשרות הטובה ביותר לזיהוי בעיות בדפים מסוימים או בפלחים מסוימים של תנועה.

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

ניתוח ביצועי האתר באמצעות PageSpeed Insights

בכלי PageSpeed Insights מוצגים נתוני CrUX מ-28 הימים האחרונים של נתוני חוויית המשתמש באחוזון ה-75. המשמעות היא שאם 75% מחוויית המשתמש עומדת בסף שהוגדר למדד מסוים, חוויית המשתמש נחשבת לטובה.

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

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

ב-PSI מוצגים גם כל שלושת המדדים הבסיסיים של חוויית המשתמש באתר (LCP,‏ CLS ו-INP) וגם מדדי האבחון TTFB ו-FCP. האם יש מדדים של Core Web Vitals שבהם האתר לא עומד בדרישות, ובכמה? כך תוכלו לדעת איפה כדאי להשקיע את המאמצים שלכם.

חשוב להבין את הקשרים בין המספרים האלה, במיוחד לגבי LCP. אם מהירות LCP איטית, כמו בדוגמה הזו, כדאי לבדוק את מהירות TTFB ואת מהירות FCP, שהן אבני דרך במדד הזה. בדוגמה הזו, ה-TTFB הוא 1.8 שניות, ולכן יהיה קשה מאוד לעמוד בסף המומלץ של 2.5 שניות ל-LCP טוב. המשמעות היא שהקצה העורפי איטי (בעיות בשרת או חוסר ב-CDN), שהרשתות איטיות יותר או שההפניות לכתובות URL אחרות מעכבות את הבייטים הראשונים של ה-HTML. מידע נוסף זמין במדריך לאופטימיזציה של TTFB. ה-FCP אורך עוד שנייה בנוסף לכך, וגם זה יכול להעיד על רשתות איטיות יותר. בדוגמה הזו, ה-LCP לא ארוך אחרי ה-FCP, מה שמצביע על כך שמשאב ה-LCP עבר אופטימיזציה טובה אחרי שהדף עצמו נטען. בנוסף, עכשיו אפשר לראות ב-CrUX יותר מידע אבחוני בסוגי משאבים ובחלקים משניים, מה שעוזר לכם לאבחן בעיות שקשורות ל-LCP.

במקרה של CLS, כדאי לבדוק את ה-CLS ב-CrUX ואת ציוני ה-CLS ב-Lighthouse כדי לראות אם מדובר בבעיה של CLS בטעינה (ש-Lighthouse יזהה ויציע פתרון לגביה), או בבעיה של CLS אחרי הטעינה ש-Lighthouse לא יזהה. מידע נוסף זמין במדריך לאופטימיזציה של CLS.

כדי לבדוק את הרספונסיביות, בודקים את ציוני ה-INP. כדאי לעיין בביקורות של TBT ב-Lighthouse כדי לראות אם מתבצע עיבוד רב של JavaScript במהלך הטעינה הראשונית של הדף, מה שסביר שישפיע על INP. מדד INP יכול להיות מסובך לשיפור, ולכן מומלץ לעיין במדריך לאופטימיזציה של INP לקבלת מידע נוסף.

זיהוי דפים עם ביצועים נמוכים ב-Search Console

בעוד ש-PSI שימושי כשרוצים לבדוק כתובת URL ספציפית או את האתר כולו, Search Console יכול לעזור לכם להתמקד בסוגים מסוימים של דפים. האפשרות הזו שימושית במיוחד אם יש הרבה דפים שמשתמשים בטכנולוגיות או בנושאים משותפים, ומערכת Search Console מצליחה לזהות אותם.

בדוח Core Web Vitals ב-Search Console מוצגת תמונה רחבה של ביצועי האתר, אבל אפשר גם להתעמק בדפים ספציפיים שדורשים תשומת לב. ב-Search Console אפשר גם:

• לזהות קבוצות של דפים ספציפיים שצריך לשפר, וקבוצות שמספקות חוויית משתמש טובה.
• קבלת נתונים מפורטים על הביצועים לפי כתובת URL, מקובצים לפי סטטוס, מדד וקבוצות של דפי אינטרנט דומים (כמו דפי פרטי מוצר באתר מסחר אלקטרוני).
• קבלת דוחות מפורטים שבהם כתובות ה-URL מחולקות לקטגוריות של איכות חוויית המשתמש, גם בנייד וגם במחשב.

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

שלב 2: ניפוי באגים ואופטימיזציה

בשלב 1, הייתם אמורים לזהות דפים שנדרשים בהם שיפורים בביצועים, וגם את המדדים של Core Web Vitals שאתם רוצים לשפר. כדי להבין את שורש הבעיה ולזהות אותה, אפשר להשתמש בכלים של Google כדי לקבל מידע נוסף.

1. כדאי לעיין בביקורות של Lighthouse כדי לקבל הנחיות כלליות לגבי הדף
2. כדי לנתח את מדדי ה-Core Web Vitals בזמן אמת, אפשר להשתמש בתצוגת המדדים בזמן אמת של חלונית הביצועים.
3. אפשר להשתמש במעקב בחלונית הביצועים כדי לנפות באגים בבעיות שקשורות לביצועים ולבדוק שינויים בקוד.

לקבלת הנחיות מפורטות יותר, אפשר לעיין במדריכים הבאים:

• אופטימיזציה של LCP
• אופטימיזציה של INP
• אופטימיזציה של CLS

זיהוי הזדמנויות באמצעות Lighthouse

‫PageSpeed Insights מריץ את Lighthouse בשבילכם. אפשר גם להריץ את Lighthouse מתוך כלי הפיתוח ל-Chrome, וזה שימושי כדי לאמת תיקונים באופן מקומי. עם זאת, חלונית הביצועים (שמוסברת בהמשך) היא כלי מקיף יותר לזיהוי ולתיקון בעיות ביצועים באופן מקומי.

נקודה חשובה היא לוודא שהביקורת של Lighthouse משחזרת את הבעיות שאתם מנסים לפתור (לדוגמה, LCP איטי או בעיות CLS). כברירת מחדל, Lighthouse מעריך רק את חוויית המשתמש במהלך טעינת הדף. מכיוון שמדובר בכלי Labs, הוא גם לא כולל את מדד ה-INP, אלא את מדד ה-TBT.

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

אפשר לסנן את הביקורות כדי להציג רק את המדדים הבסיסיים של חוויית המשתמש שמעניינים אתכם, וכך להתמקד בתיקון בעיות שקשורות למדד ספציפי:

במקרה של INP, כדאי להשתמש בביקורות TBT כדי לזהות בעיות שיכולות להשפיע על המדדים האלה, אבל חשוב לזכור שבלי אינטראקציות, היכולת של Lighthouse לאבחן בעיות מוגבלת.

ניתוח בזמן אמת באמצעות מסך המדדים בזמן אמת בכלי הפיתוח ל-Chrome

במסך המדדים בזמן אמת של כלי הפיתוח ל-Chrome בחלונית Performance מוצגים מדדי הליבה לבדיקת חוויית המשתמש באתר בזמן אמת במהלך טעינת הדף וגם במהלך הגלישה בדף. לכן, הוא יכול לתעד את מדד INP וגם שינויים בפריסה שמתרחשים אחרי הטעינה. אפשר גם לראות מידע מפורט יותר על כל מדד:

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

פירוט נתונים באמצעות חלונית הביצועים

בחלונית הביצועים בכלי הפיתוח ל-Chrome אפשר להקליט פרופיל (או מעקב) של כל התנהגות הדף במהלך תקופה מוקלטת.

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

בטראק Layout Shifts (שינויים בפריסה) מודגשים שינויים בפריסה, ולחיצה על השינויים האלה מספקת פרטים נוספים על הרכיבים שהשתנו לצורך ניפוי באגים של CLS.

תזמונים מרכזיים, כמו LCP, מוצגים בקטע Timings שזמין בתחתית של נתוני המעקב. לחיצה על הקישורים האלה תציג פרטים נוספים.

משימות ארוכות (שיכולות לגרום לבעיות ב-INP) מודגשות גם הן במשולשים אדומים בתרשים הלהבות.

התכונות האלה, וגם המידע בחלקים אחרים של חלונית הביצועים, יכולות לעזור לכם לקבוע אם לתיקונים יש השפעה על מדדי ה-Core Web Vitals של הדף.

ניפוי באגים של מדדי הליבה לבדיקת חוויית המשתמש באתר בשטח

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

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

שלב 3: מעקב אחר שינויים

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

מעקב אחר בקשות לביצועים בסביבות של אינטגרציה רציפה (CI)

Lighthouse-CI מאפשר להריץ באופן אוטומטי בדיקות של Lighthouse על קומיטים של קוד, כדי למנוע כניסה של רגרסיות בביצועים לקוד. הכלי יכול לבדוק את תזמוני הביצועים (שעשויים להשתנות) או רק את ביקורות הביצועים, ככלי לבדיקת קוד (linting) כדי למנוע שיטות עבודה לא מומלצות בקוד.

צפייה במגמות של תקינות האתר באמצעות נתונים מהשטח

מומלץ לנסות לזהות ולתקן את כל בעיות הביצועים לפני שהן מגיעות לסביבת הייצור, אבל חשוב גם לעקוב אחרי נתוני השדה באמצעות RUM כדי למצוא בעיות שלא זוהו. יש הרבה מוצרים מסחריים של RUM שיכולים לעזור בכך. ספריית ה-JavaScript‏ web-vitals יכולה להפוך לאוטומטי את איסוף הנתונים מהשדות באתר, ואפשר גם להשתמש בנתונים האלה כדי להפעיל לוחות בקרה מותאמים אישית ומערכות התראות.

באתרים שאין בהם פתרון RUM, אפשר להשתמש בכלים השונים של CrUX כדי לבצע ניתוח בסיסי של מגמות בנתוני השדה.

סיכום

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