Core Web Vitals, המדריך השלם

⚡ מה זה Core Web Vitals ולמה זה לא רק עוד מטריקה

תקשיבו טוב. ב 2020 גוגל הכריזה ש מהירות וחווית משתמש יהיו גורם דירוג. ב 2021 זה הופך לרשמי, Core Web Vitals (CWV). היום, ב 2026, אתר עם CWV אדום פשוט לא תחרותי. נקודה.

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

3 המטריקות

1. LCP (Largest Contentful Paint)

   זמן עד שהאלמנט הגדול ביותר בעמוד נטען. בדרך כלל תמונת hero או H1. מדד טוב, פחות מ 2.5 שניות.

2. CLS (Cumulative Layout Shift)

   כמה הלייאאוט קופץ ומשתנה אחרי שהעמוד נטען. מטריקה ל יציבות. מדד טוב, פחות מ 0.1.

3. INP (Interaction to Next Paint)

   תגובתיות לקליקים. כמה זמן עובר מהקליק עד שהדפדפן מגיב. החליף את FID ב מרץ 2024. מדד טוב, פחות מ 200ms.

הצבעים

📏 LCP, הזמן עד שרואים את התוכן

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

מה זה האלמנט הגדול ביותר

• תמונת hero גדולה
• וידאו thumbnail
• בלוק טקסט גדול (H1 + paragraph)
• background image עם תוכן עליה

מה משפיע על LCP

1. זמן תגובת שרת (TTFB)

   השרת לוקח X שניות להחזיר את ה HTML. אם TTFB 800ms, LCP לא יכול להיות מתחת ל 1s.

2. זמן טעינת CSS

   הדפדפן מחכה ל CSS לפני שמציג תוכן. CSS גדול וכבד = LCP גרוע.

3. זמן טעינת תמונות

   תמונת hero של 3MB בלי אופטימליות = LCP גרוע.

4. JavaScript חוסם

   scripts ש blocking ב head מעכבים rendering.

5. גורמי third-party

   ads, analytics, chat widgets מאטים.

איך לתקן LCP

• אחסון מהיר (TTFB < 200ms)
• CDN פעיל
• אופטימיזציית תמונות (WebP, גודל מתאים)
• preload של hero image, <link rel="preload" as="image" href="...">
• Critical CSS inline, שאר ה CSS נטען async
• הסרת JavaScript מיותר
• defer/async של scripts לא קריטיים

📐 CLS, היציבות שעוצרת את התסכול

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

הסיבות הנפוצות ל CLS גרוע

• תמונות בלי width/height attributes
• פרסומות שנטענות מאוחר ודוחקות תוכן
• iframes שנטענים מאוחר
• גופנים שמחליפים גופן ברירת מחדל (FOUT/FOIT)
• תוכן שנוסף דינמית בלי שטח שמור
• animations שמשנות layout

איך לתקן CLS

1. תמונות עם width ו height

   תמיד. בכל תמונה. הדפדפן שומר את השטח לפני שהתמונה נטענת.

2. גופנים עם font-display: swap

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

3. שטח שמור לפרסומות

   הגדירו min-height ל container של פרסומת לפני שהיא נטענת.

4. iframe עם dimensions

   height ו width מוגדרים ל iframe.

5. אל תוסיפו תוכן מעל תוכן קיים

   banners ו pop-ups שמופיעים מלמעלה דוחקים תוכן. תנו להם overlay, לא layout shift.

6. animations עם transform/opacity בלבד

   אלה לא משנות layout. הימנעו מ animations שמשנות width/height/top/left.

CLS Hidden Issues

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

⚡ INP, התגובתיות שמחליפה את FID

במרץ 2024 גוגל החליפה את FID (First Input Delay) ב INP (Interaction to Next Paint). זה היה שינוי גדול ש שבר את ה CWV של הרבה אתרים.

ההבדל בין FID ל INP

• FID, רק האינטרקציה הראשונה. רק זמן עד שה JavaScript מתחיל. לא כללית את כל הזמן עד שראינו תוצאה.
• INP, כל האינטרקציות. הזמן הארוך ביותר. כולל את כל הזמן עד שראינו את התוצאה הויזואלית.

למה INP יותר קשה

