Core Web Vitals 2026: nowe progi i INP

Core Web Vitals 2026 to zupełnie inne wymagania niż jeszcze w 2022 roku. Od marca 2024 INP (Interaction to Next Paint) zastąpił FID jako trzeci Core Web Vital. Progi zostały zaostrzone — Good LCP to teraz 2.5s, INP poniżej 200ms, CLS poniżej 0.1. Google wyraźnie karze strony z Poor CWV, zwłaszcza na mobile.

Ten przewodnik to pełny stan Core Web Vitals 2026 — czym się zmieniły progi, jak INP różni się od FID, które strony mają największe problemy, plus konkretne techniki optymalizacji dla WordPress, SPA i custom frontendów.

Trzy Core Web Vitals 2026

LCP — Largest Contentful Paint

Czas do zrenderowania największego elementu widocznego w viewport (zwykle hero image, H1, video thumbnail). Mierzy perceived loading speed.

• Good: ≤ 2.5s.
• Needs improvement: 2.5–4.0s.
• Poor: > 4.0s.

INP — Interaction to Next Paint (2024+)

Nowy CWV od marca 2024, zastąpił FID (First Input Delay). Mierzy responsiveness dla WSZYSTKICH interactions (nie tylko first), pokazując 98th percentile delay między user input a next visual update.

• Good: ≤ 200ms.
• Needs improvement: 200–500ms.
• Poor: > 500ms.

CLS — Cumulative Layout Shift

Suma niespodziewanych layout shifts — gdy tekst/obrazek nagle się przesuwa po załadowaniu innego elementu. Mierzy visual stability.

• Good: ≤ 0.1.
• Needs improvement: 0.1–0.25.
• Poor: > 0.25.

INP vs FID — co się zmieniło

FID mierzył tylko FIRST interaction (zazwyczaj click) i tylko delay do start JS handlera. INP mierzy WSZYSTKIE interactions i pełen czas do next visual update.

Konsekwencje tej zmiany

1. Ostrzej dla SPA — React/Vue/Angular apps często mają slow handlers przy kolejnych klikach, FID tego nie widział.
2. Third-party scripts boją się — chat widgets, heatmaps, ads mogą blokować main thread po initial load.
3. Niektóre strony Good w FID są Poor w INP — szczególnie ecommerce z carousel, filtry, search widgets.

Debug INP

Chrome DevTools → Performance panel → nagraj interakcję → sprawdź „Interactions” track. Długie handlers (> 50ms) oznaczają ryzyko. Narzędzie: web-vitals library, Lighthouse 10+, PageSpeed Insights field data.

Field data vs lab data — kluczowa dystynkcja

Field data (CrUX)

Chrome User Experience Report — real user data zbierane od użytkowników Chrome (opted-in). To jest to, co Google waży w rankings.

• Dostępne w: PageSpeed Insights (section „Real-Experience”), Search Console Core Web Vitals report.
• Minimum data: 28 days, pewna liczba visitors.
• Agregat: 75th percentile musi być w Good threshold.

Lab data

Symulacja w controlled environment. Useful dla diagnostyki, ale nie odzwierciedla realnego user experience.

• Dostępne w: Lighthouse, PageSpeed Insights (sekcja „Lab”), WebPageTest.
• Szybkie (kilka sekund), reproducible.
• Różni się od field — lab na Moto G Power 4G, field na różnych devices.

Rekomendacja

Diagnostyka: lab (szybki feedback loop). Decyzje o wdrożeniach: field (co real users widzą). Sprawdzaj oba regularnie.

Optymalizacja LCP — 8 technik

1. Preload hero image — <link rel="preload" as="image" fetchpriority="high">.
2. Właściwe formaty — WebP dla większości, AVIF dla nowszych przeglądarek.
3. Responsive images — srcset + sizes dla device-appropriate sizes.
4. Server-side rendering dla SPA — LCP element w HTML od razu, nie po JS.
5. Critical CSS inline — no render-blocking external CSS dla above-the-fold content.
6. Font-display: swap + preload najważniejszych fonts.
7. CDN — Cloudflare, KeyCDN dla geo reach.
8. Backend optymalizacje — TTFB < 400ms (hosting, DB queries, cache).

Optymalizacja INP — 7 technik

1. Break long tasks — split JS handlers (> 50ms) na smaller chunks z setTimeout(fn, 0) albo requestIdleCallback.
2. Defer third-party scripts — chat, ads, analytics → load after main content (idle time).
3. Virtualize long lists — react-window, react-virtualized dla listów > 100 items.
4. Debounce / throttle — input handlers, scroll events.
5. Web Workers dla heavy computation poza main thread.
6. Optimistic UI — reaguj UI natychmiast, sync server w tle.
7. Lazy imports — code-splitting components, żeby initial bundle był mniejszy.

