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. Więcej o tym zagadnieniu znajdziesz w jak przyspieszyć WordPress pod CWV.

• 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 Wnioski field data. Zagadnienie to omawiamy szerzej w audyt SEO 2026.

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. Zagadnienie to omawiamy szerzej w przewodniku SEO 2026.

• Dostępne w: PageSpeed Wnioski (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 Wnioski (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 Wnioski – per URL check (field + lab).
• Lighthouse CI — automated lab tests w CI/CD ciąg procesów.
• 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: Pogłębiona analiza z RUM data (web-vitals library agg).
• Per release: Lighthouse CI w ciąg procesów, 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% konwersja.
• 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 Wnioski 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.

Case studies – rzeczywiste przykłady optymalizacji

Case 1: polski e-commerce fashion — LCP z 4,8s do 1,9s

Sklep z odzieżą z 85 000 URL-ów (produkty + kategorie) miał średnie LCP 4,8s (Poor) i tylko 12% URL-ów w Good bucket w Google Search Console. Problemy: unoptimized hero images (JPEG 850KB), legacy CDN z europejskich only, blocking JS w head (~1,2s), render-blocking fonts.

• Akcja 1: migracja na Cloudfront z global edge + automatic image optymalizacja (AVIF format) → hero image z 850KB → 95KB, LCP -1,4s.
• Akcja 2: inline critical CSS (14KB), defer non-critical JS, preload hero image → LCP -0,8s.
• Akcja 3: self-host Google Fonts z font-display: swap, preload woff2 → LCP -0,3s.
• Akcja 4: database query optymalizacja (indexy na product_id, caching categorii) → TTFB z 620ms na 180ms → LCP -0,4s.
• Rezultat po 10 tygodniach: average LCP 1,9s (Good), 81% URL w Good bucket (+69 pkt), organic traffic +28%, conversion rate +14%.
• Koszt: 38 000 PLN (8 tygodni × 1 FTE dev + Cloudfront migration).

Case 2: B2B SaaS – INP z 380ms do 140ms

Dashboard SaaS (React 17, legacy codebase) miał INP 380ms (Poor) — skargi użytkowników o „lagging” UI. Audit pokazał: ogromny Redux store (150MB in memory), synchronous state updates blocking main thread na 200+ms per interaction.

• Akcja 1: migracja na React 18 z concurrent rendering → INP -80ms.
• Akcja 2: refactor state management (Redux → Zustand + TanStack Query) → smaller bundle + async state updates → INP -100ms.
• Akcja 3: code splitting per route (lazy() + Suspense) → initial bundle z 840KB na 220KB.
• Akcja 4: debounce na heavy computations (filtering tables, chart rendering) → INP -60ms.
• Rezultat po 6 tygodniach: INP 140ms (Good), user satisfaction survey score z 3,2 na 4,4 (5-point scale), churn reduction 18% YoY.

Case 3: portal content / blog — CLS z 0,28 do 0,05

Blog newsowy (WordPress, 1200 artykułów, 800k sesji/mies.) miał CLS 0,28 (Poor). Source: ads dynamic inject bez reserved space, late-loading images bez dimensions, cookies banner pop-up z layout shift.

• Akcja 1: ad slot fixed heights (min-height CSS) → CLS -0,12.
• Akcja 2: dodanie width/height atrybutów do wszystkich img → CLS -0,07.
• Akcja 3: cookies banner jako overlay (position: fixed) bez wypychania contentu → CLS -0,04.
• Rezultat: CLS 0,05 (Good), średni bounce rate -8%, average time on page +22%.

CWV: SME vs enterprise – różne strategie

Wymiar	SME (1–100 URL)	Mid-market (100–10k)	Enterprise (10k+)
Audit frequency	Miesięcznie	Tygodniowo	Real-time RUM + daily reports
Tooling	PSI free, Lighthouse	Lighthouse CI + SpeedCurve	Calibre, DebugBear, custom RUM
Budżet optymalizacji	0–15k PLN	15–80k PLN	100k+ PLN
Zespół	1 dev part-time	1 FTE frontend	Performance team (3-5 FTE)
Priority metrics	LCP + CLS	LCP + INP + CLS	All + business correlation

Optymalizacja CWV dla WordPress – konkretny plan

Około 45% polskich sites działa na WordPress. Typowy WP site out-of-the-box ma LCP 3,5–5,5s. Poniższy plan to realistyczny roadmap do Good CWV.

Tydzień 1: hosting i server

• Migracja z shared hosting na managed WP (Kinsta, WP Engine, cloudways) lub VPS (Hetzner, DigitalOcean).
• Target TTFB < 400ms — jeśli hosting nie dowiezie, zmieniaj.
• PHP 8.2+ (wydajność +15–25% vs PHP 7.4).
• HTTP/3 enabled (LiteSpeed, Nginx 1.25+).

Tydzień 2: caching i CDN

• Page cache: W3 Total Cache, WP Rocket, LiteSpeed Cache.
• Object cache: Redis lub Memcached.
• CDN: Cloudflare (darmowe), BunnyCDN (1–5 USD/mies.), KeyCDN.
• Image CDN z AVIF/WebP auto-konwersja (Cloudflare Images, BunnyCDN Optimizer).

Tydzień 3: frontend optymalizacja

• Defer non-critical JS (Autoptimize, FlyingPress).
• Critical CSS inline (Autoptimize Pro, CriticalCSS.com).
• Preload hero image + fetchpriority=”high” w HTML.
• Eliminate render-blocking fonts (font-display: swap, preload woff2).
• Lazy load below-fold images z loading=”lazy”.

Tydzień 4: wtyczki i database

• Audit aktywnych wtyczek – usuń nieużywane (typowo 5–10 wtyczek do usunięcia).
• Replace heavy wtyczki lighterszymi alternatywami (np. Elementor → GenerateBlocks).
• Database cleanup: WP-Optimize, wyczyść post revisions, trashed posts, transients.
• Indeksy na wp_postmeta (szczególnie dla WooCommerce sites z 10k+ produktami).

Zespół i proces – jak utrzymywać Good CWV

Role w organizacji

• Frontend performance engineer (od mid-market) – owns CWV metrics, runbook optymalizacja, PR reviews pod kątem performance. Skills: Lighthouse, Chrome DevTools, Webpack/Vite, framework-specific optymalizacje.
• DevOps / SRE — monitoring infrastruktury, hosting, CDN, cache strategies.
• SEO analyst – śledzi korelację CWV vs. ranking/traffic, prioryzuje URLs by business impact.
• Design / UX – early stage preventive – nie projektuje UI, który gwałci performance budżet.

Performance budżet i CI/CD

1. Ustal performance budżet per URL template (np. homepage: LCP < 2s, blog: LCP < 2,5s, product page: LCP < 2,2s).
2. Lighthouse CI w ciąg procesów — każdy PR testowany przeciw budżet.
3. Fail build jeśli regression > 10% na kluczowych URL-ach.
4. Weekly performance review – team analyzes trends, plans optymalizacja sprints.
5. Monthly exec report – correlation CWV z business metrics (konwersja, przychód).

Narzędzia

• Field data: Google Search Console Core Web Vitals, PageSpeed Wnioski, CrUX Dashboard.
• Lab data: Lighthouse (Chrome DevTools), PageSpeed Wnioski 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 optymalizacja: ShortPixel, Imagify, Squoosh, Cloudinary.
• Font optymalizacja: Google Fonts + self-host, fontsquirrel subsetter.

Pogłębiona analiza INP – nowa metryka zamiast FID

INP (Interaction to Next Paint) to metryka, która weszła jako oficjalny CWV w marcu 2024, zastępując FID. Kluczowa różnica: FID mierzył tylko opóźnienie pierwszego kliknięcia; INP mierzy worst-case responsiveness przez całą sesję.

Jak INP jest kalkulowany

1. Przeglądarka monitoruje wszystkie interakcje użytkownika (click, tap, keyboard input).
2. Dla każdej interakcji mierzy czas od input do następnego paintu (DOM update widoczny w UI).
3. INP dla sesji = 98-percentyl z wszystkich interakcji (dla sesji 50+ interakcji) lub worst 1–2 interakcje (dla krótkich sesji).
4. Aggregate INP dla CWV = 75-percentyl URL-i (pole danych z CrUX).

Typowe problemy obniżające INP

• Long event handlers – click handler że 200+ms logic (filtering, calculations, state updates).
• Synchronous state updates (React < 18, legacy Redux) blokują main thread.
• Heavy third-party scripts (ad networks, chat widgets) competing o main thread.
• Unoptimized tables/lists z 1000+ rows render na każdej interakcji.
• CSS animations wykorzystujące layout properties (left, top, width) zamiast transform/opacity.

Techniki optymalizacji INP

1. Task yielding – rozbicie długich tasków na mniejsze z yield (scheduler.yield() API).
2. Debounce heavy actions – wyszukiwanie po 300ms bez nowego keystroke’u, nie per-keystroke.
3. Virtualization dużych list — TanStack Virtual, react-window, render tylko visible rows.
4. Web Workers dla CPU-intensive tasks – offload z main thread.
5. Concurrent rendering (React 18 startTransition, Vue 3 async components).

Business impact – jak CWV wpływa na przychód

CWV to nie techniczna ciekawostka – to mierzalne driver biznesowy. Poniżej konkretne metryki z real-world studies.

Impact na conversion rate

• Amazon: 100ms poprawa latency = 1% wzrost sprzedaży (dokumentowane od 2006, trend consistent).
• Walmart: LCP redukcja z 4s na 1s = 2% conversion rate increase per 1s improvement.
• Vodafone: LCP improvement 31% przełożył się na 8% wzrost w sales.
• Polski e-commerce (agregat 12 sklepów): każde 0,5s improvement w LCP = 3–7% conversion rate lift.

Impact na bounce rate

• LCP > 3s vs. LCP < 1s – bounce rate różnica 22 pkt (32% vs. 10%).
• INP > 500ms → users percepują site jako „broken” — 40%+ pozycji mobile users back-out.
• CLS > 0,25 → rage-clicks i mis-clicks zwiększają się 3–5x, frustracja mierzalna w NPS.

Impact na SEO rankings

• CWV jest ranking factor od 2021 (Page Experience Update).
• Impact: tie-breaker signal – strony o podobnej content quality, Good CWV wygrywa.
• Differential w SERP: top-3 positions mają typowo 85%+ URL w Good, pozycje 10–20 tylko 45%.
• Quantified: 1-click improvement (z Poor na Good CWV) = 2–5 pozycji w SERP w konkurencyjnych keywords.

Integracja CWV monitoring z stackiem

CWV + GA4

Custom dimension web_vitals w GA4, wysyłane przez web-vitals library (opensource, 3KB). Dashboard: LCP trend per page, INP per user segment, korelacja CWV z conversion rate. Code snippet do wdrożenia:

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

function sendToGA4(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.value),
    metric_rating: metric.rating,
    metric_id: metric.id,
  });
}