INP מודד עד paint. זה אומר, אם אתם מקליקים על כפתור, ולוקח 500ms עד ש הדפדפן מציג שינוי, INP הוא 500ms. גם אם ה JavaScript הגיב מהר.

הסיבות ל INP גרוע

1. JavaScript ארוך, פונקציה שלוקחת 300ms חוסמת את הדפדפן
2. Event handlers כבדים, click listener שעושה הרבה עבודה
3. DOM גדול, dezenes של אלמנטים שמתעדכנים
4. third-party scripts, analytics ו ads מאטים
5. React/Vue updates כבדים, רנדור מחדש של חלקים גדולים מה DOM

איך לתקן INP

1. חלקו פונקציות ארוכות

   פונקציה של 200ms תחלקו ל 4 פונקציות של 50ms. השתמשו ב setTimeout או requestIdleCallback.

2. השתמשו ב Web Workers

   למשימות כבדות. ה main thread נשאר חופשי.

3. Lazy Hydration

   ב React/Next.js, hydrate חלקים של העמוד רק כשמגיעים אליהם.

4. אופטימליות של event handlers

   debounce ו throttle על input, scroll, resize.

5. Defer של scripts לא קריטיים

   analytics, chat, ads טעונים אחרי שהעמוד אינטראקטיבי.

🛠 כלי מדידה, PSI Lighthouse CrUX WebPageTest

איך מודדים CWV? יש 4 כלים עיקריים, וכל אחד עם מטרה שונה.

Lab vs Field, ההבדל הקריטי

• Lab data, מדידה סינתטית. הכלי מריץ את העמוד בסביבת בדיקה מבוקרת. עקבי, אבל לא משקף את החוויה האמיתית.
• Field data, מ משתמשים אמיתיים. אגרגטיב נתונים מ Chrome. משקף חוויה אמיתית, אבל פחות עקבי.

איזה כלי מתי

1. פיתוח/דיבוג, Lighthouse ב DevTools, מהיר, עם המלצות
2. בדיקה כללית, PageSpeed Insights, מהיר, נתונים מ Field
3. ניתוח מעמיק, WebPageTest, waterfall מפורט, מספר locations
4. מעקב לאורך זמן, Search Console > CWV, מציג גם prerelease של בעיות עתידיות
5. נתונים אמיתיים אגרגטיביים, CrUX dashboard, נתונים מ Chrome גלובלית

🖼 אופטימיזציית תמונות, ההשפעה הכי גדולה על LCP

תמונות הן 50%+ מהמשקל של עמוד ממוצע. ולעיתים האלמנט שאחראי ל LCP. אם תאופטימזו תמונות, אתם בדרך כלל פותרים את רוב הבעיות.

הצעדים

1. פורמט WebP או AVIF

   חוסך 30-50% משקל לעומת JPG/PNG. כל הדפדפנים המודרניים תומכים.

2. גודל מתאים

   אל תעלו 4000px כשמציגים ב 800px. השתמשו ב srcset לגדלים שונים.

3. Lazy loading

   תמונות מתחת ל fold נטענות רק כשמגיעים אליהן. native, loading="lazy".

4. Hero image עם preload

   תמונת hero עם <link rel="preload" as="image">. עוזר ל LCP.

5. width ו height attributes

   בכל תמונה. ל CLS.

6. aspect-ratio ב CSS

   שטח שמור לפני שהתמונה נטענת.

7. CDN לתמונות

   Cloudinary, Imgix, או Cloudflare Images. אופטימיזציה אוטומטית.

responsive images

<img
  src="image-800.webp"
  srcset="image-400.webp 400w,
          image-800.webp 800w,
          image-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="800" height="600"
  loading="lazy"
  alt="..."
/>

📜 JavaScript Optimization, ה INP killer

JavaScript הוא הסיבה העיקרית ל INP גרוע. כל script שאתם מוסיפים = עוד זמן ה main thread עסוק = עוד זמן עד שהדפדפן מגיב.

הצעדים

1. Code splitting

   אל תטענו את כל ה JavaScript בעמוד הבית. ב webpack/Next.js, dynamic imports.

2. Tree shaking

   הסרת קוד שלא בשימוש. הכלים המודרניים עושים אוטומטית.