Optymalizacja CLS — 6 technik

1. Width/height na images — zawsze. Przeglądarka rezerwuje miejsce.
2. Aspect-ratio CSS dla video, iframes (aspect-ratio: 16/9).
3. Reserve space dla ads — minimum height container przed ad loads.
4. Font fallbacks — podobny metric do web font (avoid FOIT/FOUT shifts).
5. Bez injected content powyżej istniejącego (np. dynamic banners, cookie notices na top).
6. Skeleton screens — reserve space dla content ładowanego async.

Jak monitorować CWV systematycznie

Narzędzia monitoringu

• Google Search Console — Core Web Vitals report (field data, 28-day).
• PageSpeed Insights — per URL check (field + lab).
• Lighthouse CI — automated lab tests w CI/CD pipeline.
• web-vitals library — real user monitoring z JS w twojej stronie, send to GA4/custom endpoint.
• Calibre, SpeedCurve, DebugBear — enterprise RUM + lab monitoring.
• Cloudflare Web Analytics — basic CWV monitoring z CDN level.

Cadence

• Daily: top 10 URL-ów lab check (PSI API + automation).
• Weekly: Search Console CWV report review.
• Monthly: Deep dive z RUM data (web-vitals library agg).
• Per release: Lighthouse CI w pipeline, blok deployment jeśli regression.

CWV jako ranking factor — ile to waży

Google oficjalnie: CWV jest ranking signal, ale stosunkowo lekki. W praktyce:

• Dla stron z Poor CWV mobile: -5% do -15% organic rankings (nasze audits 2023–2026).
• Dla stron z Good CWV mobile: neutralny lub +3% lift (tie-breaker signal).
• Dla stron z mieszanymi CWV (Good desktop, Poor mobile): Google uses mobile-first, więc Poor mobile = Poor w rankingu.

Większy impact: user experience

CWV wpływa bezpośrednio na user signals:

• Conversion rate: każde 0.5s opóźnienia LCP = -7% do -15% conversion.
• Bounce rate: slow INP zwiększa bounce o 10–25%.
• Session duration: poor CWV = krótsze sesje.
• Returns: niższa retention, lower LTV.

Indirect ranking impact przez user signals może być większy niż direct CWV signal.

Przykład praktyczny: e-commerce fashion, 6 miesięcy CWV

Klient: sklep odzieżowy, baseline 40% URL-ów w Poor na mobile, LCP medium 4.1s, INP medium 380ms, CLS 0.18.

Interwencje

1. LCP: hero images — konwersja do WebP, lazy load below-fold, preload top fold.
2. INP: third-party chat widget → lazy load po 3s idle, filter handlers → debounce + virtualize product list.
3. CLS: wszystkie img z width/height, cookie consent → bottom banner zamiast top injection.
4. Hosting: migracja z shared (TTFB 800ms) do Cloudways DO (TTFB 180ms).
5. Third-party review widget: replace Yotpo (500KB JS) z Trustpilot (120KB).
6. Font loading: preload 2 wags woff2, reszta fallback.

Wyniki po 6 miesiącach (field data)

• LCP mobile median: 4.1s → 1.9s.
• INP mobile median: 380ms → 140ms.
• CLS mobile median: 0.18 → 0.04.
• % URL w Good: 28% → 91% (mobile).
• Mobile conversion rate: +34%.
• Bounce rate: -18%.
• Organic traffic mobile: +22% (6 miesięcy).

Więcej o konkretnych metrykach: LCP, INP, CLS — co naprawdę wpływa na wyniki.

Pułapki i częste błędy

Pułapka 1: optimizing dla lab nie dla field

PageSpeed Insights Performance 98/100 w lab, ale field data pokazuje Poor LCP 3.8s. Lab nie odzwierciedla real devices i networks. Field data jest ranking signal.

Pułapka 2: ignorowanie INP

„FID było OK, CWV pass”. Ale FID wyłączony od marca 2024, INP is tougher. Wielu strony pass FID, fail INP.

Pułapka 3: third-party scripts nieopanowane

Chat widget, 3 ad networks, 2 heatmap tools, session replay. Razem 400ms blocking time. Audyt third-party i eliminuj/defer.

Pułapka 4: obrazki bez dimensions

Responsive design bez width/height → CLS. Nawet przy max-width CSS, przeglądarka nie wie jaką wysokość zarezerwować.

Pułapka 5: SSR wycofane dla „szybszej iteracji”

