הדוח בנושא 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 בפועל, ולא לכתובת ה-URL הקנונית, כמו ברוב הדוחות האחרים.

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

"אין נתונים זמינים"

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

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

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

ניווט בדוח

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

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

 

דף סקירה כללית

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

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

דפי הסיכום לגבי ניידים ומחשבים

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

תרשים

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

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

 

טבלה

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

כתובת URL עשויה להופיע בכמה שורות בטבלה אם היא מושפעת מכמה בעיות.

דף הפרטים של בעיה לגבי ניידים ומחשבים

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

תרשים

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

טבלה

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

בטבלה תמצאו את הפרטים הבאים:

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

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

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

איך למצוא את הסטטוס של כתובת URL ספציפית

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

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

הנתונים בדוח בנושא 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 <=2.5 שנ' <=4 שנ' ‫>4 שנ'
INP <=200 אלפיות שנייה <=500 אלפיות שנייה >500 אלפיות שנייה
CLS <=0.1 <=0.25 ‫>0.25

 

  • 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 מסודרות לפי מספר החשיפות, בסדר יורד.

תיקון הבעיות

משתמשים שאינם טכניים

  1. כדאי לתעדף את הבעיות: אנחנו ממליצים לתקן קודם את כל הבעיות בדפים 'איטיים', ולאחר מכן לתעדף לפי אחד מהסיווגים האלה: בעיות שמשפיעות על המספר הגדול ביותר של כתובות URL, או בעיות שמשפיעות על כתובות ה-URL החשובות ביותר. ניתן לשפר כתובות URL עם התווית 'דרוש שיפור', אבל חשוב יותר לפתור בעיות בכתובות URL איטיות.
  2. אחרי שממיינים לפי עדיפות, משתפים את הדוח עם מהנדס התוכנה או עם מי שאחראי לעדכון כתובת ה-URL.
  3. תיקוני דפים נפוצים:
    • מקטינים את גודל הדף: השיטה המומלצת היא פחות מ-500KB לדף ולכל המשאבים שבו.
    • כדי להשיג את הביצועים הטובים ביותר בנייד, כדאי להגביל את הדף ל-50 משאבים.
    • משתמשים בבדיקה חיצונית לקבלת המלצות לתיקון הדף.
  4. בודקים את התיקונים באמצעות בדיקה חיצונית.
  5. כשנראה שבעיה מסוימת נפתרה, לוחצים על התחלת מעקב בדף פרטי הבעיה שבדוח בנושא Core Web Vitals של Search Console.
  6. עוקבים אחר תהליך האימות.

מפתחי אתרים

  1. מסדרים את הבעיות לפי סדר עדיפויות: מומלץ לתקן את כל מה שמסומן בתווית 'איטי'. אפשר לשפר כתובות URL שמסומנות בתווית 'דרוש שיפור', אבל חשוב יותר לפתור בעיות בכתובות URL איטיות. בין הבעיות בסטטוס מסוים, כדאי לתת עדיפות לבעיות שמשפיעות על המספר הגדול ביותר של כתובות URL, או לבעיות שמשפיעות על כתובות ה-URL החשובות ביותר.
  2. כתובות ה-URL שמוצגות בקבוצה נתונה ממוינות לפי חשיפה ובסדר יורד, אז כתובות ה-URL שבראש הרשימה הן המשפיעות ביותר על סטטוס הקבוצה. כדאי לתקן את כתובות ה-URL לפי הסדר שבו הן מוצגות כדי שההשפעה על הסטטוס תהיה הכי משמעותית, ומומלץ לתקן כמה שיותר כתובות URL. הערה: אם קבוצה נמצאת קרוב לקצה הסטטוס, יכול להיות שהסטטוס מושפע מכמה כתובות URL בקבוצה שנמצאות בהמשך הרשימה.
  3. לקבלת תיאוריה והנחיות לשיפור מהירות דף, אנחנו ממליצים לעיין בהנחיות לטעינה מהירה של web.dev ובדפי הביצועים של Web Fundamentals (היסודות של בניית אתרים) בכתובת developers.google.com.
  4. משתמשים בבדיקה חיצונית לקבלת המלצות לתיקון הדף.
  5. בודקים את התיקונים באמצעות בדיקה חיצונית.
  6. כשנראה שבעיה מסוימת נפתרה, לוחצים על התחלת מעקב בדף פרטי הבעיה שבדוח בנושא Core Web Vitals של Search Console.
  7. עוקבים אחר תהליך האימות.

עוד מקורות מידע שימושיים:

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

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

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

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

 

שיתוף הדוח

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

ייצוא של נתוני הדוח

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

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

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

האפשרותהפעלת מעקב לא מפעילה הוספה מחדש לאינדקס או כל התנהגות פעילה אחרת מצד Google. הפעולה פשוט מתחילה (מחדש) את תקופת המעקב ב-Search Console למשך 4 שבועות אחר נתוני CrUX באתר שלכם.
  • להצגת פרטי האימות של בקשת אימות בתהליך או של בקשה שנכשלה:
    • לוחצים על לעיון בפרטים בקטע של סטטוס האימות שבדף הפרטים של הבעיה.
  • להפעלה מחדש של תקופת מעקב לצורך אימות בכל שלב:
    • פותחים את דף הפרטים של האימות ולוחצים על התחלת אימות חדש.
  • אם האימות נכשל:
    1. מנסים לתקן את הבעיות שוב.
    2. כדי להפעיל את המעקב מחדש, פותחים את דף הפרטים של האימות ולוחצים על התחלת אימות חדש.

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

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

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

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

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

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

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

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

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

 

כלי בדיקה חיצוניים

דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) מקשר לשני כלי בדיקה חיצוניים לבדיקות דפים נוספות. סוג הכלי תלוי בסוג הדף:

  • דפים שאינם AMP: כלי הבדיקה PageSpeed Insights מדווח על הביצועים של דף גם במכשירים ניידים וגם במחשבים, ומספק הצעות לשיפור הדף. הבדיקה מציגה גם נתוני בדיקה של גרסה פעילה וגם נתונים של ניסויי שטח ממשתמשים שנכנסו לאתר בפועל. שימו לב: המידע ב-PageSpeed Insights עשוי להיות שונה מהמידע בדוח המדדים הבסיסיים של חוויית המשתמש. כאן מוסברת הסיבה לכך.
  • דפי AMP: מדריך חוויית השימוש בדף AMP מספק בדיקה מקיפה של גרסה פעילה בדפי AMP, כולל מדדי Core Web Vitals. הבדיקה מציגה גם נתוני בדיקה של גרסה פעילה וגם נתונים של ניסויי שטח ממשתמשים שנכנסו לאתר בפועל.

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

תוכלו גם להשתמש בכלי הבדיקה המובנה בדפדפן Chrome: הכלי Chrome Lighthouse.

האם המידע הועיל?

איך נוכל לשפר את המאמר?

צריכים עזרה נוספת?

תוכלו לנסות את האפשרויות הבאות:

חיפוש
ניקוי החיפוש
סגירת החיפוש
אפליקציות Google
התפריט הראשי