3. Defer scripts

   scripts שלא קריטיים עם defer attribute. נטענים אחרי DOM.

4. Async scripts

   scripts בלתי-תלויים (analytics) עם async.

5. Lazy loading של components

   ב React, React.lazy(). ב Vue, async components.

6. Web Workers

   למשימות כבדות. ה main thread נשאר חופשי לאינטרקציות.

7. Hydration אופטימלית

   ב SSR, partial hydration או progressive hydration.

הגדולים שמאטים

• jQuery (אם לא חיוני)
• Bootstrap JS (אם משתמשים רק במעט קומפוננטים)
• Page builders כבדים (Divi, Elementor עם הרבה widgets)
• Analytics ו tag managers
• Chat widgets
• Social media embeds
• Heatmap tools (Hotjar, Clarity)

🎨 CSS Optimization, ה Critical Render Path

CSS חוסם rendering. הדפדפן מחכה ל CSS לפני שמציג תוכן. CSS גדול = LCP גרוע.

הצעדים

1. Critical CSS inline

   ה CSS הדרוש לתצוגה הראשונית, inline ב <style>. שאר ה CSS נטען async.

2. Minify CSS

   הסרת רווחים, comments. כלים, cssnano, csso.

3. Remove unused CSS

   PurgeCSS מסיר CSS שלא בשימוש. חוסך 50%+ ב הרבה אתרים.

4. הפרידו ל files לפי דרישה

   CSS ל עמוד הבית, ל קטגוריות, ל מוצרים. לא הכל ב file אחד גדול.

5. אל תשתמשו ב @import

   חוסם rendering. השתמשו ב <link> tags.

6. defer של CSS לא קריטי

   טכניקת media swap, <link rel="preload" href="..." as="style" onload="this.rel='stylesheet'">.

CSS Frameworks, הבעיה

Tailwind, Bootstrap, Materialize, כולם גדולים. עם PurgeCSS (Tailwind מובנה), אפשר להוריד מ 1MB ל 30KB.

🔤 Font Loading Strategy, להציל את ה LCP וה CLS

גופנים יכולים להרוס גם LCP וגם CLS. אם הגופן לא נטען, ה דפדפן מחכה (FOIT) או מציג גופן ברירת מחדל ואז מחליף (FOUT). שני המצבים גרועים.

הפתרון, font-display: swap

@font-face {
  font-family: 'MyFont';
  src: url('myfont.woff2') format('woff2');
  font-display: swap;
}

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

איך למנוע CLS מגופנים

1. השתמשו בגופן ברירת מחדל דומה בגודל וב metrics לגופן המותאם
2. השתמשו ב font-size-adjust ו size-adjust ב @font-face
3. השתמשו ב Adobe Fonts או Google Fonts עם font-display: swap מובנה
4. preload לגופנים קריטיים, <link rel="preload" as="font">
5. הפחיתו מספר variants (אם אתם משתמשים רק ב regular ו bold, אל תטענו את כל ה weights)

גופנים ב עברית

גופנים בעברית כבדים יותר (יותר תווים). השתמשו ב subsetting להוריד תווים שלא בשימוש. Heebo, Assistant, Open Sans Hebrew הם אופציות טובות.

🖥 TTFB, הגדרות שרת ו CDN

TTFB (Time To First Byte) הוא הזמן עד שהשרת מתחיל לשלוח את ה HTML. אם TTFB 800ms, LCP לא יכול להיות מתחת ל 1s. נקודה. אז שיהיה לכם TTFB טוב.

מה משפיע על TTFB

• איכות האחסון, shared hosting זול = TTFB גרוע
• מיקום השרת, שרת בארה"ב + גולש בישראל = 100-200ms latency
• שאלות database, שאילתות איטיות
• cache, אם אין cache, ה PHP נע על כל בקשה
• CDN, אם אין, כל בקשה ל שרת המקור
• SSL, handshake נוסף, 50-100ms

איך לשפר TTFB

1. אחסון איכותי

   VPS או Managed WordPress. הימנעו מ shared hosting זול.

2. שרת קרוב לקהל היעד

   אם הקהל בישראל, שרת באירופה לא בארה"ב.

3. Cache plugin

   WP Rocket, W3 Total Cache. שומר HTML מוכן.

