כדי לבדוק, לשפר ולנטר את האתר שלכם בצורה יעילה, כדאי לשלב בין הכלים של Google.
תאריך פרסום: 28 במאי 2020
Core Web Vitals הם קבוצה של מדדים שמעריכים את חוויית השימוש לפי קריטריונים כמו ביצועי הטעינה, תגובה לקלט של משתמשים ויציבות הפריסה.
במדריך הזה נסביר על תהליך העבודה לשיפור מדדי ה-Core Web Vitals של האתר, אבל נקודת ההתחלה של התהליך תלויה בשאלה אם אתם אוספים נתוני שדה משלכם. היכן הוא מסתיים תלוי בכלים של Google שיועילו לכם באבחון ובתיקון של בעיות בחוויית המשתמש.
הדרך הכי טובה למדוד את Core Web Vitals היא בשטח
Core Web Vitals הם מדדים שמתמקדים במשתמשים, והם נועדו במיוחד למדוד את חוויית המשתמשים באתר. כלים מבוססי-מעבדה כמו Lighthouse הם כלי אבחון שמדגישים בעיות פוטנציאליות בביצועים ושיטות מומלצות. כלים שמבוססים על נתוני מעבדה פועלים בתנאים מסוימים שהוגדרו מראש, ולא תמיד משקפים את המדידות של Core Web Vitals שמתבצעות בפועל אצל המשתמשים.
לדוגמה, Lighthouse הוא כלי מבוסס-מעבדה שמריץ בדיקות עם ויסות נתונים מדומה בסביבה מדומה של מחשב או מכשיר נייד. סימולציות כאלה של תנאי רשת ומכשירים איטיים יותר עוזרות כשמנסים לאבחן בעיות בביצועים, אבל הן רק חלק קטן מהמגוון הרחב של תנאי הרשת ויכולות המכשירים, ולכן יכול להיות שהן לא משקפות את מה שהמשתמשים באתרים שלכם חווים.
כלים מבוססי-מעבדה כמו Lighthouse בדרך כלל מבצעים גם "טעינה קרה" של דף אינטרנט, כאילו מדובר במבקר חדש לגמרי. בדרך כלל זו הטעינה האיטית ביותר, אבל בחיים האמיתיים, יכול להיות שחלק מהנכסים נשמרו במטמון של המבקרים אם הם ביקרו באתר בעבר, או כשהם גולשים באתר. גם מבקרים חדשים וכלים עשויים לחוות את האתר בצורה שונה, אם מוצגות להם הודעות על שימוש בקובצי Cookie או תוכן אחר.
בקיצור, כלים שמבוססים על נתוני מעבדה יכולים לתת אינדיקציה לבעיות פוטנציאליות בביצועים ולעזור לכם לנפות באגים ולבצע שינויים, אבל הם לא בהכרח מייצגים את החוויה של המבקרים באתר שלכם. כדי למדוד את הביצועים בעולם האמיתי, השתמשו בנתוני שטח. כדי לאבחן איך לשפר את הביצועים, השתמשו בכלים מבוססי-מעבדה כמו Lighthouse. כדאי גם לעיין בקטע מתי כדאי להשתמש ב-Lighthouse.
Google מודדת את מדדי ה-Core Web Vitals באמצעות הדוח לגבי חוויית המשתמש ב-Chrome (CrUX). זו קבוצת נתונים ציבורית שנאספה ממשתמשי Chrome אמיתיים. הוא הבסיס של הרבה כלים של Google ושל צדדים שלישיים שמדווחים על מדדי ה-Core Web Vitals של אתר.
עם זאת, ל-CrUX יש מגבלות. הוא יכול להגיד לכם מתי יש בעיה, אבל בדרך כלל אין לו מספיק נתונים כדי להגיד לכם למה.
אם אפשר, כדאי לאסוף נתוני שדה משלכם
קבוצת הנתונים הטובה ביותר לשיפור ביצועי האתר בשטח היא זו שאתם יוצרים. השלב הראשון הוא לאסוף נתוני שדה מהמבקרים באתר. האופן שבו עושים את זה תלוי בגודל הארגון, ובהחלטה אם לשלם על פתרון של צד שלישי או ליצור פתרון משלכם.
פתרונות בתשלום כמעט תמיד מודדים את Core Web Vitals (ומדדי ביצועים אחרים), ובדרך כלל מספקים מגוון כלים לניתוח הנתונים שמתקבלים. בארגונים גדולים עם משאבים משמעותיים, יכול להיות שזו השיטה המועדפת.
עם זאת, יכול להיות שאתם לא חלק מארגון גדול, או אפילו מארגון שיש לו את האמצעים לממן פתרון של צד שלישי. במקרים כאלה, ספריית 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) ולפלח את הנתונים בצורה טובה יותר כדי לזהות בעיות. האם משתמשים שמחוברים לחשבון נהנים מ-Core Web Vitals טוב יותר או פחות טוב מאשר משתמשים שלא מחוברים לחשבון? האם למשתמשים עם LCP איטי יש רכיב LCP מסוים? אילו אינטראקציות גורמות לערכים גבוהים של FID ו-INP?
PageSpeed Insights (PSI)
PSI הוא כלי שמדווח על נתונים מהשטח מ-CrUX וגם על נתוני מעבדה מ-Lighthouse לגבי דף נתון. לפרטים נוספים, אפשר לעיין בקטעים הרלוונטיים.
מתי להשתמש ב-PSI
הכלי PSI מצוין להערכת הביצועים של CrUX ברמת הדף או ברמת המקור, גם למשתמשים בנייד וגם למשתמשים במחשב. הוא מתאים לקבלת סקירה ראשונית של Core Web Vitals בדף או באתר. הוא גם מאפשר לכם לראות את נתוני Core Web Vitals של אתרים אחרים, כמו מתחרים.
בנוסף, PSI מספק נתונים מ-Lighthouse, שכוללים המלצות מועילות לשיפור Core Web Vitals – אם המדדים תואמים. אם אין התאמה, יכול להיות שההמלצות של 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 יש גם דוח בנושא 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 במהלך פיתוח ופריסה של פרויקטים, כדי לעזור בבדיקות רגרסיה של ביצועים. הוא מציג דוח Lighthouse יחד עם בקשות משיכה, ועוקב אחרי מדדי ביצועים לאורך זמן.
מתי כדאי להשתמש ב-Lighthouse
Lighthouse הוא כלי מצוין למציאת הזדמנויות לשיפור הביצועים במהלך הפיתוח, גם בסביבות מקומיות וגם בסביבות Staging. Lighthouse CI שימושי גם בשלבי הפיתוח והפריסה בסביבות ה-staging והייצור, שבהן נדרשות בדיקות רגרסיה של הביצועים כדי לשמור על חוויית משתמש טובה.
מתי לא להשתמש ב-Lighthouse
Lighthouse (או Lighthouse CI) לא מחליף את נתוני השדה. Lighthouse הוא בעיקר כלי אבחון שמפרט בעיות פוטנציאליות ושיטות מומלצות מטעינת דף מוגדרת מראש. יכול להיות שההמלצות שמוצגות לא תמיד יתאימו לביצועים שהמשתמשים חווים.
אפשר להשתמש ב-Lighthouse כדי לאבחן אתרים בסביבת הייצור באמצעות כלים כמו PageSpeed Insights, אבל עדיף להשתמש ב-Lighthouse בסביבות פיתוח ושילוב רציף (CI) כדי לטפל בבעיות בביצועים לפני שהן מגיעות לסביבת הייצור.
הבדיקות ש-Lighthouse מספק זמינות גם דרך "תובנות" בחלונית הביצועים בכלי הפיתוח ל-Chrome, שמספקת ניתוח מעמיק יותר של ביצועי הדף.
החלונית "ביצועים" בכלי הפיתוח ל-Chrome
כלי הפיתוח ל-Chrome הם אוסף של כלים לפיתוח בדפדפן, כולל החלונית Performance. חלונית הביצועים היא כלי מעבדה שמורכב משני "מצבים":
כשפותחים את החלונית Performance בפעם הראשונה, מופיע מסך Live Metrics עם המדדים הנוכחיים של Core Web Vitals, ואפשר לייבא נתוני שטח מ-CrUX. הוא שימושי בתור תצוגה "בזמן אמת" של הביצועים בזמן האינטראקציה עם הדף, כדי לנסות לחשוף בעיות בביצועים – במיוחד בעיות שמופיעות אחרי הטעינה, שאפשר לראות במדדים CLS ו-INP.
שנית, חלונית הביצועים מאפשרת למפתחים לתעד פרופיל (או מעקב) של כל הפעילות בדף במהלך טעינת הדף או במהלך תקופה מתועדת. התצוגה הזו מספקת תובנות מעמיקות לגבי כל מה שהיא מזהה במאפיינים כמו פעילות ברשת, רינדור, ציור וסקריפטים, וגם לגבי מדדי Core Web Vitals של הדף. הוא כולל גם תובנות, בדומה לאלה ש-Lighthouse מספק.
מתי כדאי להשתמש בחלונית הביצועים
מפתחים יכולים להשתמש בחלונית "ביצועים" כדי לקבל תובנות מעמיקות לגבי הביצועים של דף מסוים.
אפשר להשתמש בתצוגת המדדים בזמן אמת כדי להבין במהירות את מאפייני הביצועים הנוכחיים של הדף, וגם לזהות בעיות פוטנציאליות בזמן האינטראקציה עם הדף.
תצוגת המעקב שימושית במיוחד לניפוי באגים בבעיות של תגובה שמשפיעות על INP. אחרי שמזהים אינטראקציה עם תגובה איטית וניתן לחזור עליה, חלונית הביצועים יכולה לספק הרבה נתונים לגבי מה שקורה בדפדפן כדי לעזור להבין את הבעיה, החל מחסימת השרשור הראשי, דרך סטאקים של סטאק ביצוע של JavaScript ועד לעבודת רינדור.
מתי לא כדאי להשתמש בחלונית הביצועים
החלונית Performance היא כלי למפתחים שמספק בעיקר נתוני מעבדה, אבל גם קצת הקשר מהשטח מ-CrUX. הוא לא מהווה תחליף לנתוני שדה.
תצוגת המעקב מכילה הרבה מידע על תוצאות ניפוי הבאגים, אבל בגלל זה, יכול להיות שיהיה קשה למפתחים מתחילים או לאנשים בתפקידים שאינם מפתחים להבין אותה. עם זאת, תצוגת המדדים בזמן אמת שמופיעה כשפותחים את החלונית מספקת ממשק קל יותר לשימוש למי שלא צריך את כל הפרטים.
תהליך עבודה בן שלושה שלבים שיעזור לכם לוודא שמדדי ה-Core Web Vitals של האתר שלכם נשארים תקינים
כשמנסים לשפר את חוויית המשתמש, כדאי לחשוב על התהליך כמעגל מתמשך. כדי לשפר את מדדי ה-Core Web Vitals ומדדים אחרים לבדיקת ביצועים, אפשר לנסות את הגישה הבאה:
- להעריך את תקינות האתר ולזהות בעיות.
- ניפוי באגים ואופטימיזציה.
- מעקב באמצעות כלים של אינטגרציה רציפה (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. האם יש מדדי Core Web Vitals שנכשלו, ובאיזו מידה? כך תדעו איפה כדאי למקד את המאמצים.
חשוב להבין את הקשר בין המספרים האלה, במיוחד לגבי LCP. אם ה-LCP איטי, כמו בדוגמה הזו, צריך לבדוק את ה-TTFB וה-FCP, ששניהם אבני דרך למדד הזה. בדוגמה הזו, ה-TTFB הוא 1.8 שניות, ולכן יהיה קשה מאוד לעמוד בסף המומלץ של 2.5 שניות ל-LCP טוב. זה מצביע על קצה עורפי איטי (בעיות בשרת או חוסר ב-CDN), רשתות איטיות יותר או הפניות אוטומטיות שמעכבות את הבייטים הראשונים של ה-HTML. מידע נוסף זמין במדריך לאופטימיזציה של TTFB. הצגת התוכן הראשוני (FCP) נמשכת עוד שנייה, וגם זה יכול להעיד על רשתות איטיות יותר. בדוגמה הזו, ה-LCP לא מתרחש הרבה אחרי ה-FCP, מה שמעיד על כך שמשאב ה-LCP עובר אופטימיזציה טובה אחרי שהדף עצמו נטען. בנוסף, ב-CrUX מוצג עכשיו מידע נוסף לאבחון בסוגי משאבים ובחלקים משניים, שעוזר גם לאבחן בעיות ב-LCP.
במדד CLS, בודקים את ציוני ה-CLS ב-CrUX וב-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 כדי לקבל מידע נוסף שיעזור לכם להבין את שורש הבעיה ולזהות אותה.
- מעיינים בדוחות הביקורת של Lighthouse כדי לקבל הנחיות כלליות לגבי הדף.
- כדי לנתח את מדדי ה-Core Web Vitals בזמן אמת, אתם יכולים להשתמש בתצוגת המדדים בזמן אמת בחלונית Performance.
- אפשר להשתמש במעקב של חלונית הביצועים כדי לנפות באגים בבעיות בביצועים ולבדוק שינויים בקוד.
הנחיות מפורטות יותר זמינות במדריכים הבאים:
זיהוי הזדמנויות בעזרת Lighthouse
הכלי PageSpeed Insights מפעיל את Lighthouse בשבילכם. אפשר גם להריץ את Lighthouse מכלי הפיתוח ל-Chrome, וזה שימושי לאימות תיקונים באופן מקומי, אבל חלונית הביצועים (שמפורטת בהמשך) היא כלי מקיף יותר לזיהוי ולתיקון של בעיות בביצועים באופן מקומי.
נקודה חשובה היא לוודא שהביקורת של Lighthouse משחזרת את הבעיות שאתם מנסים לפתור (לדוגמה, LCP איטי או בעיות ב-CLS). כברירת מחדל, Lighthouse מעריך את חוויית המשתמש רק במהלך טעינת הדף. מכיוון שמדובר בכלי מעבדה, הוא גם לא כולל את INP אלא את TBT.
כשהמדדים של Lighthouse מצביעים על בעיה דומה לזו שאתם מנסים לפתור, המידע הרב שמופיע בדוחות הביקורת יכול לעזור לכם לזהות בעיות ולהציע פתרונות.
אפשר לסנן את הבדיקות כך שיוצגו רק מדדי Core Web Vitals שמעניינים אתכם, כדי להתמקד בתיקון בעיות שקשורות למדד ספציפי:
ב-INP, משתמשים בבדיקות TBT כדי לזהות בעיות שיכולות להשפיע על המדדים האלה, אבל חשוב לזכור שבלי אינטראקציות, יכולת האבחון של Lighthouse מוגבלת.
ניתוח בזמן אמת באמצעות מסך המדדים בזמן אמת של כלי הפיתוח ל-Chrome
מסך המדדים בזמן אמת של כלי הפיתוח ל-Chrome בחלונית Performance מציג את מדדי Core Web Vitals בזמן אמת במהלך טעינת הדף וגם בזמן הגלישה בדף. לכן, הוא יכול לתעד את ה-INP וגם שינויים בפריסה שמתרחשים אחרי הטעינה. אפשר גם לראות מידע מפורט יותר על כל מדד:
התצוגה הזו מספקת הרבה מידע שימושי שעוזר לזהות בעיות בביצועים, ואפילו יכולה לשלוף מידע מהשטח מ-CrUX. כדי לקבל מידע נוסף, אפשר להציג פירוט באמצעות מעקב.
התעמקות בנתונים באמצעות חלונית הביצועים
החלונית "ביצועים" בכלי הפיתוח ל-Chrome מאפשרת לתעד פרופיל (או מעקב) של כל ההתנהגות בדף במהלך תקופת זמן מתועדת.
התובנות לגבי הביצועים זמינות בחלונית הצדדית תובנות. בנוסף, מוצגים מדדי Core Web Vitals וערכי השדות שלהם, אם הם זמינים.
הטראק שינויים בפריסה מדגיש את השינויים בפריסה. לחיצה על השינויים האלה מספקת פרטים נוספים על הרכיבים שהשתנו, כדי לנפות באגים ב-CLS.
תזמונים חשובים, כמו LCP, מוצגים בקטע Timings שזמין בתחתית המעקב. אפשר ללחוץ עליהם כדי לקבל פרטים נוספים.
משימות שנמשכות הרבה זמן (שיכולות לגרום לבעיות ב-INP) מודגשות גם במשולשים אדומים בתרשים הלהבה.
התכונות האלה, וגם המידע בחלקים אחרים של חלונית הביצועים, יכולים לעזור לכם לקבוע אם התיקונים משפיעים על מדדי Core Web Vitals של הדף.
ניפוי באגים ב-Core Web Vitals בשטח
כלים של מעבדה לא תמיד יכולים לזהות את הסיבה לכל הבעיות ב-Core Web Vitals שמשפיעות על המשתמשים. זו אחת מהסיבות לכך שחשוב כל כך לאסוף נתוני שדה משלכם, כי הם מביאים בחשבון גורמים שנתוני מעבדה לא יכולים להביא בחשבון.
מידע נוסף זמין במאמר ניפוי באגים בביצועים בשטח.
שלב 3: מעקב אחר שינויים
אחרי שמתקנים את הבעיות, חשוב לוודא שהתיקונים פועלים כמו שצריך ושהבעיות החדשות לא משבשות את ה-Core Web Vitals. כדי לעשות את זה, צריך לעקוב אחרי בעיות בביצועים כחלק מתהליך העבודה של המפתחים, כדי למנוע פרסום של בעיות בביצועים בסביבת הייצור, ולעקוב אחרי נתוני השדה באופן קבוע כדי לוודא שזה המצב.
מעקב אחרי דרישות הביצועים בסביבות של אינטגרציה רציפה (CI)
Lighthouse-CI מאפשר להריץ באופן אוטומטי בדיקות של Lighthouse על שמירות (commit) של קוד כדי למנוע רגרסיות בביצועים שנובעות מהזנת קוד. הוא יכול לבדוק את תזמוני הביצועים (שכפופים לשינויים), או רק את ביקורות הביצועים, ככלי לניתוח קוד סטטי כדי למנוע שיטות עבודה לא תקינות בקוד.
הצגת מגמות תקינות של האתר באמצעות נתוני שטח
כדאי לנסות לזהות ולתקן את כל הבעיות בביצועים לפני שהן מגיעות לסביבת הייצור, אבל חשוב לעקוב אחרי נתוני השטח באמצעות RUM כדי למצוא בעיות שלא זוהו. יש הרבה מוצרי RUM מסחריים שיכולים לעזור בכך. ספריית JavaScript של web-vitals יכולה להפוך את איסוף נתוני השדה של אתר לאוטומטי, ולהשתמש בנתונים האלה כדי להפעיל מרכזי בקרה מותאמים אישית ומערכות התראה.
באתרים שאין בהם פתרון RUM, אפשר להשתמש בכלים השונים של CrUX כדי לבצע ניתוח מגמות בסיסי של נתוני השדה.
סיכום
כדי להבטיח חוויית משתמש מהירה ומהנה, צריך לאמץ גישה שמתמקדת בביצועים ולהשתמש בתהליך עבודה שמאפשר התקדמות. עם הכלים והתהליכים הנכונים לביקורת, ניפוי באגים ומעקב, אתם יכולים ליצור חוויות משתמש נהדרות ולעמוד בסף שמוגדר ל-Core Web Vitals טובים.