Core Web Vitals: מה המדדים בודקים ואיך עוברים אותם (2026)

Core Web Vitals הם שלושה מדדים שגוגל הגדירה כדי למדוד איך עמוד מרגיש לגולש אמיתי: כמה מהר מופיע התוכן המרכזי (LCP), כמה מהר העמוד מגיב לפעולות (INP), וכמה הפריסה שלו יציבה בזמן הטעינה (CLS). המדדים נמדדים אצל משתמשי Chrome אמיתיים, מוצגים ב-Search Console וב-PageSpeed Insights, ומהווים חלק מאותות חוויית העמוד שגוגל משתמשת בהם בדירוג. עמוד "עובר" כשכל שלושת המדדים נמצאים בטווח הטוב אצל לפחות 75% מהביקורים.

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

מה זה Core Web Vitals?

גוגל הציגה את Core Web Vitals ב-2020, והם הפכו לחלק מאותות הדירוג ב-2021, במסגרת עדכון חוויית העמוד (Page Experience). הם תת-קבוצה של רשימה רחבה יותר בשם Web Vitals, שכוללת גם מדדים כמו TTFB ו-FCP. ההבדל הוא שהמדדים "הליבתיים" רלוונטיים לכל עמוד באינטרנט, מוצגים בכל הכלים של גוגל, ונבחרו כי הם משקפים את שלוש החוויות הבסיסיות של גלישה: טעינה, תגובה ויציבות.

מדד	שם מלא	מה הוא מודד	טוב	צריך שיפור	גרוע
LCP	Largest Contentful Paint	מתי מופיע הרכיב הגדול ביותר במסך הראשון	עד 2.5 שניות	2.5 עד 4 שניות	מעל 4 שניות
INP	Interaction to Next Paint	כמה זמן עובר מלחיצה או הקלדה עד שהמסך מתעדכן	עד 200 מ"ש	200 עד 500 מ"ש	מעל 500 מ"ש
CLS	Cumulative Layout Shift	כמה התוכן זז ממקומו באופן לא צפוי	עד 0.1	0.1 עד 0.25	מעל 0.25

המדד FID (First Input Delay), שהיה חלק מהשלישייה המקורית, הוצא משימוש במרץ 2024 והוחלף ב-INP. אם אתם נתקלים במדריך שעדיין מדבר על FID, הוא מבוסס על מידע ישן.

איך גוגל מודדת את Core Web Vitals?

נתוני שדה מול נתוני מעבדה

נתוני שדה (Field Data) נאספים מגולשים אמיתיים שמשתמשים ב-Chrome והסכימו לשתף נתוני שימוש. הם מרוכזים בדוח בשם CrUX (Chrome User Experience Report), ועליהם גוגל מסתמכת בדירוג. נתוני מעבדה (Lab Data) הם סימולציה: כלי כמו Lighthouse טוען את העמוד במכשיר ובחיבור מוגדרים מראש ומחשב ציון. סימולציה מצוינת לאבחון ולבדיקה לפני ואחרי שינוי, אבל היא לא מה שגוגל רואה. לכן עמוד יכול לקבל ציון 100 ב-Lighthouse ועדיין להיכשל בנתוני השדה, וגם להפך.

האחוזון ה-75

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

חלון מתגלגל של 28 ימים

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

נתוני עמוד, קבוצת עמודים ונתוני אתר

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

LCP לעומק: מהירות הצגת התוכן המרכזי

מה נחשב לרכיב ה-LCP?

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

ארבעת החלקים של LCP

הדרך המקצועית לטפל ב-LCP היא לפרק אותו לחלקים, ולבדוק איזה מהם צורך את רוב הזמן:

חלק	מה קורה בו	סיבה נפוצה לאיטיות	תיקון עיקרי
זמן תגובת השרת (TTFB)	מהבקשה ועד שהבייט הראשון של ה-HTML מגיע	אחסון חלש, אין מטמון עמודים, הפניות מיותרות	מטמון עמודים, אחסון טוב יותר, CDN
השהיית טעינת המשאב	הזמן עד שהדפדפן מתחיל להוריד את תמונת ה-LCP	התמונה נטענת דרך CSS או JavaScript, או מסומנת לטעינה עצלה	תמונה רגילה ב-HTML, fetchpriority="high", ביטול lazy בתמונה הזו
משך טעינת המשאב	זמן ההורדה של התמונה עצמה	קובץ כבד, גודל לא מותאם, פורמט ישן	WebP או AVIF, גדלים מותאמים עם srcset, דחיסה
השהיית רינדור	מהרגע שהתמונה הגיעה ועד שהיא מוצגת	CSS ו-JavaScript חוסמים, גופנים שמעכבים טקסט	CSS קריטי, דחיית סקריפטים, font-display: swap

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

