Core Web Vitals ב-2026 — מה עדיין חשוב לדירוג ומה כבר לא

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

שלושת המדדים של 2026

• LCP (Largest Contentful Paint) — כמה זמן עד שהאלמנט הגדול ביותר בעמוד (לרוב תמונת ההירו או כותרת) מצויר. יעד: מתחת ל-2.5 שניות. זה מדד ה"מהירות הנתפסת".
• INP (Interaction to Next Paint) — כמה מהר העמוד מגיב לפעולה של המשתמש (קליק, הקלדה). INP החליף את FID במרץ 2024, והוא מחמיר יותר — הוא מודד את כל האינטראקציות לאורך הביקור, לא רק את הראשונה. יעד: מתחת ל-200 מילישניות.
• CLS (Cumulative Layout Shift) — כמה התוכן "קופץ" בזמן הטעינה (תמונה בלי מידות שדוחפת טקסט, באנר שנכנס פתאום). יעד: מתחת ל-0.1.

מה כבר לא רלוונטי

• FID (First Input Delay) — הוסר. אם המשרד שלכם עדיין מדבר על "לשפר FID" — הוא מפגר בשנתיים.
• ציון PageSpeed של 100 — הציון ב-Lighthouse הוא הדמיה במעבדה, לא מה שגוגל משתמש בו לדירוג. גוגל משתמש בנתוני שדה אמיתיים (CrUX) ממשתמשים אמיתיים. אפשר לקבל 100 ב-Lighthouse ועדיין להיכשל ב-Core Web Vitals בשטח, ולהפך.
• אובססיה למילישניות — ההבדל בין LCP של 1.8 ל-2.1 שניות זניח לדירוג. ההבדל בין 2.1 ל-4.5 שניות משמעותי מאוד. השאיפה היא לעבור את הסף, לא לשבור שיאים.

כמה זה באמת משפיע על הדירוג

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

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

איך לבדוק את המצב האמיתי

• Search Console → Core Web Vitals — הדוח הרשמי, מבוסס נתוני שדה. מראה כמה עמודים "טובים", "צריכים שיפור" ו"גרועים", בנפרד למובייל ולדסקטופ.
• PageSpeed Insights — הזינו כתובת, וקבלו גם נתוני שדה (אם יש מספיק תנועה) וגם הדמיית מעבדה עם המלצות ספציפיות.
• הסתכלו על מובייל קודם — רוב התנועה מגיעה משם, וגוגל מדרג לפי גרסת המובייל.

התיקונים שנותנים הכי הרבה

