Core Web Vitals למתחילים: איך למדוד ולשפר LCP, INP ו-CLS

מדדי Core Web Vitals בוחנים שלושה היבטים של ביקור באתר: כמה מהר מופיע התוכן הגלוי הגדול ביותר, כמה מהר הדף מגיב לפעולה, והאם הפריסה זזה במפתיע. המדדים הנוכחיים הם Largest Contentful Paint ‏(LCP), ‏Interaction to Next Paint ‏(INP) ו-Cumulative Layout Shift ‏(CLS). מתחילים בתוצאות של משתמשים אמיתיים, ואז משתמשים בהקלטה מבוקרת בדפדפן כדי למצוא את הרכיב, הפעולה או שינוי הפריסה שמאחורי הבעיה.

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

השאלה המועילה אינה רק אם האתר מהיר. צריך לברר באיזה חלק של הביקור יש כשל, אצל אילו מבקרים, ומה יוכיח שהשינוי עזר.

קוראים את שלושת המדדים לפני הציון הכללי

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

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

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

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

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

מבינים מה אומר האחוזון ה-75

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

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

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

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

גם לכלי הדיווח של Google יש כללים משלהם לכמות נתונים מספקת. PageSpeed Insights יכול להעריך LCP ו-CLS כאשר אין מספיק נתוני INP. יש לקרוא את ההערכה שהדוח מציג ואת היקף הנתונים שלה, בלי להמציא ערך חסר ובלי להניח שכל הכלים מציגים נתונים לפי אותם כללים.

מפרידים בין דוח משתמשים אמיתיים לבדיקה מבוקרת

נתוני שטח מתארים ביקורים שנרשמו. נתוני מעבדה מתארים בדיקה מבוקרת. שניהם מועילים, אך עונים על שאלות שונות.

Chrome User Experience Report, או CrUX, מאגד חוויות שימוש ב-Chrome שעומדות בתנאי האיסוף. ה-API מציג חלון איסוף מתגלגל של 28 ימים. PageSpeed Insights משתמש ב-CrUX באזור המשתמשים האמיתיים, ואילו באזור המעבדה הוא מריץ Lighthouse בתנאים מוגדרים. שתי התוצאות יכולות להיות שונות בצדק.

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

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

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

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

בוחרים את הדוח שמתאים לשאלה

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

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

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

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

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

מאבחנים LCP איטי באמצעות מעקב אחר המשאב

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

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

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

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

<img
  src="/images/article-hero-960.webp"
  srcset="/images/article-hero-960.webp 960w,
          /images/article-hero-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A request moving from a browser to a server"
>

ההיעדר של loading="lazy" מכוון. fetchpriority הוא רמז לתזמון, לא פקודה שמבטלת כל החלטה של הדפדפן. יש לשמור אותו למשאבים חשובים באמת, ולא לתת עדיפות גבוהה לגלריה שלמה.

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

מאבחנים INP גרוע באמצעות שחזור פעולה אמיתית

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

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

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

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

בדיקת ניווט רגילה ב-Lighthouse משתמשת ב-Total Blocking Time כסימן מעבדתי מועיל לחסימת זרם הביצוע הראשי. TBT אינו INP, ואין להזין אותו בשדה INP של כלי בדיקה. הקלטות אינטראקטיביות מבוקרות יכולות למדוד השהיית פעולה; המגבלה היא של בדיקת טעינה בלבד, לא של כל מדידת מעבדה.

מאבחנים CLS באמצעות מציאת הגורם לתזוזה

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

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

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

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

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

בונים שגרת מדידה קטנה שאפשר לחזור עליה

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

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

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

import { onCLS, onINP, onLCP } from 'web-vitals';

function logMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id
  });
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

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

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

מציבים את Core Web Vitals בהקשר הנכון של SEO

Google Search Central מסבירה שמערכות הדירוג שלה משתמשות ב-Core Web Vitals, אך שתוצאות טובות בדוחות אינן מבטיחות דירוג גבוה. רלוונטיות, תוכן מועיל והיבטים נוספים של חוויית הדף עדיין חשובים. אין יחס המרה מתועד בין עלייה בציון Lighthouse לבין עלייה במיקומים.

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

הופכים את הממצא הראשון לשינוי מוגדר

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

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