Core Web Vitals: עברו את בדיקת המהירות של Google

בשנת 2021, Google הודיעה כי Core Web Vitals הם גורמי דירוג. שלושה מדדים ספציפיים משפיעים כעת ישירות על דירוגי החיפוש שלכם: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), ו-Interaction to Next Paint (INP). לאתרים עם מדדים חלשים סיכוי נמוך יותר לדרג היטב. לאתרים עם מדדים מצוינים יש יתרון בדירוג. עבור SEO מודרני, עמידה ב-Core Web Vitals אינה עניין למשא ומתן.

ההשלכות מרחיקות לכת. אי אפשר עוד להתעלם מהביצועים. אי אפשר לבנות אתר איטי ולקוות לדירוגים טובים. Google הבהירה שחוויית המשתמש חשובה, ו-Core Web Vitals מכמתים את חוויית המשתמש. אופטימיזציה של Core Web Vitals אינה עוד אופציונלית; היא הכרחית לנוכחות תחרותית בחיפוש.

מהם Core Web Vitals ומדוע הם חשובים

Core Web Vitals מודדים שלושה ממדים של חוויית משתמש: מהירות טעינה (LCP), יציבות חזותית (CLS), ותגובתיות (INP). דף ה-Web Vitals של Google מגדיר כל מדד בפירוט. שלושת המדדים הללו מייצגים את ההיבטים החשובים ביותר של האופן שבו משתמשים חווים את האתר שלכם.

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

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

Largest Contentful Paint (LCP): מדידת מהירות הטעינה

Largest Contentful Paint (LCP) מודד כמה זמן לוקח לאלמנט התוכן הגדול ביותר בדף להיות גלוי למשתמש. זה יכול להיות תמונה, סרטון, כותרת או בלוק טקסט. LCP מודד את הרגע שבו המשתמש יכול לראות את התוכן העיקרי ולחוש שהדף נטען.

ההמלצה של Google: LCP צריך להיות מתחת ל-2.5 שניות. דפים עם LCP מתחת ל-2.5 שניות נחשבים "טובים". דפים עם LCP בין 2.5-4 שניות "דורשים שיפור". דפים עם LCP מעל 4 שניות הם "גרועים". משתמשים שחווים LCP מעל 3 שניות תופסים את הדף כאיטי. משתמשים שחווים LCP מעל 4 שניות נוטשים לעיתים קרובות את הדף.

גורמים נפוצים ל-LCP איטי: זמן תגובה איטי של השרת, קוד CSS ו-JavaScript שחוסם רינדור, תמונות שאינן מותאמות, וגופנים גדולים שלוקחים זמן לטעון. תקנו את ה-LCP על ידי: שיפור מהירות השרת (הפחתת Time to First Byte / TTFB), הסרת משאבים שחוסמים רינדור, דחיית JavaScript, אופטימיזציה ודחיסה של תמונות, שימוש בפורמטים מודרניים לתמונות (WebP), וטעינה מוקדמת (preload) של משאבים קריטיים.

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

Cumulative Layout Shift (CLS): מדידת היציבות החזותית

Cumulative Layout Shift (CLS) מודד תזוזה בלתי צפויה של אלמנטים בדף בזמן טעינתו. כאשר אתם קוראים כתבה ולפתע הטקסט קופץ למטה כי מודעה נטענה מעליו, זו תזוזת פריסה (layout shift). CLS מכמת עד כמה פריסת הדף זזה במהלך הטעינה.

ההמלצה של Google: CLS צריך להיות מתחת ל-0.1. ציון CLS מתחת ל-0.1 הוא "טוב". ציונים בין 0.1-0.25 דורשים שיפור. ציונים מעל 0.25 הם "גרועים". גם תזוזות קטנות מצטברות. CLS של 0.15 משמעו שאלמנטים בדף זזו בסך הכול 15% מגובה אזור התצוגה במהלך הטעינה. משתמשים מוצאים זאת מעצבן וחווים תסכול.

