מה זה Core Web Vitals ואיך עוברים את הספים של גוגל

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

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

מה זה Core Web Vitals?

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

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

איך גוגל מודדת את המדדים?

שלושה פרטים בשיטת המדידה מסבירים את רוב הבלבול סביב ציוני מהירות.

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

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

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

שלושת המדדים מקרוב

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

LCP, מהירות הטעינה

Largest Contentful Paint מודד תוך כמה זמן מופיע האלמנט הגדול ביותר בחלק הנראה של העמוד, לרוב תמונת השער או הכותרת. ירוק עד 2.5 שניות, אדום מעל 4. מה שמקלקל, שרת שמגיב לאט, תמונות ענק לא מכווצות, קוד שחוסם את הרינדור, ולפעמים טעינה עצלה שהוחלה בטעות על תמונת השער עצמה. מה שמתקן, פורמט תמונות מודרני (WebP או AVIF) במידות אמיתיות, טעינה מוקדמת של תמונת ה-LCP, שרת מהיר או CDN, ודחיית קוד לא קריטי. מהניסיון שלי זה המדד שהכי קל להזיז בו הרבה, כי האשם לרוב בולט.

INP, מהירות התגובה

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

CLS, יציבות ויזואלית

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

תוכנית עבודה לשלושה ירוקים

1. מדדו נכון. דוח Core Web Vitals ב-Search Console לתמונה הרחבה של כל האתר, PageSpeed Insights לעמודי הכסף. נתוני שטח, במובייל.
2. קודם האדומים. מדד בטווח האדום פוגע במשתמשים עכשיו. מדד ירוק לא נוגעים בו, גם אם הציון הכללי מפתה לשפר עוד.
3. תקנו ברמת התבנית קודם. תיקון בתבנית או בשרת משפיע על כל העמודים בבת אחת. רק אחרי זה יורדים לתיקונים פרטניים לעמודים בודדים.
4. חכו ומדדו שוב. נתוני השטח מתחלפים על פני 28 יום. סבלנות, ואז סבב שיפור נוסף לפי הדוח המעודכן.

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

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

כמה זה משפיע על הדירוג?

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

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

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

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

בשורה התחתונה

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

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