שילוב של הכלים של Google כדי לבצע ביקורת על האתר, לשפר אותו ולעקוב אחריו בצורה יעילה.
תאריך פרסום: 28 במאי 2020
מדדי הליבה לבדיקת חוויית המשתמש באתר הם קבוצת מדדים להערכת חוויית המשתמש לפי קריטריונים כמו ביצועי הטעינה, מידת הרספונסיביות לקלט של המשתמשים ויציבות הפריסה.
במדריך הזה נסביר על תהליך עבודה לשיפור מדדי הליבה לבדיקת חוויית המשתמש באתר, אבל המקום שבו תהליך העבודה מתחיל תלוי בכך שאתם אוספים נתוני שדה משלכם. המקום שבו תסיימו את התהליך עשוי להשתנות בהתאם לכלי של Google שתמצאו שימושי לאבחון ולפתרון בעיות בחוויית המשתמש.
מדדי הליבה לבדיקת חוויית המשתמש באתר מודדים בצורה הטובה ביותר בשטח
המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) נועדו למדוד את חוויית המשתמשים באתר – הם מדדים שמתמקדים במשתמשים. כלים מבוססי-מעבדה כמו Lighthouse הם כלים לאבחון שמאפשרים להדגיש בעיות פוטנציאליות בביצועים ושיטות מומלצות. הכלים במעבדה פועלים בתנאים מסוימים שהוגדרו מראש, ויכול להיות שהם לא משקפים את המדידות של מדדי Core Web Vitals בעולם האמיתי שהמשתמשים שלכם חווים.
לדוגמה, Lighthouse הוא כלי מבוסס מעבדה שמריץ בדיקות עם סימולציה של ויסות נתונים (throttle) בסביבה מדומה של מחשב או נייד. סימולציות כאלה של תנאי רשת ומכשיר איטיים יותר מועילות כשמנסים לאבחן בעיות בביצועים, אבל הן רק טעימה אחת מהמגוון הרחב של תנאי הרשת ויכולות המכשיר, ולכן ייתכן שהן לא משקפות את מה שהמשתמשים באתרים שלכם חווים.
כלים מבוססי-מעבדה כמו Lighthouse, גם מבצעים בדרך כלל "טעינה קרה" של דף אינטרנט כמבקר חדש לגמרי. בדרך כלל זוהי הטעינה האיטית ביותר, אבל במציאות, יכול להיות שחלק מהנכסים יאוחסנו במטמון של המבקרים אם הם ביקרו באתר בעבר, או כשהם גולשים באתר. גם מבקרים וכלים חדשים עשויים להתנסות באתר באופן שונה עם באנרים של קובצי cookie או תוכן אחר שמוצג להם.
בקיצור, כלים מבוססי-מעבדה יכולים לספק אינדיקציה לבעיות פוטנציאליות בביצועים ולעזור לכם לנפות באגים ולבצע שיפורים חוזרים, אבל יכול להיות שהם לא מייצגים את מספר המבקרים שבאמת נתקלים בבעיות באתר. אפשר להשתמש בנתוני שטח למדידת ביצועים בעולם האמיתי, ובכלים מבוססי-מעבדה כמו Lighthouse כדי לאבחן איך אפשר לשפר אותם. אפשר לעיין גם בקטע מתי משתמשים ב-Lighthouse.
Google מודדת את מדדי Core Web Vitals באמצעות דוח חוויית המשתמש ב-Chrome (CrUX). זהו מערך נתונים ציבורי שנאסף ממשתמשי Chrome אמיתיים. זהו עמוד התווך של כלים רבים של Google ושל צדדים שלישיים שמדווחים על מדדי הליבה לבדיקת חוויית המשתמש באתר.
עם זאת, ל-CrUX יש מגבלות משלו. בדרך כלל אפשר לדעת מתי יש בעיה, אבל לרוב אין מספיק נתונים כדי לדעת למה.
אם אפשר, כדאי לאסוף נתונים משלכם מהשטח
קבוצת הנתונים הטובה ביותר לשיפור ביצועי האתר בשטח היא זו שאתם יוצרים. התהליך הזה מתחיל באיסוף נתוני שדות מהמבקרים באתר. האופן שבו תעשו זאת תלוי בגודל הארגון שלכם, ובשאלה אם אתם רוצים לשלם על פתרון של צד שלישי או ליצור פתרון משלכם.
כמעט בטוח שפתרונות בתשלום מודדים את המדדים הבסיסיים של חוויית המשתמש (ומדדי ביצועים אחרים), ובדרך כלל מספקים מגוון כלים לניתוח הנתונים שמתקבלים. בארגונים גדולים עם משאבים משמעותיים, זו עשויה להיות השיטה המועדפת.
עם זאת, ייתכן שאתם לא חלק מארגון גדול – או אפילו אם יש לכם אמצעים שמאפשרים לו ליהנות מפתרון של צד שלישי. במקרים כאלה, ספריית web-vitals של Google תעזור לכם לאסוף את כל ה-Web Vitals. עם זאת, אתם אחראים לאופן הדיווח, האחסון וניתוח של הנתונים האלה.
אם אתם כבר משתמשים ב-Google Analytics אבל עדיין לא התחלתם לאסוף נתוני שדות משלכם, יכול להיות שתוצג לכם הזדמנות להשתמש בספרייה web-vitals כדי לשלוח אל Google Analytics מדדי אתר שנאספו בשטח ולהשתמש בייצוא של GA4 ל-BigQuery כדי לדווח על הנתונים.
הסבר על הכלים של Google
לא משנה אם אתם אוספים נתוני שטח משלכם, יש כמה כלים של Google שיכולים להיות שימושיים בניתוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals). לפני שמגדירים תהליך עבודה, כדאי לקרוא סקירה כללית על כל כלי כדי להבין אילו כלים עשויים להתאים לכם ואילו לא.
הדוח לגבי חוויית המשתמש ב-Chrome (CrUX)
כפי שצוין קודם, CrUX הוא מערך נתונים ציבורי של נתוני שדה שנאספים מפלח של משתמשים אמיתיים ב-Google Chrome ממיליוני אתרים. הדוח כולל מדדים של Core Web Vitals ומדדים אחרים לאתרים עם מספיק תנועה.
CrUX זמין כמערך נתונים חודשי ב-BigQuery ברמת המקור, או כAPI יומי ברמת כתובת ה-URL או ברמת המקור, בתנאי שבכתובת URL או במקור יש מספיק דוגמאות במערך הנתונים של CrUX. אפשר לראות את נתוני BigQuery גם במרכז הבקרה של 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, אבל שונים מנתוני ה-Lab של Lighthouse, ייתכן שהערך של ההמלצות מ-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 בסביבות פיתוח ואינטגרציה רציפה כדי לטפל בבעיות בביצועים לפני שהן מגיעות לסביבת הייצור.
החלונית 'ביצועים' בכלי הפיתוח ל-Chrome
כלי הפיתוח של Chrome הם אוסף של כלים לפיתוח בדפדפן, כולל החלונית 'ביצועים'. החלונית 'ביצועים' היא כלי מעבדה שמכיל שני 'מצבים':
בפעם הראשונה שפותחים את החלונית 'ביצועים', מוצגת במסך 'מדדים בזמן אמת' המדד הנוכחי של Core Web Vitals, עם אפשרות לייבא נתוני שטח מ-CrUX. התכונה הזו מאפשרת לכם לראות תצוגה 'בזמן אמת' של הביצועים בזמן שאתם מבצעים פעולות בדף, כדי לנסות לזהות בעיות בביצועים – במיוחד בעיות לאחר הטעינה שעשויות להופיע במדדים CLS ו-INP.
שנית, הלוח 'ביצועים' מאפשר למפתחים לתעד פרופיל (או נתיב) של כל הפעילות בדף במהלך טעינת הדף או בתקופה מסוימת שתועדה. התצוגה הזו מספקת תובנות מעמיקות לגבי כל מה שהיא מזהה במאפיינים שונים, כמו רשת, רינדור, ציור, פעילות כתיבת סקריפטים, ומדדי הליבה לבדיקת חוויית המשתמש באתר.
מתי כדאי להשתמש בחלונית 'ביצועים'
מפתחים יכולים להשתמש בחלונית 'ביצועים' כדי לקבל תובנות מעמיקות לגבי ביצועי דף מסוים.
התצוגה של המדדים בזמן אמת מאפשרת לכם להבין במהירות את מאפייני הביצועים הנוכחיים של הדף, וגם לזהות בעיות פוטנציאליות במהלך האינטראקציה של המשתמשים עם הדף.
תצוגת המעקב שימושית במיוחד לניפוי באגים בבעיות שקשורות לתגובה מהירה שמשפיעות על INP. ברגע שאנחנו מזהים אינטראקציה עם תגובה גרועה וחוזרת עליה, חלונית הביצועים יכולה לספק שפע של נתונים לגבי מה שקורה בדפדפן כדי לעזור בהבנת הבעיה – מחסימת שרשורים ראשיים ועד לערימות קריאות של JavaScript ועד לעבודות רינדור.
מתי לא כדאי להשתמש בחלונית 'ביצועים'
החלונית 'ביצועים' היא כלי למפתחים שמספק בעיקר נתוני מעבדה, אבל עם הקשר מסוים מ-CrUX. הוא לא תחליף לנתוני השדות.
תצוגת המעקב מכילה הרבה מידע על תוצאות ניפוי באגים, אבל לכן יכול להיות קשה להבין אותה למפתחים מתחילים או למשתמשים בתפקידים שלא קשורים למפתחים. עם זאת, תצוגת המדדים החיים שבה הלוח נפתח מספקת ממשק קל יותר לשימוש למי שלא זקוק לפרטים המלאים.
תהליך עבודה בן שלושה שלבים שיעזור לכם לוודא שמדדי הליבה לבדיקת חוויית המשתמש באתר שלכם יהיו תקינים
כשעובדים על שיפור חוויית המשתמש, מומלץ לחשוב על התהליך כמחזור מתמשך. כדי לשפר את מדדי הליבה לבדיקת חוויית המשתמש באתר ומדדי ביצועים אחרים, אפשר לנקוט בגישה הבאה:
- הערכת בריאות האתר וזיהוי נקודות חולשה.
- ניפוי באגים ואופטימיזציה.
- מעקב באמצעות כלים לאינטגרציה רציפה (CI) כדי לזהות נסיגות ולמנוע אותן.
שלב 1: הערכת התקינות של האתר וזיהוי הזדמנויות לשיפור
מומלץ להתחיל עם נתוני השטח כדי להעריך את תקינות האתר.
- להשתמש ב-PageSpeed Insights כדי לראות את המדדים הכלליים של חוויית המשתמש ב-Core Web Vitals לגבי המקור, ומידע ספציפי על כתובת URL יחידה.
- Search Console יכול לעזור לכם לזהות דפים שצריך לשפר, אם התכונה של קיבוץ הדפים מתאימה לאתר שלכם.
- אם יש לכם נתוני RUM, לרוב זו האפשרות הטובה ביותר לזהות דפים ספציפיים או פלחי תנועה עם בעיות.
בין שאתם מנתחים נתוני שדה שאתם אוספים בעצמכם ובין שאתם מנתחים נתוני CrUX, השלב הראשון הזה חיוני. אם אתם לא אוספים נתוני שטח, יכול להיות שנתוני CrUX מספיקים כדי להנחות אתכם – שוב, בתנאי שהאתר שלכם מיוצג במערך הנתונים.
ניתוח ביצועי האתר באמצעות PageSpeed Insights
כלי PageSpeed Insights מציג את נתוני CrUX של 28 הימים האחרונים של נתוני חוויית המשתמש ב-75% העליונים. כלומר, אם 75% מחוויות המשתמש עומדות בדרישות הסף שהוגדרו למדד מסוים, חוויית המשתמש נחשבת ל'טובה'.
אם יש לכם דף ספציפי שתרצו לבדוק את הביצועים שלו, תוכלו להשתמש בו. כדי לקבל תצוגה כוללת של אתר כשמתחילים לבצע אופטימיזציה, מומלץ להתחיל בדף הבית, מכיוון שלרוב הוא אחד מהדפים הפופולריים ביותר באתרים רבים.
בשלב הראשון, כדאי להתמקד בקטע מהי חוויית המשתמשים בפועל ב-PSI. יוצגו עד ארבע תצוגות של הנתונים: נייד ומחשב לכתובת ה-URL שהוזנה ולמקור כולו. כדאי להשוות בין האפשרויות האלה ולבדוק מה ההבדל ביניהן. בדרך כלל, הביצועים בנייד פחות טובים משל מחשב, כי הוא מכשיר מוגבל יותר במשאבים שפועל בתנאי רשת שעשויים להיות פחות יציבים. אם יש הבדל מהותי בין נתוני כתובת ה-URL לבין נתוני המקור, כדאי לנסות להבין את הסיבה לכך: דפי הבית הם לרוב הדפים הראשונים שבהם מבקרים (כלומר דף נחיתה), ולכן הם עשויים להיות איטיים יותר מאשר משתמשי המקור מתייחסים באופן מלא למטמון של הדפדפן שלא הוגדר מראש. סביר להניח שהדפים הבאים יטענו מהר יותר, כי כל הנכסים המשותפים יישמרו במטמון, וכך יתמעטו הנתונים המצטברים ברמת המקור.
ב-PSI מוצגים גם כל שלושת המדדים של Core Web Vitals (LCP, CLS ו-INP) וגם המדדים של זמן אחזור ה-TTFB ו-FCP לצורכי אבחון. האם אחד מהמדדים הבסיסיים של חוויית המשתמש באתר נכשל, ובאיזו מידה? כך תוכלו להבין איפה כדאי למקד את המאמצים.
להבין את הקשרים בין המספרים האלה — במיוחד לגבי LCP. אם מדד ה-LCP איטי, כמו בדוגמה הזו, צריך לבחון את המדדים 'דברים שאפשר לעשות' (TTD) ו-FCP, שהם גם אבני הדרך של המדד הזה. בדוגמה הזו, זמן ה-TTFB הוא 1.8 שניות, ולכן יהיה קשה מאוד לעמוד בערך הסף המומלץ של 2.5 שניות ל-LCP טוב. המשמעות היא שקצה עורפי איטי (בעיות בשרת או חוסר CDN), רשתות איטיות יותר או הפניות אוטומטיות שמתעכבות ביטים HTML ראשונים. מידע נוסף זמין במדריך לאופטימיזציה של זמן אחזור הבקשה הראשון (TTFB). זמן ה-FCP נמשך עוד שנייה, וגם הוא עשוי להצביע על רשתות איטיות יותר. בדוגמה הזו, ה-LCP מתרחש זמן קצר אחרי ה-FCP, מה שמצביע על כך שהמשאב של ה-LCP עבר אופטימיזציה טובה לאחר טעינת הדף עצמו.
בנוגע ל-CLS, ניתן לעיין בציונים ב-CrUX CLS וב-Lighthouse CLS כדי לראות אם זו בעיית 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 כדי לקבל מידע נוסף שיעזור לכם להבין את שורש הבעיה ולזהות אותה.
- יש להריץ ביקורת Lighthouse כדי לקבל הנחיות ברמת הדף
- אתם יכולים להשתמש בתצוגת המדדים החיים בלוח הביצועים כדי לנתח את מדדי Core Web Vitals בזמן אמת.
- אפשר להשתמש במעקב בחלונית הביצועים כדי לנפות באגים בביצועים ולבדוק שינויים בקוד.
הנחיות מפורטות יותר זמינות במדריכים הבאים:
זיהוי הזדמנויות באמצעות Lighthouse
הכלי PageSpeed Insights מפעיל את Lighthouse בשבילכם, אבל לצורך פיתוח מקומי אפשר גם להריץ את Lighthouse מכלי הפיתוח ל-Chrome, כדי לאמת תיקונים באופן מקומי.
חשוב לוודא שהבדיקה של Lighthouse משחזרת את הבעיות שאתם מנסים לפתור (לדוגמה, בעיות LCP או CLS איטיות). כברירת מחדל, Lighthouse מעריך את חוויית המשתמש רק במהלך טעינת הדף. מכיוון שזהו כלי מעבדה, הוא גם מחריג את INP לטובת TBT.
אם מדדי Lighthouse מצביעים על בעיה דומה לבעיה שאתם מנסים לפתור, המידע הרב שבבדיקות יכול לעזור לכם לזהות בעיות ולהציע פתרונות.
אתם יכולים לסנן את הביקורות כך שיוצגו רק מדדי Core Web Vitals שמעניינים אתכם, כדי להתמקד בתיקונים לבעיות שקשורות למדד ספציפי:
לצורך INP, ניתן להשתמש בביקורות של TBT כדי לזהות בעיות שעשויות להשפיע על המדדים האלה. עם זאת, חשוב לדעת שבלי אינטראקציות, Lighthouse הוא יכול לאבחן בעיות באופן מוגבל.
ניתוח בזמן אמת באמצעות המסך של המדדים החיים בכלי הפיתוח ל-Chrome
במסך המדדים בזמן אמת של כלי הפיתוח ל-Chrome בחלונית הביצועים מוצגים מדדי הליבה לבדיקת חוויית המשתמש באתר בזמן אמת במהלך טעינת הדף וגם בזמן הגלישה בדף. לכן, הוא יכול לתעד שינויי INP ושינויים בפריסה שמתרחשים לאחר הטעינה. אפשר גם לראות מידע מפורט יותר על כל מדד:
התצוגה הזו מספקת הרבה מידע שימושי שעוזר לזהות בעיות בביצועים, אבל אפשר לקבל מידע נוסף באמצעות מעקב.
פירוט באמצעות חלונית הביצועים
בחלונית הביצועים בכלי הפיתוח ל-Chrome אפשר לתעד פרופיל (או מעקב) של כל התנהגות הדפים במהלך פרק זמן מתועד.
תזמונים מרכזיים — כמו LCP, לדוגמה — מוצגים במסלול 'תזמונים'. אפשר ללחוץ עליהם כדי לקבל פרטים נוספים.
המעקב אחרי שינויים בפריסה מדגיש שינויים בפריסה, ולחיצה עליהם מספקת פרטים נוספים על הרכיבים שהשתנו לצורך ניפוי באגים ב-CLS.
משימות ארוכות (שיכולות להוביל לבעיות INP) מודגשות גם הן באמצעות משולשים אדומים.
התכונות האלה, יחד עם מידע בחלקים אחרים של לוח הביצועים, יכולות לעזור לכם לקבוע אם לתיקונים יש השפעה על מדדי Core Web Vitals של דף מסוים.
ניפוי באגים של מדדי הליבה לבדיקת חוויית המשתמש באתר בשטח
לא תמיד אפשר לזהות בכלים של Lab את הסיבה לכל הבעיות במדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) שמשפיעות על המשתמשים. זו אחת הסיבות לכך שחשוב מאוד לאסוף נתונים משלכם מהשטח, כי הם מביאים בחשבון גורמים שלא ניתן להביא בחשבון בנתונים מהמעבדה.
מידע נוסף זמין במאמר ניפוי באגים של ביצועים בשטח.
שלב 3: מעקב אחר שינויים
אחרי שתתקנו את הבעיות, רצוי לוודא שהן מניבות את ההשפעה הרצויה ושבעיות חדשות לא משבשות את מדדי הליבה של חוויית השימוש באתר. לשם כך, צריך לעקוב אחרי בעיות בביצועים כחלק מתהליך העבודה של המפתחים כדי למנוע שחרור של בעיות בביצועים בסביבת הייצור, ולעקוב באופן קבוע אחרי נתוני השדה כדי לוודא שהבעיה לא נובעת מהם.
מעקב אחר בקשות לביצועים בסביבות של אינטגרציה רציפה (CI)
Lighthouse-CI מאפשר להריץ באופן אוטומטי בדיקות של Lighthouse על השמירה של הקוד, כדי למנוע פגיעה בביצועים. אפשר להשתמש באפשרות הזו כדי לבדוק את זמני הביצועים (שנתונים לשינויים), או רק את ביקורות הביצועים, ככלי לניפוי שגיאות בקוד כדי למנוע שיטות עבודה לא טובות.
הצגת מגמות בבריאות האתר באמצעות נתוני שדה
מומלץ לזהות ולתקן את כל בעיות הביצועים לפני שהן מגיעות לסביבת הייצור, אבל חשוב לעקוב אחרי נתוני השדה באמצעות RUM כדי למצוא בעיות שלא זוהו. יש הרבה מוצרים מסחריים של RUM שיכולים לעזור בכך. ספריית JavaScript web-vitals יכולה להפוך לאוטומטי את איסוף נתוני השדות באתר, ולאפשר שימוש בנתונים האלה כדי להפעיל מרכזי בקרה ומערכות התראות בהתאמה אישית.
באתרים שאין להם פתרון RUM, אפשר להשתמש במרכז הבקרה של CrUX לניתוח מגמות בסיסי של נתוני השדות. הדוח כולל את הנתונים הבאים לגבי אתרים ב-CrUX:
- סקירה כללית על אתרים, שמפלחת את מדדי הליבה לבדיקת חוויית המשתמש באתר לפי סוגים של מחשבים וניידים.
- מגמה היסטורית לפי סוג מדד – התפלגות של מדדים לאורך זמן לכל גרסה חודשית זמינה של נתוני דוח CrUX.
- דמוגרפיה של משתמשים – התפלגות צפיות בדפים במקור מסוים בקרב משתמשים בכל קבוצה דמוגרפית, כולל סוגי מכשירים וחיבורים אפקטיביים.
מרכז הבקרה של CrUX מבוסס על מערך הנתונים של CrUX ב-BigQuery, שמתעדכן פעם בחודש. זהו תזכורת טובה לבדוק באופן קבוע את המדדים הבסיסיים של חוויית המשתמש.
סיכום
כדי להבטיח חוויית משתמש מהירה ומהנה, יש צורך בתפיסת עולם שמתמקדת בביצועים ובתהליך עבודה שמבטיח התקדמות. בעזרת הכלים והתהליכים המתאימים לבדיקות, לניפוי באגים ולמעקב, תוכלו ליצור חוויית משתמש מעולה ולהישאר בתוך ערכי הסף שהוגדרו לקבלת ציונים טובים במדדים הבסיסיים של חוויית המשתמש.