דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals)

תיקון בעיות של חוויות משתמש איטיות באתר

בדוח המדדים הבסיסיים של חוויית המשתמש, ביצועי הדפים מוצגים לפי נתוני השימוש בפועל (שלפעמים נקראים נתוני שטח). בבלוג של Google Search Central מפורט מידע נוסף על היוזמה.

פתיחת הדוח

למה הביצועים של דפים חשובים

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

  • מחקרים הראו שכשאתר עומד בערכי הסף של דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), יש סיכוי נמוך יותר ב-24% לנטישה של משתמשים במהלך טעינת הדף.
  • בכל הפחתה של 100 אלפיות השנייה ב-Largest Contentful Paint‏ (LCP), שיעור ההמרה (CVR) באינטרנט של Farfetch גדל ב-1.3%.
  • ירידה של 0.2 בערך של Cumulative Layout Shift ‏(CLS) של Yahoo!‎ JAPAN הובילה לעלייה של 15% במספר הצפיות בדפים בכל סשן, למשכי סשן ארוכים יותר ב-13% ולירידה של 1.72 נקודות אחוז בשיעור העזיבה.
  • דוח המדדים הבסיסיים של חוויית המשתמש של Netzwelt השתפר וכתוצאה מכך ההכנסות מפרסום גדלו ב-18% ומספר הצפיות בדפים גדל ב-27%.
  • ירידת ערך ה-CLS מ-1.65 ל-0 הובילה לעלייה בדירוגי הדומיינים של redBus ברחבי העולם.

כאן תוכלו לקרוא על מקרים נוספים לדוגמה

הסבר על הדוח

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

הדוח מבוסס על שלושה מדדים לפי נתוני משתמשים בפועל: LCP,‏ FID ו-CLS. לאחר שכמות הנתונים לגבי קבוצת כתובות ה-URL עוברת את סף המינימום במדדים LCP ו-CLS, הסטטוס של קבוצת כתובות ה-URL הוא המדד עם הביצועים הגרועים ביותר. לדוגמה, אם לקבוצת כתובות ה-URL יש CLS נמוך אבל FID טוב, הסטטוס של כתובת ה-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,‏ FID ו-CLS (הצגת הנתונים לכתובות URL טובות).

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

 

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

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

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

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

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

תרשים

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

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

 

טבלה

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

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

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

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

תרשים

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

טבלה

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

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

  • כתובת URL: כל שורה בטבלה מייצגת קבוצה של כתובות URL דומות.
  • לדפים עם סטטוס לא טוב: העמודה המתאימה למטה תוצג, בהתאם לסוג הבעיה שבודקים. חשוב לשים לב שכתובת URL יחידה יכולה להיות מושפעת ממספר בעיות, אבל רק העמודה המתאימה לבעיה הנבחרת מוצגת.
    • FID קבוצתי: ב-28 הימים האחרונים, זה היה משך הזמן המקסימלי לתגובה לקלט ראשוני מהמשתמשים ב-75% מהבקשות לדפים.
    • LCP קבוצתי: ב-28 הימים האחרונים, זה היה משך הזמן המקסימלי להגיע ל-Largest Contentful Paint ‏(LCP) ב-75% מהבקשות לדפים.
    • CLS קבוצתי: ב-28 הימים האחרונים, זה היה הציון המקסימלי ב-Cumulative Layout Shift ‏(CLS)‏ של 75% מהבקשות לדפים.

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

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

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

הדוח לא מיועד לחיפוש סטטוס של כתובת URL ספציפית, אלא להצגת הביצועים של האתר שלכם באופן כללי, ולפתרון בעיות שמשפיעות על מספר דפים באתר. אם רוצים להציג נתוני ביצועים של כתובת URL ספציפית, צריך להשתמש בבדיקה חיצונית. אתם יכולים להציג פירוט של סטטוס ובעיה ולראות כתובות 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 עם נתוני FID,‏ LCP ו-CLS בסטטוס דפים מהירים בנייד ונתוני FID,‏ LCP ו-CLS בסטטוס דרוש שיפור במחשב, מסומנת בסטטוס דפים מהירים בנייד ודרוש שיפור במחשב.

 

הגדרות סטטוס

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

  מהירים דרוש שיפור איטיים
