היי, אני סער — מהנדס תוכנה, מומחה SEO ומרצה שאוהב לבנות כלים וללמד טכנולוגיה.
לצפייה בפרופיל הכותב ←Core Web Vitals הם סט של שלושה מדדי ביצועים שגוגל הציגה ב-2020 ושילבה באלגוריתם הדירוג של החיפוש האורגני ביוני 2021. שלושת המדדים: LCP (Largest Contentful Paint) למדידת זמן טעינה - יעד פחות מ-2.5 שניות; INP (Interaction to Next Paint) למדידת תגובתיות - יעד פחות מ-200 מילישניות; ו-CLS (Cumulative Layout Shift) למדידת יציבות חזותית - יעד פחות מ-0.1.
במרץ 2024, INP החליף רשמית את FID (First Input Delay) כמדד הליבה לתגובתיות, מכיוון ש-INP מודד את כל מחזור התגובה (מרגע הפעולה ועד שהמשתמש רואה תגובה על המסך) ולא רק את ההשהיה הראשונית כמו FID. שיפור Core Web Vitals חשוב גם לחוויית המשתמש וגם לקידום אורגני - לפי Google, אתרים שעומדים ביעדים יכולים להופיע גבוה יותר בתוצאות החיפוש.
Core Web Vitals כוללים שלושה מדדים מרכזיים שמודדים שלושה היבטים שונים של חוויית המשתמש: זמן טעינה, תגובתיות, ויציבות חזותית. כל מדד מציג סף ברור לטוב/דורש שיפור/גרוע, ו-Google משתמשת בערכי field data (מדידות אמיתיות של משתמשים) כדי לדרג את האתר.
מדד זה מתמקד בזמן טעינה ומציין את הרגע שבו האלמנט הגדול ביותר בתצוגה (כמו תמונה או טקסט גדול) נטען ומוכן לצפייה על ידי הדפדפן. LCP משקף את זמן ההמתנה של המשתמש לראות את התוכן המרכזי בדף, ובדרך כלל זה החלק של ה-Hero section. ערך טוב ל-LCP הוא פחות מ-2.5 שניות, ערך שמצריך שיפור הוא בין 2.5 שניות ל-4 שניות, וערך מעל 4 שניות נחשב לגרוע.
מדד זה מודד את התגובתיות של הדף לפעולות המשתמש - הזמן שלוקח לאתר להציג תגובה ויזואלית על המסך אחרי שהמשתמש מבצע פעולה (לחיצה על כפתור, הקלדה, ניווט וכן הלאה). INP החליף רשמית את FID במרץ 2024 כמדד Core Web Vital, מכיוון ש-INP מודד את כל מחזור התגובה - מרגע הפעולה ועד שהמשתמש רואה את התוצאה - ולא רק את ההשהיה הראשונית כמו ש-FID עשה.
איך INP מחושב: המדד לוקח את הפעולה שלקחה הכי הרבה זמן באופן עקבי בכל הסשן של המשתמש, ומשתמש בה כדי להעריך את ביצועי האתר. ערך טוב ל-INP הוא פחות מ-200 מילישניות, ערך שמצריך שיפור הוא בין 200 ל-500 מילישניות, ומעל 500 מילישניות נחשב לגרוע.
דוגמה: נדמיין שאנחנו עושים שלושה קליקים באתר. הקליק הראשון לוקח שנייה, השני שנייה וחצי, והשלישי ארבע שניות. ערך ה-INP יהיה שנייה וחצי, ולא ארבע שניות. למה? כי ה-INP מתמקד בפעולה שלקחה הכי הרבה זמן באופן עקבי, ולא בחריג. הקליק השלישי שלקח ארבע שניות נחשב לחריג ולא משפיע על ערך ה-INP.
מדד זה בודק כמה יציב הדף במהלך טעינתו, על ידי מדידת כמות ותדירות השינויים בפריסת האלמנטים. לדוגמה, אם טקסט פתאום זז למעלה או למטה, או שתמונות מתווספות ומשנות את המראה הכללי של האתר, זה יכול לגרום לחוויה מבלבלת ומתסכלת למשתמש. CLS נועד להבטיח יציבות, כך שהמשתמשים לא יתקלו בפתע בתוכן לא צפוי או בפרסומות שמופיעות ומפריעות לחוויה שלהם. ערך מצוין ל-CLS הוא עד 0.1, בין 0.1 ל-0.25 מצריך שיפור, ומעל 0.25 נחשב לגרוע.
FID (First Input Delay) היה המדד הוותיק לתגובתיות, ומדד רק את הזמן שלוקח לדפדפן להתחיל לעבד את הפעולה הראשונה של המשתמש - לא את הזמן שלוקח לפעולה להסתיים ולהשפיע על המסך. הבעיה: FID לא לכד את החוויה האמיתית של המשתמש, שמרגיש את האטיות לאורך כל הסשן ולא רק בפעולה הראשונה.
INP נותן תמונה מלאה יותר של חוויית המשתמש כי הוא מתחשב בכל התהליך, מרגע הפעולה ועד שהמשתמש רואה את התגובה על המסך, ולוקח בחשבון את כל הפעולות בסשן ולא רק את הראשונה. במרץ 2024 Google הכריזה רשמית על המעבר, ו-INP הפך למדד הסטנדרטי לתגובתיות.
השיפור של Core Web Vitals חשוב לא רק לחוויית המשתמש, אלא גם לקידום אורגני במנועי החיפוש. גוגל משתמשת במדדים אלה כחלק מאלגוריתם הדירוג שלה, כך שאתרים עם ציונים טובים יותר, יכולים להופיע גבוה יותר בתוצאות החיפוש. בנוסף, שיפור ה-Core Web Vitals יכול להוביל להגדלת שיעורי ההמרה ולהקטנת שיעורי היציאה מהאתר והסיבה היא חוויית המשתמש.
היעדים שהוצגו כאן נשמעים ברי-השגה, אבל בפועל רוב האתרים לא עומדים בהם. דוח State of Websites 2026 של Greadme בחן 643 אתרים אמיתיים ב-1,133 בדיקות דפים מתוך מסד הנתונים של הפלטפורמה, ומספק תמונה מדודה של המצב בשטח - לא סקר ולא הערכה, אלא בדיקות שרצו על אתרים חיים.
הממצא הבולט הוא הפער בין מובייל ל-desktop: ציון הביצועים החציוני במובייל עמד על 65, לעומת 84 ב-desktop. 87.4% מבדיקות המובייל לא עמדו ביעד ה-LCP של 2.5 שניות, ורק 12.8% מהן הגיעו לטווח ה"טוב" (90 ומעלה). זה בדיוק ההסבר לכך שבעלי אתרים רבים מרגישים שהאתר שלהם מהיר - הם בודקים אותו ב-desktop, בעוד שגוגל מדרגת לפי mobile-first indexing.
מנגד, CLS יצא כמדד הפתור ביותר מבין השלושה: רק 16.9% מהבדיקות נכשלו בו. ההיגיון מאחורי זה פשוט - הקצאת מקום לתמונות באמצעות height ו-width היא תיקון חד-פעמי וזול, בעוד ש-LCP דורש עבודה מתמשכת על זמני שרת, אופטימיזציית תמונות ו-JavaScript.
אלו רק הנתונים שרלוונטיים ל-Core Web Vitals. הדוח המלא מכסה גם אבטחה, נגישות, מטא-תגיות, נתונים מובנים והתנהגות של סורקי AI, כולל פירוט המתודולוגיה ופילוח לפי פלטפורמות. את הממצאים המלאים תוכלו לקרוא בדוח State of Websites 2026 של Greadme.
מבחינת LCP, תוכלו להקטין את גודל האלמנט כמו תמונות וקבצים כבדים כדי לזרז טעינה מהירה יותר. בנוסף השתמשו ב-Lazy Loading לטעינת תמונות ווידאו רק כאשר המשתמש מגיע אליהם, ואם יש לכם את הידע המתאים, נסו לשפר את זמני התגובה של השרת (בדרך כלל מצריך מתכנת).
מבחינת INP, נסו לפצל קוד JavaScript לחלקים קטנים יותר ובכך יהיה פחות עומס, והתגובתיות תהיה מהירה יותר. JavaScript כבד יכול לחסום את ה-main thread של הדפדפן ולהאט את תגובת האתר שלכם. גישות נוספות: dynamic imports לטעינת קוד רק כשצריך, web workers להרצת חישובים כבדים ב-thread נפרד, ו-debouncing/throttling על event handlers.
מבחינת CLS, הימנעו משינויי גודל באתר שלכם והזזת תוכן במיוחד בזמן הטעינה הראשונית. בנוסף, הקצו מקום לתמונות לפני טעינתן על ידי ה-attributes גובה (height) ורוחב (width) כדי שהדפדפן שלכם יכיר בצורך של שמירת מקום ובכך תשפרו משמעותית את CLS.
למדידת המדדים בזמן אמת, השתמשו ב-PageSpeed Insights, Chrome DevTools, או ה-Core Web Vitals report ב-Google Search Console.
בסופו של דבר, Core Web Vitals הם כלים חשובים למדידת חוויית המשתמש באתרים. על ידי שיפור המדדים הללו אתם תקבלו נקודות מגוגל ותוכלו לשפר את ה-SEO שלכם ולהגדיל את הסיכויים להיות מדורגים גבוה יותר במנועי חיפוש.
Google הכריזה רשמית על המעבר מ-FID ל-INP כמדד Core Web Vital במרץ 2024. INP נחשב למדד מדויק יותר של תגובתיות מכיוון שהוא מודד את כל מחזור התגובה - מרגע פעולת המשתמש ועד שהדפדפן מציג תגובה ויזואלית - ולא רק את ההשהיה הראשונית כמו FID. אתרים נדרשים לעמוד ביעד של INP פחות מ-200 מילישניות.
יש מספר כלים רשמיים: PageSpeed Insights (pagespeed.web.dev) שמציג נתוני lab + field; Google Search Console מציג Core Web Vitals report בכרטיסיית "Experience"; Chrome DevTools (Lighthouse panel) להרצת בדיקות lab; ו-web.dev/measure לסקירה כוללת. בנוסף, יש את ספריית web-vitals של Google למדידה בקוד האתר.
Lab data הוא מדידה סינתטית במעבדה - הרצת בדיקה אחת בתנאים מבוקרים (כמו ב-Lighthouse). Field data הוא מדידה אמיתית של משתמשים בעולם האמיתי, מאוסף Chrome User Experience Report (CrUX) ב-28 הימים האחרונים. Google מדרג את האתר לפי field data, לא lab. הם יכולים להיות שונים מאוד - אתר יכול להיות מהיר ב-lab ואיטי בשטח בגלל רשתות איטיות, מכשירים חלשים, או התנהגות משתמשים בפועל.
כן, אבל Google מדרגת אותם בנפרד. אתר יכול לעמוד ביעדי Core Web Vitals במובייל אבל לא ב-desktop, או להפך. בפועל, מובייל הוא קריטי יותר - Google משתמשת ב-mobile-first indexing מאז 2019, ולכן הציון של מובייל הוא זה שמשפיע יותר על הדירוג. האתגרים במובייל גם גדולים יותר: רשתות איטיות, מעבדים חלשים, וחיבורים פחות יציבים.
לפי דוח State of Websites 2026 של Greadme, שבחן 643 אתרים אמיתיים ב-1,133 בדיקות דפים, הרוב לא עומדים ביעדים. 87.4% מבדיקות המובייל לא עמדו ביעד ה-LCP של 2.5 שניות, ורק 12.8% מהן הגיעו לטווח ה"טוב" (90 ומעלה). ציון הביצועים החציוני במובייל עמד על 65 לעומת 84 ב-desktop. היוצא מן הכלל הוא CLS - רק 16.9% נכשלו בו, משום שהתיקון שלו פשוט וחד-פעמי.
Google מאשרת ש-Core Web Vitals הם signal של דירוג מאז יוני 2021, אבל הם רק אחד מבין מאות signals. רלוונטיות התוכן (E-E-A-T, התאמה לשאילתה) משקלה גבוה יותר. מצד שני, אתר עם UX נוראי יסבול: שיעורי bounce גבוהים מאותתים על איכות נמוכה. הגישה הנכונה: לעמוד ביעדים כרף בסיסי, אבל להמשיך להשקיע גם בתוכן ובחוויית משתמש כוללת.
