Core Web Vitals הם שלושה מדדים שגוגל מודדת אצל גולשים אמיתיים: כמה מהר התוכן הראשי נטען (LCP), כמה מהר האתר מגיב ללחיצה (INP), וכמה יציב העמוד נראה בזמן הטעינה (CLS). כדי לעבור, שלושת המדדים צריכים להיות בטווח הטוב ב-75% מהביקורים: LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1.
גוגל מציינת שהמדדים האלה מתיישבים עם מה שמערכות הדירוג שלה מנסות לתגמל, ולכן הם חלק מהבדיקה הטכנית של כל אתר. בהמשך תמצאו מה כל מדד מודד, מה הסיבות הנפוצות לציון נמוך, ואיך מתקנים אותן בסדר הגיוני.
מהם הספים של שלושת המדדים?
לכל מדד יש שלושה טווחים: טוב, טעון שיפור וגרוע. גוגל בודקת אותם ברמת האחוזון ה-75 של הביקורים, כלומר שלושה מכל ארבעה גולשים צריכים לקבל חוויה בטווח הטוב, ובמדידה נפרדת למובייל ולדסקטופ.
| מדד | מה הוא מודד | טוב | טעון שיפור | גרוע |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | זמן הטעינה של האלמנט הגדול ביותר במסך הראשון | עד 2.5 שניות | 2.5 עד 4 שניות | מעל 4 שניות |
| INP (Interaction to Next Paint) | הזמן מרגע לחיצה, הקשה או נגיעה ועד שהמסך מתעדכן | עד 200 מילישניות | 200 עד 500 מילישניות | מעל 500 מילישניות |
| CLS (Cumulative Layout Shift) | כמה אלמנטים קופצים ממקומם בזמן שהעמוד נטען | עד 0.1 | 0.1 עד 0.25 | מעל 0.25 |
מדד INP הוא המדד העדכני לתגובתיות. הוא הפך למדד יציב ב-2024 ותפס את המקום של FID, מדד ישן שבדק רק את העיכוב בלחיצה הראשונה.
מה מודד LCP ואיך משפרים אותו?
LCP מודד את הרגע שבו האלמנט הגדול ביותר בחלק הנראה של העמוד מוצג, בדרך כלל תמונה ראשית, וידאו או בלוק טקסט גדול. כדי לשפר אותו כדאי לפרק את הזמן לארבעה חלקים ולמצוא איפה הוא אבד.
לפי המדריך של Google, כ-40% מהזמן אמורים להיות טעינת מסמך ה-HTML, כ-40% טעינת המשאב עצמו, ופחות מ-10% כל אחד מהחלקים האחרים: ההמתנה עד שהדפדפן מתחיל להוריד את המשאב, וההמתנה עד שהאלמנט מצויר.
- שרת איטי: קיצור הפניות מיותרות, שימוש ב-CDN וקאשינג של עמודים מקצרים את הזמן עד הבייט הראשון.
- תמונה ראשית כבדה: דחיסה, פורמט מודרני וגודל שמתאים לתצוגה מקטינים את זמן ההורדה.
- גילוי מאוחר של התמונה: התמונה הראשית צריכה להופיע ישירות ב-HTML, עם fetchpriority=high, ולא להיטען מאוחר בעזרת סקריפט.
- Lazy loading על התמונה הלא נכונה: אסור להוסיף loading=lazy לתמונה שמופיעה במסך הראשון, כי זה מעכב אותה בדיוק כשצריך אותה.
- חסימת רינדור: קבצי CSS וסקריפטים סינכרוניים כבדים מעכבים את הציור גם אחרי שהתמונה כבר ירדה.
מה מודד INP ואיך משפרים אותו?
INP בודק כמה זמן עובר מרגע שגולש לוחץ, נוגע או מקליד ועד שהדפדפן מצייר את התגובה הבאה. גלילה, ריחוף וזום לא נספרים, והמדד מתייחס לאחת האינטראקציות האיטיות ביותר בביקור.
הזמן מורכב משלושה חלקים: עיכוב לפני שהקוד מתחיל לרוץ, זמן הריצה של הקוד, והזמן עד שהמסך מתעדכן. כמעט תמיד הבעיה היא ג'אווה סקריפט שתוקע את התהליך הראשי של הדפדפן.
- לפרק משימות ארוכות: פעולה כבדה אחת אפשר לחלק למשימות קטנות, כך שהדפדפן מספיק להגיב בין לבין.
- לדחות עבודה לא דחופה: אנליטיקס, שמירת נתונים ובדיקות רקע יכולים לרוץ אחרי שהמסך התעדכן.
- להקטין את ה-DOM: עמוד עם אלפי אלמנטים דורש יותר עבודת רינדור אחרי כל לחיצה.
- לצמצם סקריפטים של צד שלישי: צ'אטים, פיקסלים ותוספי וורדפרס מיותרים מוסיפים קוד שרץ על אותו תהליך.
מה מודד CLS ואיך משפרים אותו?
CLS מודד קפיצות פתאומיות של תוכן בזמן שהעמוד נטען, למשל כפתור שזז ברגע שאתם מנסים ללחוץ עליו. הציון מחושב לפי שטח המסך שהאלמנט הזז תופס ולפי המרחק שבו הוא זז, ושינויי פריסה שקורים עד 500 מילישניות אחרי לחיצה או הקשה לא נספרים.
רוב הקפיצות מגיעות מארבעה מקורות, ולכל אחד תיקון ברור:
- תמונות בלי מידות: הגדירו width ו-height או aspect-ratio, כדי שהדפדפן ישמור מקום מראש.
- פרסומות, וידאו מוטמע וווידג'טים: שמרו להם מקום קבוע בעזרת min-height או aspect-ratio.
- פונטים: החלפה בין פונט זמני לפונט האתר משנה את גודל הטקסט. אפשר להשתמש ב-font-display ובפונט חלופי דומה בגודלו.
- באנרים שנדחפים לתוך העמוד: הודעת עוגיות או פס מבצע שמופיעים מעל התוכן אחרי הטעינה דוחפים אותו למטה. עדיף להציג אותם באזור שמור מראש או מעל הקיפול.
- אנימציות: עדיף להשתמש ב-transform במקום להזיז אלמנטים בעזרת top ו-left.
איך בודקים את Core Web Vitals של האתר?
הבדיקה המדויקת ביותר מתבססת על נתוני שטח, כלומר מדידות של גולשים אמיתיים, ולא על בדיקה חד-פעמית במחשב שלכם. הדוח של Core Web Vitals ב-Google Search Console מציג בדיוק את זה, על בסיס נתוני Chrome UX Report.
הדוח מקבץ כתובות דומות לקבוצות ונותן לכל קבוצה את הסטטוס של המדד החלש ביותר שלה. הנתונים נבדקים בחלון של 28 יום, ולכן אחרי תיקון צריך לחכות כמה שבועות לפני שרואים אותו מתבטא בדוח. אם לאתר קטן אין מספיק גולשים, הדוח עלול להישאר ריק. מדריך ההתחלה שלנו על Google Search Console מסביר איך מחברים את האתר וקוראים את הדוחות.
| סוג נתונים | מקור | למה משמש |
|---|---|---|
| נתוני שטח | גולשים אמיתיים (CrUX), דוח Search Console | לדעת איך האתר באמת מרגיש לגולשים ולעקוב אחרי שיפור לאורך זמן |
| נתוני מעבדה | בדיקה סימולטיבית בכלי כמו Lighthouse או PageSpeed Insights | לאתר סיבה לבעיה ולבדוק תיקון מיד, בלי לחכות לגולשים |
האם Core Web Vitals משפיעים על דירוג בגוגל?
כן, גוגל כוללת אותם בין האותות של חוויית העמוד וממליצה לבעלי אתרים לשאוף למדדים טובים. עם זאת, הם לא מחליפים תוכן רלוונטי ואמין: עמוד מהיר שלא עונה על השאלה של הגולש לא יגיע גבוה רק בגלל הציון.
בפועל כדאי לראות בהם שני יתרונות: הם מסננים בעיות טכניות שמפריעות לגולשים, והם משפרים את חוויית הגלישה של הגולשים, גם בנייד. על ההיבט הזה כתבנו גם במאמר על אתר מותאם למובייל ובעמוד על חוויית משתמש וקידום אתרים.
באיזה סדר מתקנים?
מתחילים מהמדד שנכשל בדוח, ובתוכו מהעמודים או מסוג העמודים שמביאים הכי הרבה כניסות. תיקון תבנית אחת, כמו תבנית מאמר או דף מוצר, משפר בבת אחת מאות כתובות.
- פתחו את הדוח ב-Search Console וזהו אילו קבוצות כתובות מסומנות כגרועות או טעונות שיפור, ובאיזה מדד.
- בדקו עמוד מייצג מהקבוצה בכלי מעבדה ומצאו את האלמנט הגדול, את הסקריפט הכבד או את האלמנט שקופץ.
- תקנו גורם אחד בכל פעם ובדקו שוב, כדי לדעת מה באמת עבד.
- בצעו אימות תיקון בדוח וחכו לחלון המעקב של 28 יום.
את הבדיקה הזו כדאי לשלב בצ׳קליסט ל-SEO טכני, לצד בדיקות אינדוקס, מפת אתר ומבנה כתובות.
מהן הטעויות הנפוצות בתיקון Core Web Vitals?
הטעות הנפוצה ביותר היא לרדוף אחרי ציון של 100 בכלי מעבדה ולהתעלם מנתוני השטח. הטעויות הבאות חוזרות שוב ושוב:
- לבדוק רק בדסקטופ, כשרוב הגולשים מגיעים מהנייד והמדידה נפרדת.
- להתקין עוד תוסף אופטימיזציה על כל בעיה, ובכך להוסיף סקריפטים שפוגעים ב-INP.
- להוסיף loading=lazy לכל התמונות, כולל התמונה הראשית.
- לצפות לשינוי בדוח כבר למחרת, למרות חלון המדידה של 28 יום.
- לתקן עמוד אחד במקום את התבנית שמשותפת לכל קבוצת העמודים.
שאלות נפוצות
מה זה Core Web Vitals?
שלושה מדדים של גוגל שמודדים חוויית גלישה אמיתית: LCP לטעינה, INP לתגובתיות ו-CLS ליציבות חזותית. כדי לעבור צריך להיות בטווח הטוב ב-75% מהביקורים.
מהם הערכים הטובים של LCP, INP ו-CLS?
LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1. מעל 4 שניות, 500 מילישניות ו-0.25 בהתאמה המדד נחשב גרוע.
איפה רואים את Core Web Vitals של האתר?
בדוח Core Web Vitals ב-Google Search Console, שמבוסס על נתוני גולשים אמיתיים מ-Chrome UX Report. לבדיקה מיידית של תיקון אפשר להשתמש בכלי מעבדה כמו Lighthouse.
מה ההבדל בין INP ל-FID?
FID בדק רק את העיכוב בהתחלת האינטראקציה הראשונה. INP בודק את כל משך התגובה באינטראקציות לאורך הביקור, והוא הפך למדד היציב ב-2024 במקום FID.
כמה זמן לוקח לראות שיפור בדוח אחרי תיקון?
הנתונים בדוח נאספים בחלון של 28 יום, ולכן שיפור מלא מתבטא רק אחרי כארבעה שבועות מהתיקון.
מקורות
- web.dev: Core Web Vitals
- Google Search Central: Understanding Core Web Vitals and Google Search results
- Search Console Help: Core Web Vitals report
- web.dev: Largest Contentful Paint (LCP)
- web.dev: Optimize Largest Contentful Paint
- web.dev: Interaction to Next Paint (INP)
- web.dev: Optimize Interaction to Next Paint
- web.dev: Cumulative Layout Shift (CLS)
- web.dev: Optimize Cumulative Layout Shift