onCLS(sendToGA4);
onINP(sendToGA4);
onLCP(sendToGA4);

CWV + CRM / business data warehouse

Join CWV data (per URL × per day × per device) z business metrics (konwersja, przychód) w BigQuery. Correlation analysis: identify URLs gdzie improvement CWV najbardziej impacts business. Priority list na optymalizacja backlog.

CWV + alerting (Slack, PagerDuty)

• Alert na spike LCP > 30% WoW na crucial URLs (homepage, checkout, top category pages).
• Alert na INP regression po deployment.
• Weekly digest z top 5 URL-ów z najgorszym CWV (candidates do optymalizacja).

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. Pełen obraz tematu znajdziesz w kompletnym przewodniku seo 2026.

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 optymalizacja 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.

Jak Core Web Vitals wpływają na Google Ads Quality Score?

Bezpośrednio, przez Landing Page Experience component. Wolny landing (LCP > 4s, INP > 500ms) = Below average landing page experience = lower Quality Score = higher CPC. W Q1 2026 benchmarki polskich kont Google Ads: landingi z Good CWV mają średnio 28% niższy CPC przy tym samym bidding. Optymalizacja CWV dla landing pages PPC zwraca się w 2–4 tygodnie przez niższy CAC.

Jaki jest koszt ignorowania CWV dla e-commerce?