גורמים נפוצים ל-CLS גבוה: מודעות שנטענות באופן אסינכרוני, תמונות ללא מאפייני width ו-height מוגדרים, הטמעות (embeds) (סרטוני YouTube, ווידג'טים של רשתות חברתיות) שנטענות באופן אסינכרוני, וגופנים שמתחלפים בפתאומיות. תקנו את ה-CLS על ידי: הגדרת מידות תמונה ב-HTML (מאפייני width ו-height), שריון מקום למודעות לפני שהן נטענות, שימוש ב-font-display: swap בקוד ה-@font-face של ה-CSS כדי למנוע קפיצת גופן, וטעינת סרטונים והטמעות באופן סינכרוני או עם מקום שמור.

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

Interaction to Next Paint (INP): מדידת התגובתיות

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

ההמלצה של Google: INP צריך להיות מתחת ל-200 אלפיות שנייה. ציונים מתחת ל-200 אלפיות שנייה הם "טובים". ציונים בין 200-500 אלפיות שנייה דורשים שיפור. ציונים מעל 500 אלפיות שנייה הם "גרועים". משתמשים מצפים לתגובה מיידית. INP של 500 אלפיות שנייה מרגיש איטי. INP של שנייה אחת מרגיש שבור.

גורמים נפוצים ל-INP חלש: JavaScript כבד שחוסם את ה-thread הראשי, סקריפטים גדולים של צד שלישי, מטפלי אירועים (event handlers) לא יעילים, וחוסר שימוש ב-request idle callback. תקנו את ה-INP על ידי: פירוק משימות JavaScript ארוכות לחלקים קטנים יותר, דחיית JavaScript שאינו קריטי, הסרת סקריפטים שאינם בשימוש, אופטימיזציה של מאזיני אירועים (event listeners), ושימוש ב-web workers עבור משימות עתירות חישוב.

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

כיצד נמדדים Core Web Vitals

Core Web Vitals נמדדים בשתי דרכים: נתוני מעבדה ונתוני שטח. נתוני מעבדה מגיעים מכלים כמו PageSpeed Insights ו-Lighthouse הפועלים בסביבה מבוקרת. נתוני שטח מגיעים ממשתמשים אמיתיים המבקרים באתר שלכם. Google מתעדפת נתוני שטח מכיוון שהם מייצגים חוויית משתמש בפועל.

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

Google Search Console מדווח על נתוני שטח של Core Web Vitals. הדוח מציג מדידות משתמשים אמיתיים המצטברות מתוך Chrome User Experience Report (CrUX). אם לאתר שלכם אין די נתוני משתמשים אמיתיים, Google מספקת במקום זאת נתוני מעבדה מ-Lighthouse.

אמות מידה וציוני מעבר

Google מגדירה Core Web Vitals "טובים" כעמידה באחוזון ה-75 של חוויית משתמש. המשמעות היא ש-75% מהמשתמשים האמיתיים חווים את האתר שלכם באותה רמה או טובה יותר מהסף. הספים הם:

LCP: 2.5 שניות או פחות. CLS: 0.1 או פחות. INP: 200 אלפיות שנייה או פחות. ספים אלה אומתו מדעית באמצעות ניתוח של טריליוני אינטראקציות אמיתיות של משתמשים. דפים בסף זה ומעלה מספקים חוויית משתמש טובה.

עם זאת, Google אינה דורשת ש-100% מהדפים שלכם יעמדו ב-Core Web Vitals. אם 75% מהדפים שלכם עוברים, האתר שלכם נחשב כבעל Core Web Vitals "טובים" באופן כללי. המשמעות היא שיכולים להיות לכם דפים איטיים יותר ועדיין לעבור, אם רוב דפי התנועה שלכם מהירים.

אופטימיזציה של כל מדד: צעדים מעשיים

לאופטימיזציית LCP: ראשית, מדדו את ה-TTFB (Time to First Byte) שלכם באמצעות PageSpeed Insights. אם ה-TTFB איטי (מעל 600 אלפיות שנייה), השרת שלכם הוא צוואר הבקבוק. שדרגו את האחסון (hosting), בצעו אופטימיזציה לקוד ה-backend, או השתמשו ברשת אספקת תוכן (Content Delivery Network / CDN). אם ה-TTFB טוב אך ה-LCP איטי, ה-CSS או ה-JavaScript שלכם חוסמים רינדור. דחו JavaScript שאינו קריטי והטמיעו inline CSS קריטי עבור תוכן שנמצא מעל לקיפול (above the fold).

לאופטימיזציית CLS: בדקו את האתר שלכם לאיתור אלמנטים שזזים במהלך הטעינה. השתמשו ב-DevTools של הדפדפן כדי לזהות אלמנטים שזזים. הוסיפו מאפייני width ו-height לכל תמונה. השתמשו ב-font-display: swap ב-CSS. שריינו מקום למודעות, הטמעות ותוכן דינמי.

לאופטימיזציית INP: השתמשו בלשונית ה-Performance ב-Chrome DevTools כדי לזהות משימות JavaScript ארוכות (משימות שלוקחות מעל 50 אלפיות שנייה). פרקו משימות ארוכות. דחו JavaScript שאינו קריטי. השתמשו ב-requestIdleCallback עבור עבודה בעדיפות נמוכה. בצעו בדיקות במכשירים אמיתיים, לא רק במחשבי שולחן עבודה.

ניטור Core Web Vitals לאורך זמן

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

הגדירו התראות ניטור. אם ה-Core Web Vitals שלכם יורדים, עליכם לחקור זאת מיידית. הגורמים עשויים לכלול: פריסות קוד חדשות שהכניסו חוסר יעילות, סקריפטים חדשים של צד שלישי, שינויים בתמונות או במדיה, או בעיות אחסון (hosting).

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

Core Web Vitals ואסטרטגיית SEO

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

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

סיכום

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

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