Migracja z Next.js SSR do full CSR React — prostsze dla deweloperów, ale LCP wzrasta z 2s do 5s (bo user musi ściągnąć + parse + render JS przed LCP element).

Pułapka 6: ignorowanie mobile

„Desktop PSI 95, ok”. Google używa mobile-first indexing. Mobile CWV jest tym, co się liczy. Audit mobile osobno.

Narzędzia

• Field data: Google Search Console Core Web Vitals, PageSpeed Insights, CrUX Dashboard.
• Lab data: Lighthouse (Chrome DevTools), PageSpeed Insights lab, WebPageTest.
• RUM: web-vitals library (open source), Calibre, SpeedCurve, DebugBear.
• CI/CD: Lighthouse CI, Google web-vitals action.
• Profiling: Chrome DevTools Performance panel, Firefox Profiler.
• Image optimization: ShortPixel, Imagify, Squoosh, Cloudinary.
• Font optimization: Google Fonts + self-host, fontsquirrel subsetter.

FAQ — najczęstsze pytania

Czy CWV ma większy impact niż content quality?

Nie. Content quality (relevance, E-E-A-T, depth) jest znacznie ważniejszy niż CWV. CWV to tie-breaker signal dla stron o podobnej jakości content. Optymalizacja: primary — content quality, secondary — CWV. Strona z Excellent content i Poor CWV rankuje lepiej niż Good content + Good CWV, przy wszystkim innym równym.

Jak często zmieniają się CWV standardy?

Znacząco: 2020 (wprowadzenie CWV z LCP, FID, CLS), 2022 (INP jako experimental), 2024 (INP replace FID jako official CWV). Wynik: co 2–3 lata major zmiana. Aktualnie w 2026 Google ewaluuje dalsze metryki (Interaction to Last Paint — ILP, potencjalne replace INP w 2027–2028). Monitor Chrome Dev blog dla preview changes.

Czy server speed (TTFB) jest CWV?

TTFB nie jest oficjalnym CWV, ale jest fundamentem dla LCP. Jeśli TTFB = 1s, LCP nie może być < 1s (fizyczna niemożliwość). Target TTFB < 400ms dla wszystkich stron. Dla stron z TTFB > 800ms — nawet perfect frontend optimization nie pomoże osiągnąć Good LCP. Hosting decyduje.

Czy Single Page Applications mogą osiągnąć Good CWV?

Tak, ale wymaga dodatkowej pracy. Optymalne podejście: SSR (Next.js, Nuxt, SvelteKit) lub SSG (static generation). CSR-only React/Vue/Angular ma typowo Poor LCP z dużym JS bundle. W 2026 92% high-performing SPA używa SSR lub Island architecture (Astro, Remix). Pure CSR to legacy approach.

Czy AMP to rozwiązanie dla CWV?

W 2026 AMP jest praktycznie dead dla większości use-cases. Google usunął AMP requirement dla Top Stories w 2021, i AMP nie daje już ranking boost. Lepsze: well-optimized responsive site (SSR) — ma lepsze CWV niż AMP i pełną kontrolę nad UX. Wyjątek: niektóre mobile news sites wciąż AMP dla speed.

Czy lazy loading zawsze pomaga?

Nie zawsze. Lazy load hero image (above-the-fold) → opóźnia LCP, zamiast przyspieszać. Reguła: lazy load tylko below-the-fold. Pierwsza-drugi hero image → eager load + preload + fetchpriority=”high”. Natywne loading="lazy" dobre dla below-fold images, ale nigdy dla LCP element.

Czy INP problemami rozwiązują się same po frameworku upgrade?

Częściowo. React 18 (concurrent mode), Vue 3, modern Angular — wszystkie poprawiają INP z box. Ale: własny kod (long event handlers, non-optimized state updates) może być bigger issue niż framework. Framework upgrade + targeted refactoring handlers = realny improvement. Samo upgrade nie wystarczy.

Co dalej

Start: CWV audit z PageSpeed Insights dla top 10 URL-ów (lab + field). Priorytetyzuj największe issues per URL (zwykle LCP albo INP). 30-dniowy fix plan, monitoring przez 3 miesiące żeby zobaczyć field data trends.

Kolejne kroki: (1) jak przyspieszyć WordPress pod CWV — jeśli jesteś na WP, (2) LCP, INP, CLS — co naprawdę wpływa na wyniki — głęboki dive w metryki, (3) audyt SEO 2026 — CWV jako część pełnego audytu.

Pełen kontekst w przewodniku SEO 2026 — CWV to jedna z kilku warstw technical SEO, ale jedna z najłatwiejszych do mierzenia i audit.