איך משפרים LCP בפועל?

• להציג את תמונת ה-LCP כתגית img רגילה ב-HTML, ולא כרקע ב-CSS או דרך סליידר שנבנה ב-JavaScript.
• לא לטעון אותה בטעינה עצלה. זו הטעות הנפוצה ביותר. Lazy Load מצוין לתמונות שמתחת לקפל, והרסני לתמונה הראשית. פירוט בערך דחיסת תמונות ו-Lazy Load.
• לסמן אותה בעדיפות גבוהה עם fetchpriority="high", ואם היא מגיעה מדומיין אחר, להוסיף preconnect לדומיין.
• לקצר את TTFB עם מטמון עמודים ואחסון מתאים. אם TTFB לבד עובר שנייה, שום אופטימיזציה של תמונות לא תציל את המדד.
• לצמצם CSS חוסם ולדחות JavaScript שלא נדרש לתצוגה הראשונה.

INP לעומק: תגובה לפעולות הגולש

איך INP מחושב?

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

שלושת השלבים של אינטראקציה

שלב	מה קורה בו	מה מאט אותו
השהיית קלט (Input Delay)	הזמן מהלחיצה עד שהדפדפן מתחיל לטפל בה	ה-Main Thread עסוק במשימה אחרת, בדרך כלל סקריפט שעדיין רץ
זמן עיבוד (Processing)	הרצת הקוד שמגיב ללחיצה	קוד כבד באירוע עצמו, הרבה עבודה מיותרת בכל לחיצה
השהיית הצגה (Presentation Delay)	הזמן עד שהשינוי מצויר במסך	DOM ענק, חישובי פריסה כבדים, עדכון של חלקים רבים בעמוד

איך משפרים INP?

• לפרק משימות ארוכות. כל משימה ב-JavaScript שנמשכת מעל 50 מילישניות חוסמת את הדפדפן. מפצלים אותה לחלקים קטנים ומחזירים שליטה לדפדפן ביניהם.
• לצמצם סקריפטים של צד שלישי. צ'אטים, פיקסלים, מפות חום ווידג'טים הם הגורם הנפוץ להשהיית קלט. טוענים אותם מאוחר, או רק בעמודים שבאמת צריכים אותם.
• להקטין את ה-DOM. עמוד עם אלפי רכיבים מקוננים מאט כל עדכון במסך. בוני עמודים כבדים נוטים לייצר DOM עמוק במיוחד.
• לתת משוב מיידי. כשפעולה דורשת זמן, מציגים מיד מצב טעינה, ורק אחר כך מבצעים את העבודה הכבדה.
• להימנע מאנימציות שמפעילות חישובי פריסה, ולהעדיף transform ו-opacity.

CLS לעומק: יציבות הפריסה

איך CLS מחושב?

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

מה גורם לתזוזות?

גורם	מה קורה	פתרון
תמונות ווידאו בלי מידות	הדפדפן לא יודע כמה מקום לשמור, והתוכן נדחף כשהתמונה מגיעה	width ו-height לכל תמונה, או aspect-ratio ב-CSS
מודעות, באנרים ו-iframe	נטענים מאוחר ודוחפים את הטקסט למטה	שמירת מקום קבוע מראש לכל משבצת
גופני רשת	הטקסט מוצג בגופן חלופי ואז "קופץ" כשהגופן נטען	טעינה מוקדמת של הגופן הראשי והתאמת מידות הגופן החלופי
תוכן שמוזרק למעלה	באנר עוגיות, הודעה או פס מבצעים שנכנסים מעל התוכן	להציג אותם כשכבה צפה, או לשמור להם מקום מראש
אנימציות של מיקום או גודל	שינוי top, height או margin גורר חישוב פריסה	אנימציה עם transform בלבד

CLS הוא גם עניין של נגישות: תוכן שקופץ מבלבל במיוחד גולשים עם לקויות ראייה או קשב. על הקשר בין השניים בערך נגישות אתרים.

איך קוראים את דוח Core Web Vitals ב-Search Console?

הדוח מחולק לנייד ולמחשב, ומציג את הכתובות בשלושה סטטוסים: טוב, צריך שיפור וגרוע. כל בעיה מוצגת כקבוצה של כתובות דומות עם דוגמה, למשל "בעיה ב-LCP: מעל 2.5 שניות (נייד)". כמה דברים שחשוב לדעת:

