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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הדוח לגבי חוויית המשתמש ב-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 ובדפדפנים אחרים שבהם יש תמיכה במדדי Web Vitals.

אתרים שלא מקבלים מספיק תנועה לא מיוצגים במערך הנתונים של 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 Lab.

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

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

Search Console

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

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

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

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

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

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

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

Lighthouse

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

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

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

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

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

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

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

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

החלונית 'ביצועים' בכלי הפיתוח ל-Chrome

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

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

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

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

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

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

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

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

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

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

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

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

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

שלב 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. האם אחד מהמדדים הבסיסיים של חוויית המשתמש באתר נכשל, ובאיזו מידה? כך תוכלו להבין איפה כדאי למקד את המאמצים.

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

לגבי CLS, כדאי לבדוק את הציונים של CLS ב-CrUX ושל CLS ב-Lighthouse כדי לראות אם מדובר בבעיה ב-CLS בזמן הטעינה (ש-Lighthouse יזהה ויציע פתרון לגביו) או בבעיה ב-CLS לאחר הטעינה ש-Lighthouse לא יזהה. מידע נוסף זמין במדריך של Optimize בנושא 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 DevTools. הכלי הזה שימושי לאימות תיקונים באופן מקומי, אבל חלונית הביצועים (שתפורט בהמשך) היא כלי מקיף יותר לזיהוי ולפתרון בעיות בביצועים באופן מקומי.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הצגת מגמות בבריאות האתר באמצעות נתוני שדה

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

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

סיכום

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