4. CDN, Cloudflare

   חינמי. מציג HTML שמור מ נקודה קרובה למשתמש. חוסך 100-300ms.

5. HTTP/2 או HTTP/3

   פרוטוקול מהיר יותר. רוב האחסונים תומכים.

6. אופטימליות database

   indexes, queries מהירות, ניקוי DB.

📊 Real User Monitoring (RUM)

Lab tools נותנים תמונה אחת. RUM (Real User Monitoring) נותן את האמת מ משתמשים אמיתיים.

למה RUM חשוב

• הקהל שלכם משתמש במכשירים שונים, רשתות שונות, מיקומים שונים
• Lab tools רצים על מכשיר אחד, רשת אחת, מיקום אחד
• RUM אוסף נתונים מ כל הגולשים שלכם, אגרגציה ל אחוזון 75
• גוגל משתמש ב RUM ב CrUX, ככה הוא מודד את CWV

כלים

web-vitals JavaScript library

Google מספקת library חינמית שמודדת CWV ב browser המשתמש. אפשר לשלוח את הנתונים ל GA4 או לכלי אחר.

import {onLCP, onINP, onCLS} from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

💼 איך לדבר עם המפתח שלכם על CWV

אתם מקדם SEO. המפתח של הלקוח לא רוצה לשמוע "האתר איטי". צריך לדבר אחרת.

הצעדים

1. נתוני אמת

   השתמשו ב PSI עם Field data. הראו את הציון. הראו את ה specific metric שלא טוב.

2. השפעה עסקית

   "LCP של 5s = bounce rate עולה ב 30%". המפתח מבין מספרים עסקיים.

3. בקשה ספציפית

   לא "תאיץ את האתר". "תאופטמז את תמונת ה hero, היא 3MB". פעולה קונקרטית.

4. תיעדוף

   תנו לו רשימה מסודרת לפי impact. תמונות > CSS > JS > שרת.

5. מדידה אחרי

   אחרי שינויים, מודדים שוב. הראיתם תוצאות, יש motivation להמשיך.

טבלת תיעדוף

🎯 Budget per page type, התקציב לכל סוג עמוד

לא כל עמוד צריך להיות באותה ביצועים. אבל לכל עמוד צריך budget. הנה ה standards שלי.

איך לאכוף budget

• הגדירו את ה standards לפני שמתחילים פיתוח
• הריצו Lighthouse ב CI/CD, חסום deploys אם budget נחרג
• השתמשו ב BundleAnalyzer ב webpack לראות מה גודל
• מעקב חודשי, באתר חי, האם הציונים יורדים?

✅ צ'ק ליסט CWV מקיף

תקשיבו. אם רוצים להתחיל מחר ולתקן את ה CWV של האתר, הנה הרשימה. אחת אחת.

אבחון

• הריצו PageSpeed Insights על 5-10 עמודים מרכזיים
• רישמו את LCP, INP, CLS לכל אחד
• סמנו אילו בירוק, צריך שיפור, אדום
• בדקו ב Search Console > Core Web Vitals report
• זהו את הבעיות הגדולות (תמונות? JS? שרת?)

LCP

• אחסון מהיר (TTFB < 200ms)
• CDN פעיל (Cloudflare)
• תמונת hero אופטימלית (WebP, גודל מתאים)
• Preload של hero image
• Critical CSS inline
• הסרת JavaScript חוסם ב head

CLS

• תמונות עם width ו height
• גופנים עם font-display: swap
• שטח שמור לפרסומות
• iframes עם dimensions
• אין תוכן שמופיע מעל תוכן קיים

INP

• חלוקת פונקציות ארוכות
• Web Workers למשימות כבדות
• Defer scripts לא קריטיים
• debounce/throttle על event handlers
• Lazy loading של components

שרת ו CDN

• אחסון איכותי (לא shared hosting זול)
• Cache plugin פעיל
• CDN מוגדר נכון
• HTTP/2 או HTTP/3
• HTTPS עם handshake מהיר (OCSP stapling)

תחזוקה שוטפת

• בדיקה חודשית של CWV ב Search Console
• בדיקה אחרי כל deploy גדול
• מעקב ב GA4 על CWV events
• תיקון בעיות תוך 30 יום

❓ שאלות נפוצות