• "אין מספיק נתונים" הוא מצב נפוץ באתרים קטנים. זה לא קנס, אלא סימן שאין מספיק ביקורים מ-Chrome. במקרה כזה בודקים עם PageSpeed Insights ו-Lighthouse.
• המדד שבדוח הוא הגרוע מבין השלושה. עמוד עם LCP מצוין ו-CLS גרוע יופיע כגרוע.
• אחרי תיקון לוחצים על "אימות התיקון". גוגל עוקבת אחרי הכתובות במשך 28 ימים ומעדכנת את הסטטוס. סבלנות היא חלק מהתהליך.

מדריך מלא לשאר הדוחות בערך Google Search Console.

סדר עבודה מומלץ לתיקון Core Web Vitals

1. מזהים איזה מדד נכשל ובאיזה מכשיר. ברוב האתרים הבעיה היא בנייד, וכמעט תמיד מדד אחד בולט מעל האחרים.
2. בוחרים עמוד מייצג לכל תבנית. עמוד בית, מאמר, עמוד שירות, מוצר. תיקון בתבנית מתקן את כל העמודים שלה.
3. מאבחנים לעומק. ב-PageSpeed Insights בודקים מה רכיב ה-LCP ואילו חלקים איטיים. בכלי המפתחים של Chrome, בלשונית Performance, אפשר לראות את המדדים בזמן אמת תוך כדי לחיצות בעמוד.
4. מתקנים לפי סדר השפעה. בדרך כלל: TTFB ומטמון, תמונת ה-LCP, סקריפטים של צד שלישי, מידות לתמונות ולמודעות.
5. משנים דבר אחד בכל פעם ובודקים שוב, כדי לדעת מה עזר ומה שבר.
6. מאמתים ב-Search Console ומחכים 28 ימים לפני שמסיקים מסקנות.

Core Web Vitals בוורדפרס

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

בעיה	מדד שנפגע	מה עושים
אין מטמון עמודים	LCP (דרך TTFB)	פלאגין מטמון או מטמון ברמת השרת
סליידר בראש העמוד	LCP, CLS	תמונה סטטית אחת במקום סליידר
בונה עמודים כבד	INP, LCP	צמצום רכיבים, ובאתרים חדשים שקילת עורך הבלוקים או תבנית קוד קלה
תוספי צ'אט, פיקסלים ופופאפים	INP	טעינה מושהית ורק בעמודים הנחוצים
גופנים מ-Google Fonts	LCP, CLS	אירוח מקומי, WOFF2, טעינה מוקדמת של הגופן הראשי
תמונות שהועלו בגודל מקורי	LCP	הקטנה לפני העלאה והמרה ל-WebP

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

כמה Core Web Vitals משפיעים על הדירוג?

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

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

מיתוסים נפוצים על Core Web Vitals

• "צריך 100 ב-PageSpeed". לא. הציון הוא סימולציה. מה שקובע הוא נתוני השדה בטווח הטוב.
• "FID עדיין רלוונטי". הוא הוחלף ב-INP במרץ 2024.
• "פלאגין מהירות אחד יפתור הכל". פלאגין עוזר בעיקר ל-LCP. בעיות INP נובעות לרוב מסקריפטים, ובעיות CLS ממבנה העמוד.
• "גוגל הוסיפה מדד רביעי". נכון לעכשיו השלישייה היא LCP, INP ו-CLS, והיעדים לא השתנו מאז כניסת INP.
• "Lazy Load על כל התמונות תמיד משפר". על התמונה הראשית הוא פוגע ב-LCP.

שאלות נפוצות

מה הם שלושת מדדי Core Web Vitals?

LCP מודד כמה מהר מופיע התוכן המרכזי (יעד: עד 2.5 שניות), INP מודד כמה מהר העמוד מגיב ללחיצות ולהקלדות (יעד: עד 200 מילישניות), ו-CLS מודד כמה התוכן זז ממקומו בזמן הטעינה (יעד: עד 0.1).

מה ההבדל בין INP ל-FID?

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

למה PageSpeed Insights מראה ציון טוב אבל Search Console מראה בעיה?

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

כמה זמן לוקח לראות שיפור אחרי תיקון?

נתוני השדה מחושבים על חלון מתגלגל של 28 ימים, ולכן השיפור מופיע בהדרגה והתמונה המלאה מתעדכנת אחרי כארבעה שבועות. אחרי התיקון כדאי ללחוץ על אימות התיקון בדוח של Search Console.

מה עושים כשכתוב בדוח שאין מספיק נתונים?

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

האם Core Web Vitals הם גורם דירוג חשוב?

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

סיכום

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