מה זה Core Web Vitals, ואיך LCP, INP ו-CLS משפיעים על הדירוג שלכם?

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

תוכן העניינים 8 פרקים ▾

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

שלושת המדדים מתארים שלושה שלבים שונים בחוויה של גולש יחיד: הטעינה, התגובה והיציבות. LCP מודד טעינה, INP מודד תגובתיות, CLS מודד יציבות ויזואלית. שלושתם לא נמדדים במעבדה. הם נאספים מגולשים אמיתיים שגלשו בכרום ואישרו שיתוף נתוני שימוש, והנתון הזה נקרא field data. הוא מה שמזין את הדוח ב-Search Console.

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

עוד דבר ששווה לדעת, כי הרבה מדריכים בעברית עדיין לא התעדכנו: המדד האמצעי התחלף. עד מרץ 2024 גוגל מדדה FID, שבדק רק את ההשהיה של האינטראקציה הראשונה בעמוד. INP החליף אותו לחלוטין, והוא מחמיר בהרבה.

LCP: כמה זמן עובר עד שרואים משהו אמיתי

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

מה מקלקל LCP בפועל, לפי הסדר שבו אני נתקל בזה אצל לקוחות:

• תמונת כותרת ענקית שהועלתה במידות המקוריות של המצלמה ולא הומרה לפורמט מודרני.
• lazy loading שהוחל על תמונת הכותרת עצמה. זו טעות נפוצה מאוד: התוסף מעכב בכוונה בדיוק את התמונה שהמדד מודד.
• תגובת שרת איטית, מה שנקרא TTFB. אם השרת מתחיל לענות רק אחרי שנייה וחצי, שום אופטימיזציה בצד הדפדפן לא תציל.
• קבצי CSS ו-JS שחוסמים רינדור ונטענים לפני שמשהו בכלל מוצג על המסך.
• גופנים חיצוניים שהטקסט ממתין להם במקום להופיע מיד.

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

INP: כמה זמן העמוד לא מגיב אחרי שנוגעים בו

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

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

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

CLS: כשהעמוד קופץ מתחת לאצבע

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

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

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

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

טבלת הספים: מתי אתם Good ומתי Poor

אלה הספים שגוגל פרסמה, והם זהים לכל אתר בלי קשר לתחום, לגודל או לשפה:

מדד	מה נמדד	Good	Needs improvement	Poor
LCP	זמן עד ציור האלמנט הגדול ביותר בחלון הצפייה	עד 2.5 שניות	בין 2.5 ל-4 שניות	מעל 4 שניות
INP	השהיה מנגיעה ועד התגובה החזותית	עד 200 מילישניות	בין 200 ל-500 מילישניות	מעל 500 מילישניות
CLS	ציון הזזות פריסה, ללא יחידות	עד 0.1	בין 0.1 ל-0.25	מעל 0.25

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

למה PageSpeed מראה 95 ו-Search Console מראה אדום

זו השאלה שאני מקבל הכי הרבה, והתשובה פשוטה ממה שנדמה. מדובר בשני סוגי נתונים שונים לגמרי. נתוני מעבדה, lab data, הם טעינה מדומה אחת שהכלי מריץ ברגע זה, ממכונה חזקה, בתנאים סטריליים. נתוני שדה, field data, הם מה שקרה בפועל לגולשים שלכם ב-28 הימים האחרונים, על מכשירים אמיתיים וברשת סלולרית אמיתית.

הציון הגדול והצבעוני בראש דוח PageSpeed הוא ציון מעבדה. הדוח ב-Search Console מבוסס אך ורק על נתוני שדה. לכן אתר שנבדק ממחשב במשרד עם חיבור מהיר יכול להחזיר 95, בזמן שהגולשים האמיתיים, שחלקם על מכשיר בן ארבע שנים ברשת עמוסה בשעת ערב, חווים משהו אחר לגמרי. INP בכלל לא ניתן למדידה אמיתית במעבדה, כי בבדיקה אוטומטית אף אחד לא נוגע במסך.

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

כמה זה באמת משפיע על הדירוג

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

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

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

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

הסדר חשוב, כי הוא קובע כמה תראו מוקדם ובאיזו השקעה:

1. CLS קודם. הזול והמהיר ביותר. הגדרת מידות לתמונות, שריון מקום לבאנרים ולהטמעות, טיפול בהחלפת הגופן.
2. תמונת ה-LCP. המרה לפורמט מודרני, גודל נכון, הסרת lazy מהתמונה הראשית, preload.
3. זמן תגובת השרת. מטמון, גרסה עדכנית של PHP, ולעיתים מעבר לאחסון אחר.
4. דיאטת JavaScript עבור INP. כאן מחליטים מאילו תוספים ומאילו סקריפטים חיצוניים מוותרים.
5. אימות ב-Search Console והמתנה. לוחצים Validate fix, ומחכים שהחלון של 28 הימים יתחלף. בלי הצעד הזה אין דרך לדעת אם התיקון עבד על גולשים אמיתיים.

הטיפול המלא, מזיהוי התבניות ועד ה-re-test והמעקב אחרי 30 יום, נמצא בעמוד Core Web Vitals ותיקון LCP, INP ו-CLS ועולה ₪1,200-₪2,800 חד-פעמי לפני מע״מ, לפי גודל האתר ומספר התבניות. מתי זה לא מתאים? אם האתר עומד להיבנות מחדש בחודשים הקרובים, חבל לשלם על אופטימיזציה לתבנית שתיזרק. ואם האתר מקבל מעט מאוד מבקרים, אין בכלל נתוני שדה לעבוד איתם, ועדיף להשקיע קודם בתוכן. מי שרוצה שהבדיקה הזו תרוץ באופן קבוע ולא פעם אחת, אודיט SEO טכני מתעדכן עולה ₪400-₪1,800 חודשי לפני מע״מ וכולל גם crawl errors, canonicals, sitemap ו-schema.

אני ארתור קלנדרוב, מנהל את עבודת הקידום וההפקה בשיווקנט, עם 23 שנים בשיווק. אם יש לכם דוח אדום ב-Search Console ואתם לא בטוחים אם זה שווה טיפול או שזה רעש, שלחו לי צילום מסך של הדוח ואת כתובת האתר, ואגיד לכם בכנות מה הייתי מתקן ראשון וכמה זה אמור לקחת. אפשר גם להתחיל מהתמונה הרחבה בעמוד קידום אורגני בגוגל וב-AI, שמתחיל ב-₪1,500 חודשי לפני מע״מ. הכי מהיר להשיג אותי בטלפון 054-238-3789 או בWhatsApp. דברו איתי בוואטסאפ ←