LCP <=2.5 שנ' <=4 שנ' >4 שנ'
FID <=100 אלפיות שנייה <=300 אלפיות שנייה >300 אלפיות שנייה
CLS <=0.1 <=0.25 >0.25

 

  • LCP‏ (Largest Contentful Paint): משך הזמן שנדרש להצגת רכיב התוכן הגדול ביותר שנראה באזור התצוגה, החל מהרגע שהמשתמש שולח בקשה לכתובת ה-URL. הרכיב הגדול ביותר הוא בדרך כלל תמונה או סרטון, או אולי בלוק של רכיב טקסט. המדד הזה חשוב כי הוא מציין באיזו מהירות כתובת ה-URL נטענת בפועל ומוצגת למבקרים.
    • הנתון LCP קבוצתי שמוצג בדוח מציין כמה זמן עובר עד ש-75% מהביקורים בכתובת URL בקבוצה מגיעים למצב LCP.
  • FID (השהיה לאחר קלט ראשוני): הזמן שעובר מרגע האינטראקציה הראשונית של משתמש עם הדף שלכם (לחיצה על קישור, הקשה על לחצן ועוד) עד לרגע שבו הדפדפן מגיב לאינטראקציה. המדידה הזו מבוצעת מהאלמנט האינטראקטיבי הראשון שעליו המשתמש לוחץ. הנתון הזה חשוב בדפים שבהם משתמשים צריכים לבצע פעולה כלשהי, כי זוהי ההשהיה שבסופה הדף הופך לאינטראקטיבי.
    • הנתון FID קבוצתי הוא הערך המינימלי שהושג ב-75% מהביקורים בכתובת ה-URL בקבוצה הזו.
  • CLS ‏(Cumulative Layout Shift): ה-CLS מודד את סך כל התוצאות הנפרדות של מידת התזוזות בפריסת הדף עבור כל תזוזה בפריסת הדף שמתרחשת במהלך משך החיים של הדף. התוצאה היא אפס לכל מספר חיובי, ומשמעות התוצאה היא שלא התרחשו תזוזות בכלל. ככל שהמספר גדול יותר, כך יש יותר תזוזות בפריסת הדף. המדד הזה חשוב כי תזוזה של מרכיבים בדף בזמן שהמשתמש מנסה ליצור איתם אינטראקציה יוצרת חוויית משתמש לא טובה. אם לא גיליתם את הסיבה לערך גבוה, נסו לבצע אינטראקציה עם הדף כדי לראות איך זה משפיע על התוצאה.
    • הנתון CLS קבוצתי שמוצג בדוח הוא מדד ה-CLS הנפוץ ביותר ל-75% מהכניסות לכתובת URL בקבוצה.

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

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

כתובות ה-URL בדוח מקובצות עם דפים שחוויית המשתמש בהם דומה. הסטטוסים LCP,‏ FID ו-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 משאבים.
    • מומלץ להשתמש ב-AMP, שכמעט תמיד מבטיח טעינת דפים טובה גם בניידים וגם במחשבים.
    • משתמשים בבדיקה חיצונית לקבלת המלצות לתיקון הדף.
  4. בודקים את התיקונים באמצעות בדיקה חיצונית.
  5. כשנראה שבעיה מסוימת תוקנה, לוחצים על הפעלת מעקב בדף פרטי הבעיה בדוח המדדים הבסיסיים של חוויית המשתמש של 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. כשנראה שבעיה מסוימת תוקנה, לוחצים על הפעלת מעקב בדף פרטי הבעיה בדוח המדדים הבסיסיים של חוויית המשתמש של Search Console.
  7. עוקבים אחר תהליך האימות.

משאבים שימושיים נוספים:

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

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

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

יש לבדוק אם היו תנודות גדולות כלשהן בנתונים של תנועת הגולשים לאתר בטווח הזמן הזה. כמו כן יש לבדוק בקפידה אם היו בעיות ספציפיות ולבחון את נתוני ה-LCP/FID/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, כולל מדדים בסיסיים של חוויית המשתמש ומדדים של חוויית השימוש בדף. הבדיקה מציגה גם נתוני בדיקה של גרסה פעילה וגם נתונים של ניסויי שטח ממשתמשים שנכנסו לאתר בפועל.

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

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

האם המידע הועיל?
איך נוכל לשפר את המאמר?
חיפוש
ניקוי החיפוש
סגירת החיפוש
אפליקציות Google
תפריט ראשי
חיפוש במרכז העזרה
true
true
false
true
true
83844