• ל-LCP: דחיסת תמונות והמרה ל-WebP, הגדרת מידות מפורשות לתמונות, טעינה מוקדמת של תמונת ההירו, ואירוח מהיר.
• ל-INP: צמצום JavaScript של צד שלישי (סקריפטים של פיקסלים, צ'טים, כלי אנליטיקה כבדים), פיצול קוד, והסרת תוספים מיותרים.
• ל-CLS: מידות מפורשות לכל תמונה ו-iframe, שריון מקום לבאנרים ומודעות, וטעינת גופנים עם font-display נכון כדי למנוע "קפיצת" טקסט.

דוגמה מהשטח

אתר של משרד אדריכלים נכשל ב-Core Web Vitals במובייל: LCP של 5.1 שניות ו-CLS של 0.28. הסיבות: תמונות פורטפוליו ענקיות בלי דחיסה, גופן שנטען מאוחר וגרם לטקסט לקפוץ, ושלושה סקריפטים של צד שלישי. דחסנו את התמונות (משקל ירד ב-80%), הוספנו מידות מפורשות, טענּו את הגופן נכון, והסרנו סקריפט צ'אט שלא היה בשימוש. LCP ירד ל-2.2 שניות ו-CLS ל-0.04 — שני המדדים עברו לירוק. הדירוג לא זינק בגלל זה לבד, אבל אחוז הנטישה במובייל ירד ב-19%, וזה תרם גם להמרות וגם לאותות ההתנהגות שגוגל שוקל.

איך אנחנו מטפלים ב-Core Web Vitals ב-Wise Rank

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

שלושת המדדים — ספים ותיקונים

מדד	טוב	דורש שיפור	גרוע	גורם נפוץ	תיקון מהיר
LCP (טעינת התוכן המרכזי)	≤ 2.5 ש'	2.5–4 ש'	> 4 ש'	תמונת hero כבדה, שרת איטי	דחיסת תמונה + preload
INP (תגובתיות ללחיצות)	≤ 200ms	200–500ms	> 500ms	סקריפטים כבדים של צד ג'	לדחות/להסיר סקריפטים לא קריטיים
CLS (יציבות פריסה)	≤ 0.1	0.1–0.25	> 0.25	תמונות/פרסומות בלי מידות	להגדיר width/height לכל תמונה

מעבדה מול שדה — למה הציון שלכם מטעה

הציון ב-PageSpeed Insights או ב-Lighthouse הוא הדמיית מעבדה: מכשיר מדומה, רשת מדומה, טעינה אחת. גוגל לא מדרג לפיו. מה שגוגל שוקל הוא נתוני שדה — מדידות אמיתיות מגולשים אמיתיים, שמופיעות בדוח "Core Web Vitals" ב-Search Console וב-CrUX. אתר יכול לקבל 95 במעבדה ועדיין להיכשל בשדה, כי גולשים אמיתיים על מכשירים חלשים ורשתות איטיות חווים משהו אחר. הכלל: תקנו מה שהמעבדה מראה כשבור, אבל מדדו הצלחה לפי דוח השדה ב-Search Console.

לפי פלטפורמה: וורדפרס, חנות, אתר מותאם

• וורדפרס — רוב הבעיות מגיעות מעודף תוספים, מבנה עמוד כבד (page builder), ותמונות לא דחוסות. תוסף מטמון + דחיסת תמונות אוטומטית + ניקוי תוספים פותרים את רוב זה.
• חנות (WooCommerce / Shopify) — סקריפטים של אפליקציות ומעקב הם החשוד המרכזי ל-INP. לבדוק כל אפליקציה: האם היא שווה את העלות בביצועים.
• אתר מותאם / Headless — לרוב מהיר יותר בבסיס, אבל CLS מפונטים ומתמונות בלי מידות ו-INP מ-hydration כבד עדיין נפוצים. תקציב ביצועים מוגדר מראש מונע הידרדרות.

התיקונים שנותנים הכי הרבה — לפי סדר

• תמונות — דחיסה לפורמט מודרני, הגשה בגודל התצוגה בפועל (לא 3000px לתיבה של 800), ו-width/height מוגדרים בקוד. מתקן גם LCP וגם CLS, והמאמץ נמוך.
• סקריפטים של צד ג' — כל צ'אט, פופאפ, מפת חום וכלי מעקב מוסיפים זמן ופוגעים ב-INP. עוברים אחד-אחד: האם הוא שווה את העלות?
• מטמון ו-CDN — תוסף מטמון על וורדפרס, ו-CDN לנכסים סטטיים. שיפור גדול במאמץ קטן.
• פונטים — לצמצם למשפחה אחת ב-2–3 משקלים, לארח מקומית, ולהגדיר font-display: swap.
• קוד קריטי — לדחות CSS/JS לא-קריטי. כאן כבר צריך מפתח, וזה השלב האחרון.

מתי Core Web Vitals הופך לעדיפות — ומתי לא

הכלל הפרקטי: אם דוח Core Web Vitals ב-Search Console מראה עמודים ב"גרוע" (LCP מעל 4 שניות, INP מעל 500ms, או CLS מעל 0.25) — זה עולה לראש הרשימה, כי זה גם פוגע בדירוג וגם מבריח גולשים. אם הכול ב"טוב" או ב"דורש שיפור" קל — זה עבודה שנעשית ברקע, במקביל לתוכן ולסמכות, לא במקומם. הטעות הנפוצה היא לעצור חודשיים של עבודת תוכן כדי לרדוף אחרי ציון 100 ב-PageSpeed, שגוגל ממילא לא מדרג לפיו. מהירות היא גורם דירוג קל-משקל ששובר שוויון בין עמודים דומים; היא לא מחליפה תוכן טוב וקישורים.

כמה Core Web Vitals באמת משפיע על הדירוג

גוגל אמר את זה במפורש: חוויית העמוד היא גורם דירוג, אבל קל-משקל, ש"שובר שוויון" בין עמודים דומים ברלוונטיות. עמוד עם תוכן טוב יותר וקישורים חזקים יותר ידרג מעל עמוד מהיר יותר עם תוכן חלש. המשמעות המעשית: אם המדדים שלכם ב"טוב" או "דורש שיפור" קל — זו לא עדיפות עליונה, ומטפלים בזה ברקע. אם הם ב"גרוע" (LCP מעל 4 שניות, INP מעל 500ms, CLS מעל 0.25) — זה עולה לראש, כי מעבר לדירוג, זה מבריח גולשים ומעלה את אחוז הנטישה.

לפי פלטפורמה: וורדפרס, חנות, אתר מותאם

• וורדפרס — רוב הבעיות: עודף תוספים, page builder כבד, תמונות לא דחוסות. תוסף מטמון + דחיסת תמונות + ניקוי תוספים פותרים את רוב זה בלי מפתח.
• חנות (WooCommerce / Shopify) — סקריפטים של אפליקציות ומעקב הם החשוד ל-INP. לבדוק כל אפליקציה: שווה את העלות בביצועים?
• אתר מותאם — מהיר יותר בבסיס, אבל CLS מפונטים ותמונות בלי מידות, ו-INP מ-hydration כבד, עדיין נפוצים. תקציב ביצועים מוגדר מראש מונע הידרדרות.

טעות: לעצור הכול בשביל ציון PageSpeed

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

INP — המדד שהכי הרבה אתרים נכשלים בו

INP (Interaction to Next Paint) החליף את FID ב-2024, והוא קפדני יותר: הוא מודד את זמן התגובה של העמוד לכל לחיצה, הקלדה או הקשה — לא רק הראשונה. הסף הטוב הוא 200ms; הרבה אתרים עסקיים יושבים על 300–500ms בגלל סקריפטים כבדים של צד ג' (צ'אט, מפות חום, מנהלי תגיות עמוסים) שחוסמים את ה-thread הראשי כשהמשתמש מנסה לפעול. התיקון: לעבור על כל סקריפט חיצוני ולשאול אם הוא שווה את העלות, לדחות טעינה של מה שלא קריטי, ולצמצם מנהל תגיות מנופח.

CLS — הגורם שהכי קל לתקן

CLS (Cumulative Layout Shift) מודד כמה העמוד "קופץ" בזמן הטעינה — טקסט שזז כי תמונה נטענה מאוחר, כפתור שמחליף מקום כי באנר הופיע. זו החוויה שגורמת ללחוץ על הכפתור הלא נכון. וזה גם הכי קל לתקן: להגדיר width ו-height מפורשים לכל תמונה ו-iframe (כדי שהדפדפן ישריין מקום מראש), לשמור מקום קבוע לבאנרים ולפרסומות, ולטעון פונטים עם font-display: swap ו-fallback במידות דומות. ברוב האתרים, שעה של עבודה מורידה CLS מ"גרוע" ל"טוב".

שאלות נפוצות

קיבלתי 95 ב-PageSpeed. אני בסדר?

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

כדאי לעצור הכול ולתקן Core Web Vitals לפני שממשיכים?

לא. אלא אם המדדים "גרועים" ממש (LCP מעל 4 שניות, CLS מעל 0.25). תיקון טכני נעשה במקביל לעבודת התוכן והסמכות, לא במקומם.

האתר שלי חדש ואין נתוני שדה. מה עושים?

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

עודכן לאחרונה: 9 בספטמבר 2026