הדוח בנושא Core Web Vitals

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

פתיחה של דוח Core Web Vitals

הסבר על הדוח

בדוח בנושא Core Web Vitals מוצגים ביצועים של כתובות URL, שמקובצים לפי סטטוס ("איטיים", "דרוש שיפור" או "מהירים"), סוג מדד (CLS,‏ INP או LCP) וקבוצת כתובות URL (קבוצות של דפי אינטרנט דומים).

הדוח מבוסס על 3 מדדים לפי נתוני משתמשים בפועל: LCP,‏ INP ו-CLS. לאחר שכמות הנתונים לגבי קבוצת כתובות ה-URL עוברת את סף המינימום במדדים LCP ו-CLS, הסטטוס של קבוצת כתובות ה-URL הוא המדד עם הביצועים הגרועים ביותר. לדוגמה, אם לקבוצת כתובות ה-URL יש CLS נמוך אבל INP טוב, הסטטוס של כתובת ה-URL יהיה "איטי".

אם לקבוצת כתובות URL אין כמות מינימלית של נתוני דיווח במדדים LCP ו-CLS, כתובת ה-URL לא תיכלל בדוח.

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

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

ניווט בדוח

בדוח מוצגת טבלה של כתובות URL עם בעיות איטיות או עם בעיות לשיפור (למה כתובות ה-URL נחשבות לדפים עם חוויה לא טובה) לכל פלטפורמה (נייד או מחשב), וטבלה נוספת של כתובות URL עם כל הציונים הטובים למדדים LCP,‏ INP ו-CLS (לעיון בנתונים על כתובות URL עם מדדים טובים).

1. בדף הנחיתה אפשר לראות תרשים של מגמות כלליות לכל הפלטפורמות.
2. כדי להציג פירוט לפי פלטפורמה (נייד או מחשב), לוחצים על פתיחת הדוח לצד אחד מהתרשימים.
3. כדי להתרשם מהביצועים של כתובות ה-URL באתר שלכם, על סמך נתוני משתמש היסטוריים, עוברים בין הכרטיסיות "איטיים", "דרוש שיפור" או "מהירים" בתרשים הביצועים.
4. אפשר להציג רשימה של בעיות בביצועים בטבלה למה כתובות ה-URL נחשבות לדפים עם חוויה לא טובה. כל כתובת URL שמוצגת מייצגת קבוצה אחרת של כתובות URL.
5. בטבלה דוגמאות שבדף הפרטים של הבעיה, לוחצים על כתובת URL כדי להציג מידע נוסף על קבוצת כתובות ה-URL הזו.

מקורות הנתונים של הדוח

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

סטטוס הקבוצה: 'דפים איטיים', 'דרוש שיפור', 'דפים מהירים'

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

כברירת מחדל, הסטטוס של קבוצת כתובות URL מוגדר לפי הסטטוס האיטי ביותר שהוקצה לה באותו סוג מכשיר. לדוגמה: 

• כתובת URL בנייד עם נתוני CLS בסטטוס דפים איטיים ונתוני LCP בסטטוס דרוש שיפור תסומן בתווית דפים איטיים בנייד.
• כתובת URL בנייד עם נתוני LCP בסטטוס דרוש שיפור ונתוני CLS בסטטוס דפים מהירים תסומן בתווית דרוש שיפור בנייד.
• כתובת URL עם נתוני LCP,‏ INP ו-CLS בסטטוס דפים מהירים בנייד ונתוני LCP,‏ INP ו-CLS בסטטוס דרוש שיפור במחשב, תסומן בסטטוס דפים מהירים בנייד ודרוש שיפור במחשב.

הגדרות סטטוס

אלו טווחי הביצועים של כל סטטוס:

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

ניתן לקבל המלצות לתיקון הבעיות האלו על ידי הפעלת בדיקה חיצונית.

קבוצות של כתובות URL

כתובות ה-URL בדוח מקובצות עם דפים שחוויית המשתמש בהם דומה. הסטטוסים LCP,‏ INP ו-CLS רלוונטיים לכל הקבוצה. יכול להיות שלכתובות URL שמזוהות כחריג חשוד טעות יהיו ערכים טובים יותר או פחות בביקורים מסוימים, אבל ב-75% מהביקורים בכל כתובות ה-URL בקבוצה, החוויה תאמה לערך הסטטוס שמוצג ביחס לקבוצה. ההנחה היא שלקבוצות האלה יש מסגרת משותפת. לכן, אם הביצועים של הקבוצה האיטיים, סביר להניח שהם נגרמים מאותן סיבות בסיסיות.

כדי לכבד את פרטיות המשתמשים, לצורך הצגת קבוצה של כתובות URL בדוח, הקבוצה צריכה לכלול כמות מינימלית של נתונים. אם אין מספיק נתונים לגבי קבוצת כתובות URL להצגה בדוח, מערכת Search Console תיצור קבוצת מקור ברמה גבוהה יותר שאמורה להכיל מספיק כתובות URL ונתונים להצגה בדוח. קבוצת המקור הזו מכילה נתונים לגבי כל כתובות ה-URL באותה קבוצת protocol://host:port. לדוגמה, אם כתובת ה-URL‏ https://m.example.com/a/b/c.html שייכת לקבוצה שאין לגביה מספיק נתונים להצגה בדוח, מערכת Search Console תיצור קבוצת מקור – https://m.example.com. קבוצת המקור הזו מכילה נתונים לגבי כל כתובות ה-URL שנכללות בכתובת https://m.example.com, גם אם כתובת ה-URL הזו שייכת בעצמה לקבוצה עם מספיק נתונים, וגם אם לא.

כמה הערות:

• ההגדרה של קבוצת המקור כוללת את הפרוטוקול, לכן הקבוצה http://m.il.example.com והקבוצה https://m.il.example.com הן קבוצות מקור נפרדות.
• קבוצת המקור מכילה נתונים של כל כתובות ה-URL שמתחת למקור, בין אם כתובת URL שייכת לקבוצה אחרת שמוצגת בדוח ובין אם לא.
• אם אין לקבוצת המקור מספיק נתונים, היא לא תוצג (וכתוצאה מכך, לא יהיו לאתר מספיק נתונים להצגה בדוח הזה, אלא אם יש כמה קבוצות מקור).
• תוכלו להציג את הנתונים של קבוצת המקור בין אם היא נכללת בנכס הנוכחי ובין אם לא. עם זאת, אפשר להציג רק כתובות URL לדוגמה שנכללות בנכס הנוכחי.
• כתובות שמוצגות בקבוצה ב-Search Console מסודרות לפי מספר החשיפות, בסדר יורד.

איך לפתור את הבעיות

סטטוס האתר שלי השתנה, אבל לא שיניתי כלום

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

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

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

אימות תיקונים

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

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

סטטוס אימות של בעיה

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

אלו האפשרויות לסטטוסים של אימות:

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

סטטוס אימות של כתובת URL

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

• בהמתנה: Google מחכה לאיסוף של מספיק נתונים כדי לקבוע אם כתובת ה-URL עדיין מושפעת.
• עבר: נראה שכתובת ה-URL כבר לא מושפעת מהבעיה.
• נכשל: כתובת ה-URL עדיין מושפעת מהבעיה.

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

כל כתובות ה-URL שהוסרו מהאינטרנט ושאין נתונים לגביהן ב-28 הימים האחרונים לא יופיעו בהיסטוריית האימות או בדוח.