Kalkulacja dla typowego sklepu z 100k sesji/mies., conv rate 2,5%, AOV 280 PLN (przychód 700k PLN/mies.): poprawa LCP o 1s = +3–5% conv rate = +21–35k PLN/mies. = +250–420k PLN/rok. Koszt optymalizacji: 30–80k PLN one-time. ROI: 3–10x w pierwszym roku. Ignorowanie CWV to leaving money on the table – dla każdego miesiąca zwłoki tracisz kilkadziesiąt tysięcy.

Czy warto używać AMP w 2026 dla CWV?

Nie dla większości. Google od 2021 nie wymaga AMP dla Top Stories ani innych features. Well-optimized responsive site ma lepsze CWV niż AMP (AMP ma własne limity JS/CSS, które mogą ograniczać UX). Wyjątki: (1) legacy news sites gdzie migracja ze AMP kosztowna; (2) mobile-only sites z bardzo ograniczonym budżetem dev. Nowe projekty: zawsze standard modern framework (Astro, Next.js, Nuxt), nie AMP.

Optymalizacja CWV per framework – konkretne zalecenia

Next.js (React)

• App Router (Next.js 13+) z React Server Components – mniejszy bundle JS na client.
• next/image z automatyczną AVIF/WebP + lazy loading.
• next/font dla self-hosted fonts z optymalizacją.
• Streaming SSR + React Suspense dla progressive rendering.
• Route-level code splitting natywnie.

