המאמר מיועד לבעלי אתרים ולמנהלי חנויות שקיבלו התראה ב-Search Console, ראו ציון נמוך ב-PageSpeed Insights, או פשוט מרגישים שהאתר איטי. הוא מסביר מה שלושת המדדים בודקים, איך לקרוא את הנתונים בלי להיבהל מציון אחד, ואילו תיקונים פותרים בדרך כלל את הבעיות. בסופו תדעו איפה לבדוק, מה לתעדף, ומה לבקש מהמפתח או מחברת האחסון.
שלושת המדדים, והספים של Google
Core Web Vitals הם שלושה מדדים שמודדים את חוויית הטעינה והשימוש בעמוד, כפי שמשתמשים אמיתיים חווים אותה:
| מדד | מה הוא בודק | טוב | דורש שיפור | גרוע |
|---|---|---|---|---|
| LCP | כמה זמן עד שהאלמנט הגדול ביותר בתצוגה, לרוב תמונה או כותרת, מוצג | עד 2.5 שניות | עד 4 שניות | מעל 4 שניות |
| INP | כמה מהר העמוד מגיב לפעולות כמו לחיצה או הקלדה, לאורך כל הביקור | עד 200 מ"ש | עד 500 מ"ש | מעל 500 מ"ש |
| CLS | כמה תוכן זז ממקומו בלי שהגולש ביקש | עד 0.1 | עד 0.25 | מעל 0.25 |
הסטטוס נקבע לפי האחוזון ה-75 של הביקורים. כלומר, כדי שעמוד ייחשב "טוב", לפחות 75% מהביקורים צריכים לעמוד בסף. ב-2024 החליף INP את המדד הקודם FID, ולכן מדריכים ישנים שמזכירים FID ו-100 מ"ש אינם מעודכנים.
כמה זה משפיע על הדירוג
לפי Google, חוויית עמוד טובה, כולל Core Web Vitals, תואמת למה שמערכות הדירוג שלה מבקשות לתגמל. אבל Google גם כותבת שציונים טובים לא מבטיחים מקום בראש התוצאות, ושהיא תציג את התוכן הרלוונטי ביותר גם כשחוויית העמוד שלו לא מושלמת. בפועל, מהירות חשובה לפני הכול לגולשים: עמוד שנטען לאט או קופץ בזמן לחיצה מתסכל ופוגע בפניות ובמכירות. השיקול הזה מספיק כדי לטפל בבעיה, גם בלי להבטיח שינוי בדירוג.
איפה בודקים: נתוני שטח מול בדיקת מעבדה
- דוח Core Web Vitals ב-Search Console: מבוסס על נתוני שימוש אמיתיים מדפדפני Chrome (CrUX). הוא מקבץ עמודים דומים, ומציג רק עמודים או קבוצות שיש עליהם מספיק נתונים. באתר קטן ייתכן שתראו רק נתון לאתר כולו, או "אין מספיק נתונים".
- PageSpeed Insights: מציג בראש העמוד נתוני שטח מ-CrUX, אם יש מספיק תנועה, ומתחתם בדיקת מעבדה של Lighthouse. הציון מ-0 עד 100 שייך לבדיקת המעבדה בלבד.
- בדיקת מעבדה (Lighthouse): בדיקה אחת, במכשיר ובחיבור מדומים. היא שימושית לאיתור הסיבה לבעיה, אבל התוצאה משתנה מבדיקה לבדיקה ואינה מה ש-Google משתמשת בו לדוחות.
סדר העדיפויות: קודם נתוני השטח, כי הם משקפים את הגולשים שלכם. ציון מעבדה נמוך כשנתוני השטח תקינים אינו סיבה לפרויקט שיפור דחוף.
תיקונים נפוצים, לפי מדד
LCP איטי
- תמונה ראשית כבדה: הקטינו לגודל התצוגה האמיתי, השתמשו ב-WebP או AVIF, ואל תטענו בטעינה עצלה (lazy) את התמונה שמופיעה בראש העמוד.
- שרת איטי: זמן תגובה ראשוני ארוך מעיד לרוב על אחסון חלש או על חוסר במטמון עמודים. מטמון בצד השרת או CDN פותרים חלק גדול מהבעיה.
- גופנים וקובצי CSS שחוסמים תצוגה: טענו רק את המשקלים הנחוצים של הגופן, ומחקו CSS שאינו בשימוש.
INP גבוה
- יותר מדי JavaScript: תוספים, וידג'טים של צ'אט, כלי מעקב וסקריפטים של צד שלישי מעמיסים על הדפדפן. בדקו מה באמת נחוץ, ודחו טעינה של מה שלא נחוץ מיד.
- בוני עמודים כבדים: עמודים עם רכיבים מקוננים רבים מאטים תגובה, במיוחד בטלפונים חלשים.
CLS גבוה
- תמונות ווידאו בלי מידות: הגדירו רוחב וגובה, או יחס תצוגה, כדי שהדפדפן ישמור להם מקום.
- באנרים, הודעות עוגיות ופרסומות שנכנסים מעל התוכן: שמרו להם מקום מראש, או הציגו אותם כשכבה שלא דוחפת תוכן.
- גופנים שמתחלפים בזמן טעינה: הבדל גדול בין הגופן הזמני לגופן הסופי מזיז שורות.
דוגמה בדיונית: בחנות וורדפרס, דוח Search Console מסמן את קבוצת עמודי המוצר כ"דורש שיפור" ב-LCP. בבדיקה מתברר שתמונת המוצר הראשית מוצגת בגודל 600 פיקסלים, אבל נטענת בקובץ של 3,000 פיקסלים ובטעינה עצלה. הקטנה, המרה ל-WebP וביטול הטעינה העצלה לתמונה הראשונה פותרים את רוב הבעיה בלי לגעת בעיצוב.
לפני שמתקינים "תוסף מהירות"
תוספי מטמון ואופטימיזציה מועילים, אבל הם לא מתקנים בעיה בסיסית כמו אחסון חלש, תמונות ענקיות או עשרות תוספים. התקנה של כמה תוספי אופטימיזציה במקביל עלולה גם לשבור עיצוב או טפסים. עדיף לתקן קודם את המקור, להוסיף תוסף אחד, ולבדוק את האתר אחרי כל שינוי, כולל טפסים, עגלה ותשלום.
הצעד הבא
פתחו את דוח Core Web Vitals ב-Search Console, בנפרד לנייד ולמחשב. רשמו אילו קבוצות עמודים מסומנות, באיזה מדד, וכמה עמודים הן כוללות. התחילו מהקבוצה הגדולה ביותר במדד הגרוע ביותר, ובדקו עמוד מייצג ממנה ב-PageSpeed Insights כדי להבין את הסיבה. לבדיקה טכנית מקיפה כחלק מעבודה על האתר כולו, אפשר להיעזר בליווי בקידום אורגני.
מקורות
- Google Search Central: Understanding Core Web Vitals and Google search results
- Google Search Central: Page experience
- Search Console Help: Core Web Vitals report
- web.dev: Interaction to Next Paint (INP)
- PageSpeed Insights
שאלות ותשובות
ibastom.com
למה הציון ב־PageSpeed משתנה בכל בדיקה?
כי זו בדיקת מעבדה בודדת שמושפעת מעומס השרת, מהרשת ומסקריפטים חיצוניים. כדי לראות מגמה מסתכלים על נתוני השטח לאורך זמן, או מריצים כמה בדיקות ומשווים.
כמה זמן עד שתיקון יופיע ב־Search Console?
נתוני השטח מצטברים לאורך 28 ימים, ולכן שיפור נראה בדוח בהדרגה ולא מיד. בדוח עצמו אפשר לסמן שהבעיה תוקנה ולבקש אימות.
להחליף תבנית או בונה עמודים?
לא כצעד ראשון. קודם מזהים מה גורם לבעיה בעמודים הספציפיים. החלפת תבנית היא פרויקט עם סיכונים משלו, והיא מוצדקת רק כשהבעיה נובעת מהתבנית ואי אפשר לפתור אותה אחרת.
אין לאתר נתוני שטח בכלל. מה עושים?
באתר עם תנועה נמוכה Google לא תמיד אוספת מספיק נתונים לדוח. במקרה כזה נשענים על בדיקות מעבדה של העמודים החשובים, בודקים במכשיר נייד אמיתי ומתקנים את מה שבולט: תמונות כבדות, סקריפטים חוסמים ותזוזות של פריסה.
מה מעדיפים לתקן קודם?
את העמודים שמביאים הכי הרבה תנועה ופניות, ובהם את המדד שנכשל בנתוני השטח. שיפור של עמוד הבית ושל דפי השירות המרכזיים חשוב יותר משיפור ציון של עמוד שאיש לא מבקר בו.
