Core Web Vitals הם שלושה מספרים שגוגל מודדת על כל עמוד, מהדפדפנים של גולשים אמיתיים, ומשתמשת בהם בין השאר כאות דירוג. אפשר להתווכח על המשקל שלהם בדירוג; קשה להתווכח עם זה שהם מודדים דברים שקוראים מרגישים: כמה זמן עד שרואים משהו, כמה מהר העמוד מגיב ללחיצה, וכמה הוא קופץ בזמן הטעינה.
המדדים והספים
| מדד | מה הוא מודד | ״טוב״ | ״דורש שיפור״ | ״גרוע״ |
|---|---|---|---|---|
| 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 |
הכלל המשלים חשוב לא פחות: הסף נבדק על אחוזון ה-75 של הטעינות, בנפרד למובייל ולדסקטופ. כלומר, לא מספיק שהממוצע טוב; שלושה רבעים מהביקורים צריכים לעמוד בסף. עמוד שמהיר למרבית הגולשים אך איטי מאוד לרבע מהם ייכשל.
מעבדה מול שדה: למה המספרים לא מסכימים
יש שני סוגי נתונים, והם עונים על שאלות שונות.
נתוני שדה (field data) מגיעים מדפדפני Chrome של גולשים אמיתיים ונאספים ב-Chrome UX Report. זה מה שגוגל משתמשת בו, וזה מה שמוצג ב-Search Console תחת ״Core Web Vitals״ וב-PageSpeed Insights בחלק העליון. הם משקפים מכשירים חלשים, רשתות איטיות ותוכן שנטען אחרי גלילה. החיסרון: צריך מספיק תנועה כדי שיהיו נתונים, ויש עיכוב של ימים.
נתוני מעבדה (lab data) מגיעים מבדיקה אחת, במכשיר מדומה, ברשת מדומה. Lighthouse ו-PageSpeed Insights בחלק התחתון מציגים אותם. הם טובים לאבחון: אפשר לראות בדיוק איזה קובץ עיכב את ה-LCP. אבל INP לא ניתן למדידה אמיתית במעבדה, כי אין שם משתמש שלוחץ. כשהמעבדה אומרת ״טוב״ והשדה אומר ״גרוע״, השדה צודק מבחינת הדירוג, והמעבדה עוזרת להבין למה.
LCP: מה בדרך כלל אשם
ברוב האתרים האלמנט הגדול הוא תמונת כותרת או בלוק טקסט ראשי. הבעיות החוזרות:
- התמונה הראשית נטענת ב-
loading="lazy". טעינה עצלה טובה לתמונות מתחת לקפל, והרסנית לתמונת ה-LCP. לתמונה הראשונה כדאי להוסיףfetchpriority="high". - זמן תגובה של השרת (TTFB) ארוך. אם ה-HTML עצמו מגיע אחרי שנייה וחצי, שום אופטימיזציה בצד הדפדפן לא תציל את ה-LCP. כאן נכנסים מטמון בשרת, CDN, ובסיס נתונים שלא מבצע שאילתות מיותרות.
- CSS חוסם: קובץ CSS גדול שחייב להיטען לפני הציור הראשון. פתרון: לצמצם, לפצל, ולדאוג שהגופנים עם
font-display: swap.
INP: המדד שהחליף את FID
INP החליף את FID במרץ 2024, והוא קשוח יותר: הוא לא מודד רק את הלחיצה הראשונה אלא את האיטית ביותר (בקירוב) לאורך הביקור. הגורם השכיח הוא JavaScript שרץ זמן רב על ה-thread הראשי: סקריפטי מעקב, ווידג'טים של צד שלישי, או קוד שמעבד הרבה DOM בלחיצה אחת. הדרך לאבחן היא לשונית Performance ב-DevTools עם הקלטה של אינטראקציה; מחפשים משימות ארוכות (מעל 50 אלפיות שנייה) סביב הלחיצה.
מה שעוזר: לפצל עבודה ארוכה, לדחות סקריפטים שלא דרושים לאינטראקציה, ולהסיר מה שלא חיוני. אתר שטוען כלי מדידה רק אחרי הסכמת המשתמש, כמו האתר הזה, מרוויח כאן בלי להתכוון.
CLS: קפיצות בטעינה
הסיבות הנפוצות: תמונות בלי width ו-height (הדפדפן לא יודע כמה מקום לשמור), באנרים או הודעות הסכמה שנדחפים לראש העמוד אחרי שהתוכן כבר מוצג, וגופנים שמתחלפים ומשנים את גובה השורות. לרוב התיקון פשוט: מידות לכל תמונה, מקום שמור לכל רכיב שמגיע מאוחר, והודעות שצפות מעל התוכן במקום לדחוף אותו.
סדר עבודה מומלץ
- פתחו את דוח Core Web Vitals ב-Search Console. הוא מקבץ עמודים לפי בעיה. התחילו מהקבוצה עם הכי הרבה עמודים, לא מהעמוד הראשי.
- לכל קבוצה, הריצו PageSpeed Insights על עמוד מייצג וקראו את החלק התחתון (המעבדה) כדי להבין את הסיבה.
- תקנו דבר אחד, חכו שבוע-שבועיים עד שנתוני השדה מתעדכנים, ובדקו שוב. תיקונים מקבילים מקשים לדעת מה עזר.
וכלל אחרון: הספים הם יעד הנדסי, לא תעודה. עמוד שעובר את שלושתם לא בהכרח מהיר לכל קורא, ועמוד שנכשל ב-CLS ב-0.12 לא ״שבור״. המדדים שימושיים כשמשתמשים בהם כדי למצוא מה כואב למשתמשים, לא כדי לצבוע תיבה בירוק.