Nuxt (Vue)

• Hybrid rendering (SSG + SSR + ISR) dopasowany per route.
• nuxt/image moduł z optymalizacją.
• Payload extraction – separate JSON payload dla hydratacji.
• Lazy hydration — hydrate komponenty on-demand.

Astro

• Zero JS default – perfect dla content-heavy sites.
• Island architecture – hydratacja tylko interactive components.
• Typically LCP < 1,5s bez optymalizacji na simple static sites.
• Najlepszy wybór dla blogów i marketing sites w 2026.

Remix

• Nested routing z parallel data loading – szybsze TTFB.
• Progressive enhancement – działa bez JS dla simple interactions.
• Built-in prefetch na Link components.

Legacy frameworks (jQuery, Bootstrap, starsze React)

• Progressive upgrade – nie trzeba rewrite, ale refactor crucial components.
• Dodaj Image CDN natychmiast (Cloudflare Images, ImageKit).
• Redukuj wtyczki/libraries do minimum.
• Consider headless CMS + modern frontend (Astro/Next) dla long-term.

Roadmap 90-dniowy dla pełnej transformacji CWV

Miesiąc 1: baseline i quick wins

1. Tydzień 1: audit wszystkich URL templates (homepage, category, product, article, etc.) w PSI field data + lab.
2. Tydzień 2: install RUM (web-vitals library + GA4 lub Calibre).
3. Tydzień 3: quick wins — image optymalizacja (hero images, top 10 URL), preload critical resources, remove unused JS.
4. Tydzień 4: database/hosting audit – TTFB improvements, cache layer.

Miesiąc 2: strukturalne optymalizacje

1. Tydzień 5–6: code splitting, lazy loading (below-fold only), critical CSS inline.
2. Tydzień 7: third-party audit — remove/defer non-critical, consolidate analytics.
3. Tydzień 8: INP deep-dive – refactor heavy event handlers, introduce task yielding.

Miesiąc 3: monitoring i continuous improvement

1. Tydzień 9: Lighthouse CI w ciąg procesów, performance budżety per template.
2. Tydzień 10: alerting setup – Slack notifications, weekly exec reports.
3. Tydzień 11: team training — dev onboarding na performance principles.
4. Tydzień 12: retrospektywa — zmierz ROI (CWV improvement, organic traffic, konwersje).

Realistyczne oczekiwanie: po 90 dniach 70–90% URL w Good bucket (z typowo 15–30% przed). Business impact widoczny 60–120 dni po zakończeniu improvements (Google indeksuje nowe CrUX data i koryguje rankingi).

Ważne: CWV improvements wymagają disciplined maintenance. Bez performance budżet + CI/CD enforcement regressions pojawią się w 3–6 miesięcy (new feature adds 200KB JS, new śledzenie tool dodaje 300ms blocking time). 90% sukcesu to utrzymanie wyników, nie jednorazowa optymalizacja.

Dla najbardziej ambitnych zespołów – cel „Excellent” CWV (LCP < 1,5s, INP < 100ms, CLS < 0,05) możliwy dla content sites na Astro/Next z properly configured CDN. Dla e-commerce z product search i filtering: realistyczny target LCP 1,8–2,2s, INP 150–180ms.

Ostatnia uwaga: CWV to żywa dziedzina, Google zmienia metryki i thresholds co 2–3 lata. INP zamiast FID w 2024, potencjalnie ILP zamiast INP w 2027. Zespół, który budował proces pod CWV, radzi sobie z tymi zmianami znacznie szybciej niż ten, który każdorazowo robi sprint od zera. Inwestycja w fundamenty performance engineering – sensible architecture, RUM monitoring, CI/CD enforcement – płaci się niezależnie od tego, jakie konkretne metryki Google wybierze w przyszłości.

Top 10 błędów przy optymalizacji CWV

1. Optymalizacja na lab data, ignorowanie field data – Lighthouse 95 score, ale user experience is różny. Zawsze monitoruj CrUX/RUM.
2. Single-page optymalizacja — fix homepage, ignore pozostałe 10 000 URL-ów. Optymalizuj templates, nie pojedyncze strony.
3. Lazy loading wszystkiego — w tym LCP element. Hero image musi być eager + preloaded.
4. Over-optymalizacja dla mobile, zaniedbanie desktop (lub odwrotnie). Monitor oba, różne URL templates mają różne user devices.
5. Ignorowanie third-party scripts – chat widget + 3 analytics + 5 ad networks to główny culprit INP regressions.
6. Cached lab scores jako ground truth — Lighthouse CI z cached versions nie oddaje real user experience.
7. Optymalizacja bez performance budżet – dev team dodaje feature który regresses LCP by 0,4s, „tylko trochę”. Budżet enforcement crucial.
8. Brak alerting – regression pojawia się, nikt nie widzi 3 miesiące, aż Search Console pokaże spadek.
9. Optymalizacja CWV bez koordynacji z SEO — improve LCP, ale zmniejsz content quality → ranking spada.
10. Ignorowanie progresu Google – w 2024 FID → INP. Kolejne zmiany w 2026+ (potencjalnie ILP). Monitor i adaptuj.

Co dalej

Start: CWV audit z PageSpeed Wnioski 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. Equally ważne: zaplanuj maintenance structure od początku — weekly review, monthly exec reports, quarterly deep audits.

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. Wszystkie trzy kierunki warte są dedicated czasu, jeśli CWV to priorytet w Twoim zespole.

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