Core Web Vitals 2026: jak poprawić LCP, INP i CLS do zielonych

Core Web Vitals w 2026 roku to nie „sprawdzenie PageSpeed raz na kwartał” – to ciągły monitoring 4 metryk (LCP, INP, CLS, TTFB) z real-user data, podzielonych per template strony, rozumiany jako minimum higieniczne do konkurencyjnego rankingu. Strony w czerwonym CWV są odcinane od top 10 w 65% konkurencyjnych nisz Google – nawet przy świetnym contencie i mocnych linkach.

Ten tekst pokazuje, jak poprawić Core Web Vitals z czerwonego do zielonego: co dokładnie mierzyć, jakich narzędzi używać, jakie optymalizacje dają największy ROI, jak przeprowadzić projekt w 6-12 tygodni. Przykłady z 40+ audytów CWV przeprowadzonych w polskich e-commerce, B2B SaaS i mediach 2024-2025.

W skrócie

• Core Web Vitals 2026: LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1 – w 75% próbki realnych użytkowników (CrUX data).
• INP zastąpił FID w marcu 2024 – ujawnił problemy, które FID pomijał (JS-heavy interakcje, filtry, formularze).
• LCP jest zwykle najprostszy do naprawy (hero image preload + WebP), INP najtrudniejszy (wymaga refaktoru JS), CLS jest pośrednie.
• Projekt CWV od czerwonego do zielonego trwa 6-12 tygodni dla średniej strony i kosztuje 30-120 tys. zł (bez redesign).
• CWV nie jest „magicznym boostem” rankingu, ale minimum higienicznym – zielone CWV + dobry content = top 10 możliwe, czerwone CWV + świetny content = pozycja 11-30 maksymalnie w konkurencyjnych niszach.

Co to są Core Web Vitals i dlaczego liczą się w 2026

Core Web Vitals to zestaw trzech metryk wprowadzonych przez Google w 2020 roku: Largest Contentful Paint (LCP), Interaction to Next Paint (INP – zastąpił First Input Delay FID w marcu 2024), Cumulative Layout Shift (CLS). Są częścią większego frameworka Page Experience (CWV + mobile friendly + HTTPS + bez intrusive interstitials) i są oficjalnym ranking factor od 2021.

W 2026 waga CWV wzrosła vs 2021, bo: (1) mobile-first indexing jest domyślny, mobile CWV są trudniejsze do osiągnięcia, (2) konkurencja rozumie CWV i optymalizuje – wyścig o lepsze wyniki, (3) Google AI Overview preferuje szybkie strony (CWV jest sygnałem w algorytmie AI Overview), (4) HCU i user experience są coraz silniejszymi sygnałami, CWV korelują z UX.

Dodatkowa metryka TTFB (Time To First Byte) – nie jest oficjalnie Core Web Vital, ale wpływa na LCP i ogólną prędkość. Wszystkie 4 metryki omawiamy razem. Szczegóły problemów technicznych SEO znajdziesz w SEO technicznym 2026: najważniejszych błędach i priorytetach naprawy.

Metryka 1: Largest Contentful Paint (LCP)

LCP mierzy czas do załadowania największego widocznego elementu above-the-fold – zwykle hero image, nagłówek H1 lub główne zdjęcie produktu. Cel: ≤ 2,5 sekundy dla zielonej oceny, 2,5-4,0s – wymaga poprawy, > 4,0s – czerwona.

Najczęstsze przyczyny słabego LCP:

1. Brak preload dla hero image. Przeglądarka odkrywa obraz po parsowaniu HTML – dodanie preload w head przyspiesza o 200-800ms.
2. JPEG/PNG zamiast WebP/AVIF. WebP jest 25-35% mniejszy przy tej samej jakości, AVIF 50% mniejszy.
3. Brak responsive images. Desktop obraz na mobile – niepotrzebny overhead.
4. Slow TTFB. Serwer odpowiada po 1,5-3s – LCP nie może być szybszy niż TTFB + render.
5. Render-blocking JS w head. JS w head blokuje HTML parsing i CSS rendering.
6. Zewnętrzne fonty blokujące. Google Fonts loaded synchronicznie opóźnia render.

Optymalizacje LCP – co dokładnie zrobić

• Preload hero image: <link rel="preload" as="image" href="hero.webp"> w head
• Konwersja na WebP i AVIF: plugin Imagify, ShortPixel lub TinyPNG dla WordPress, build pipeline dla custom site
• Responsive images: <img srcset="small.webp 480w, medium.webp 768w, large.webp 1200w">
• Lazy loading below-the-fold: loading="lazy" dla obrazów poniżej hero
• CDN dla static assets: Cloudflare, BunnyCDN, AWS CloudFront
• TTFB: HTTP cache (Varnish, Nginx cache), Redis dla PHP cache, opcja plugin WP Rocket dla WordPress
• Font-display: swap z fallback font metrycznie zbliżonym
• Defer/async dla non-critical JS

Efekt typowy: LCP z 4,2s na 2,1s (czerwony → zielony) w 2-4 tygodnie pracy dewelopera + 8-15 tys. zł kosztu.

Metryka 2: Interaction to Next Paint (INP)

INP zastąpił FID w marcu 2024. FID mierzył tylko pierwszą interakcję na stronie – INP mierzy najgorszą spośród wszystkich interakcji (do 98 percentyla). Cel: ≤ 200ms zielona, 200-500ms wymaga poprawy, > 500ms czerwona.

INP ujawnił problemy, które FID pomijał – szczególnie dla stron SPA (single page application) i e-commerce z ciężkim JS. Przykład: e-commerce z filtrem produktów. FID pokazywał 50ms (pierwsza interakcja – hover menu). INP pokazuje 650ms (zmiana filtra cenowego, która re-renderuje 200 produktów).

Najczęstsze przyczyny słabego INP:

1. Synchroniczne trackery. GTM, Google Analytics, Hotjar, Facebook Pixel ładowane synchronicznie blokują główny wątek.
2. Heavy event handlers. onscroll z heavy computation, click handlers z 500+ linii kodu.
3. Brak debounce/throttle. Każde uderzenie klawisza triggeruje reflow.
4. Client-side rendering dużych list. 500+ produktów renderowanych przez JS zamiast SSR.
5. Dynamiczne filtry SPA bez wirtualizacji. Renderowanie wszystkich itemów naraz.
6. Over-engineered state management. Redux z 40 warstwami middleware blokuje.
7. Main thread bloat. 3-5 różnych bibliotek analytics działających równolegle.

Optymalizacje INP – co dokładnie zrobić

• Debounce na inputach: setTimeout 200-300ms przed triggerem search/filter
• Web Workers dla heavy computation (np. sorting 1000+ items)
• Wirtualizacja długich list: React Window, Vue Virtual Scroller
• Lazy load 3rd party scripts: defer, dynamic import, requestIdleCallback
• Code splitting bundle per route: Next.js domyślnie, Webpack dla custom
• SSR dla dynamicznych widoków: Next.js, Remix, Nuxt
• Refaktoring heavy event handlers: przeniesienie logiki do Web Worker lub deferred
• Usunięcie niepotrzebnych trackerów – audit, co realnie używasz

INP jest najtrudniejszą metryką CWV. Projekt INP z czerwonego na zielony to zwykle 6-12 tygodni pracy, 40-120 tys. zł dla e-commerce. Dla content-heavy blogów zwykle 2-4 tygodnie, 15-40 tys. zł.

Metryka 3: Cumulative Layout Shift (CLS)

CLS mierzy niespodziewane przesunięcia wizualne na stronie – użytkownik kliknie przycisk, ten się przesuwa, klika inny (np. reklamę). Cel: ≤ 0,1 zielona, 0,1-0,25 wymaga poprawy, > 0,25 czerwona.

Najczęstsze przyczyny słabego CLS:

1. Brak width/height na obrazach. Przeglądarka nie zna wymiarów przed załadowaniem, przesuwa content.
2. Dynamicznie wstawiany content. Banner reklamowy pojawia się po 500ms, przesuwa wszystko.
3. Web Fonts z FOUT (Flash of Unstyled Text). Fallback font ma inne wymiary niż final font.
4. Pop-upy i cookie banery. Dodają się do layout po wczytaniu.
5. Embeded video/iframe bez reserved space. YouTube iframe ładuje się, przesuwa content.
6. CSS transforms bez will-change. Animacje przesuwają content rzeczywiście, nie przez transform.

Optymalizacje CLS

• Width i height jako atrybuty HTML na każdym img i video
• Reserved space dla banerów reklamowych: min-height na container
• Font-display: optional (jeśli zgodny z branding) lub font matching (adjust fallback metrics)
• Lazy load 3rd party widgets z placeholderem o znanych wymiarach
• Animacje przez transform i opacity (nie width/height/top/left)
• Preload critical fonts
• Skeleton screens dla dynamicznego contentu

CLS typowo łatwy do naprawy – 1-2 tygodnie pracy, 5-15 tys. zł. Największy ROI per godzina pracy wśród wszystkich CWV.

Metryka 4: Time to First Byte (TTFB)

TTFB mierzy czas od żądania przeglądarki do pierwszego bajtu odpowiedzi serwera. Nie jest oficjalnie CWV, ale wpływa na LCP (LCP = TTFB + render time). Cel: ≤ 800ms dobrze, > 1800ms słabo.

Przyczyny słabego TTFB:

• Słaby hosting (shared hosting, tani VPS)
• Brak cache (każde żądanie = query do bazy + PHP render)
• Wolna baza danych (niezindeksowane kolumny, ciężkie query)
• 3rd party API w render path (każdy request waiting for external)
• Geografia – serwer w USA, użytkownicy w Polsce

Optymalizacje TTFB

• HTTP cache (Varnish, Nginx proxy_cache, CloudFlare Cache Rules)
• Object cache (Redis, Memcached) dla dynamicznych zapytań
• CDN z edge caching (CloudFlare, Fastly)
• Database optimization: EXPLAIN dla slow query, dodanie indexów
• Async 3rd party calls – nie w render path
• Geo-targeted hosting lub CDN z edge nodes blisko rynku

Narzędzia do pomiaru CWV

Narzędzie	Typ danych	Koszt	Zastosowanie
PageSpeed Insights	CrUX (real users) + Lighthouse (lab)	Darmowe	Pojedynczy URL
Search Console CWV	CrUX dla całej domeny	Darmowe	Overview + problemy
Chrome UX Report (CrUX API)	Real user metrics	Darmowe	Programatyczna analiza
Lighthouse CI	Lab data, zautomatyzowane	Darmowe	CI/CD integracja
WebPageTest	Lab data z różnych lokalizacji	Freemium (0-200 USD/mies)	Głęboka diagnostyka
Calibre	Monitoring real user + lab	75-300 USD/mies	Enterprise monitoring
SpeedCurve	Synthetic + RUM monitoring	114-400 USD/mies	Large-scale sites
Real User Monitoring (własne)	web-vitals.js biblioteka	Darmowe (custom)	Full control, data do własnego dashboardu

Minimum dla średniej firmy: PageSpeed Insights + Search Console CWV + własny RUM przez web-vitals.js do BigQuery. Koszt: 0-100 USD/mies, setup 10-20 godzin developera. Dla enterprise: Calibre lub SpeedCurve jako dedykowany monitoring.

Proces projektu CWV – 90-dniowy plan

1. Tydzień 1-2: Audyt i baseline. Sprawdzenie CWV per template (home, kategoria, produkt, artykuł) w PageSpeed Insights. Identyfikacja głównych problemów. Baseline: CrUX data last 28 days.
2. Tydzień 3-4: Quick wins. Optymalizacje z największym ROI – obrazy WebP, preload hero, width/height na obrazach, font-display. Efekt w 2-4 tygodnie od deploy.
3. Tydzień 5-8: LCP deep dive. Jeśli LCP nadal czerwony – refaktor hero section, optymalizacja TTFB, CDN, krytyczny CSS inline.
4. Tydzień 9-12: INP i CLS. Najtrudniejsze metryki. Refaktor JS, lazy load trackerów, debounce, usunięcie synchronicznych widgetów.
5. Tydzień 10-16: Monitoring i iteracja. CWV data z CrUX opóźnione o 28 dni – efekt widoczny po 4-6 tygodniach od deploy. Iteracja, dodatkowe fixy dla opornych metryk.

Budżet typowy: mały serwis 15-40 tys. zł, średni 40-100 tys. zł, duży e-commerce 100-300 tys. zł. Efekt: z czerwonego na zielony CWV w 6-12 tygodni pracy + 4-6 tygodni na propagation data.

CWV per template strony

Ważne – CWV różni się per template. Strona główna może być zielona, a strona produktu czerwona. Zamiast mierzyć „stronę jako całość”, mierz per template:

• Home: mało dynamiczny, zwykle najłatwiejszy do zielonej. Cel LCP < 2s.
• Artykuł blogowy: dużo obrazów inline, embeded social – LCP 2-2,5s typowo, INP 150-200ms.
• Kategoria e-commerce: grid produktów, filtry, sort – największy challenge INP. LCP 2-2,5s, INP 250-400ms bez optymalizacji.
• Strona produktu: hero image duży, recenzje 3rd party, remarketing piksele – LCP 2,2-3s, INP 200-300ms.
• Checkout: formularze dynamiczne, walidacja – INP jest kluczowe, cel < 200ms.

Monitoring per template: w Google Search Console CWV report pokazuje URLs grupowane – sprawdź każdą grupę. Dla custom: Google Tag Manager z fragmentem web-vitals.js wysyłającym data do GA4 z page template jako custom dimension. Szczegółowo o pełnym audycie technicznym piszemy w tekście o indeksacji i crawl budget: diagnostyce i optymalizacji.

Przykłady przed i po optymalizacji

Przypadek 1: B2B SaaS marketing blog

Stan: LCP 3,8s (czerwony), INP 310ms (wymagane poprawy), CLS 0,18 (wymagane poprawy). Plan 8-tygodniowy: obrazy WebP, preload hero, lazy load non-critical JS, width/height na obrazach, font-display swap, redukcja trackerów z 8 do 3. Budżet: 22 tys. zł. Efekt po 10 tygodniach: LCP 1,9s, INP 180ms, CLS 0,06 – wszystkie zielone. Ranking top 10 wzrósł z 18 do 34 fraz.

Przypadek 2: E-commerce B2C fashion

Stan: LCP 3,2s, INP 520ms (czerwony – e-commerce challenge), CLS 0,22. Plan 12-tygodniowy: CDN setup, obrazy AVIF, wirtualizacja filtrów (React Window), lazy load opinii Trustpilot, usunięcie exit-intent pop-up, reserved space dla wszystkich dynamicznych elementów. Budżet: 85 tys. zł. Efekt po 14 tygodniach: LCP 2,1s, INP 190ms, CLS 0,08 – wszystkie zielone. Mobile bounce -12 punktów, konwersja +9%.

Przypadek 3: Portal informacyjny

Stan: LCP 4,4s, INP 280ms, CLS 0,34. Plan 10-tygodniowy: CDN CloudFlare, WebP, preload hero, redukcja reklam above-the-fold (2 slots zamiast 4), refaktor sticky social share. Budżet: 45 tys. zł. Efekt: LCP 2,3s, INP 210ms, CLS 0,09. Ruch organiczny +22% w 3 miesiące post-deploy, AdSense RPM niezmieniony (fewer ads but better UX balanced).

Najczęstsze błędy w optymalizacji CWV

• Tylko Lighthouse, bez CrUX. Lighthouse syntetyczny w lab daje zielony – real users widzą czerwony. Fix: monitoruj CrUX.
• Optymalizacja homepage, ignorowanie templatów produktów. Home zielony, produkt czerwony – traci rankingu tam gdzie boli. Fix: per template.
• Stare FID zamiast INP. FID wycofany, INP nowy. Fix: aktualizuj monitoring.
• Quick fixes bez fundamentów. Plugin cache’ujący ale hosting wolny i baza nieoptymalna. Fix: hosting pierwszy.
• Ignorowanie TTFB. LCP nie może być szybszy niż TTFB. Fix: optymalizuj oba.
• Optymalizacja raz i zapomnienie. Nowe funkcjonalności, nowy tracker, CWV wraca czerwone. Fix: monitoring ciągły, CWV check w każdym deploy.
• Focus na desktop, ignorowanie mobile. Mobile ma słabsze CPU, wolniejszy network – gorsze CWV. Fix: mobile-first optimization.
• Brak budgetu per metric. „Jakiś zielony będzie”. Fix: cel konkretny (LCP ≤ 2s, INP ≤ 180ms, CLS ≤ 0,05) i monitorowanie.

FAQ — najczęstsze pytania

Czy Core Web Vitals to zawsze top priorytet SEO?

Nie. CWV to tiebreaker w konkurencyjnych niszach – różnicuje strony o podobnym contencie i autorytecie. Jeśli masz słaby content i słabe linki, zielone CWV nie uratuje rankingu. Priorytet: (1) content match z intentem, (2) autorytet domeny i linki, (3) CWV. Dla top 5% najbardziej konkurencyjnych nisz CWV jest obowiązkowe. Dla mniej konkurencyjnych CWV w wymaganej poprawy (żółte) może być akceptowalne.

Ile kosztuje projekt CWV?

Mały serwis (500-1000 URL-i, WordPress): 10-30 tys. zł, 2-6 tygodni. Średni (1000-10 tys. URL, custom CMS): 30-100 tys. zł, 6-12 tygodni. Duży e-commerce (10 tys.+ produktów): 100-300 tys. zł, 10-20 tygodni. Enterprise: 300-800 tys. zł z uwzględnieniem redesignu i CDN. Koszt zawiera: audit, optymalizacje obrazów, refaktor JS, CDN setup, monitoring. Nie zawiera: hosting upgrade, platform migration.

Czy WordPress może być szybki?

Tak, ale wymaga świadomej konfiguracji. Klasyczny WordPress z tematem „darmowym” i 20 wtyczkami jest wolny. WordPress z: solidnym hostem (Kinsta, WPX, SiteGround Cloud), premium themes (GeneratePress, Astra), essential plugin set (Rank Math, WP Rocket, ShortPixel), CDN (CloudFlare), regularnym audytem – osiąga zielone CWV regularnie. Setup kosztuje 5-15 tys. zł jednorazowo + 100-500 zł/mies utrzymania.

Czy CWV wpływa na mobile i desktop oddzielnie?

Tak. Google mierzy CWV oddzielnie dla mobile i desktop. Mobile jest zwykle trudniejszy (wolniejsze CPU, słabszy network, ekran mały). Google mobile-first indexing oznacza, że głównie mobile CWV wpływa na ranking. Desktop jest drugorzędny. Priorytet: mobile zielony, desktop zielony jako bonus. Jeśli musisz wybrać – optymalizuj mobile.

Czy 3rd party scripts (GTM, chat, analytics) niszczą CWV?

Potencjalnie tak, ale zarządzalne. 3rd party scripts są najczęstszą przyczyną słabego INP. Strategia: (1) audyt – co realnie używasz (często 3-5 skryptów z 10 zainstalowanych jest faktycznie potrzebne), (2) defer/async dla wszystkiego non-critical, (3) server-side GTM zamiast client-side (obejście ad-blockerów + redukcja main thread), (4) delayed loading po user interaction (chat widget load after 3s or scroll). Po optymalizacji 5-8 trackerów może współistnieć z zielonym CWV.

Ile trwa od deploy optymalizacji do zielonego CWV w Search Console?

CrUX data są z ostatnich 28 dni – optymalizacja widoczna jako zielona dopiero po 28 dniach od pełnego wdrożenia. W praktyce: deploy optymalizacji → tydzień 1-2 test syntetyczny (Lighthouse) zielony, tydzień 2-4 CrUX zaczyna pokazywać poprawę, tydzień 4-6 75% użytkowników w zielonym (official pass), tydzień 6-8 stabilny zielony w Search Console. Zmienia się powoli – nie oczekuj natychmiastowego rankingu.

Czy mogę użyć AMP dla szybkich CWV?

Technicznie tak, ale Google w 2021 wycofał preferencyjne traktowanie AMP. W 2026 AMP jest mniej popularny – wiele sajtów porzuciło go na rzecz szybkiej wersji mobile. Dla nowych projektów nie rekomendujemy AMP – zamiast tego szybkie mobile z CWV optymalizacją daje lepsze UX i flexibilność. Jeśli już masz AMP, utrzymuj do czasu end-of-life (planowane przez niektórych CMS 2026-2027), potem migracja na responsive mobile.

Czy redesign zabija CWV?

Często tak, krótkoterminowo. Nowy design z nowymi elementami, nowym JS, nowymi fontami zwykle obniża CWV w pierwszych 2-4 tygodniach. Plan zapobiegawczy: (1) CWV budgets w designie (max LCP 2s, INP 200ms) – design respektuje te limity, (2) performance testing przed launch (Lighthouse CI w każdym PR), (3) CWV monitoring w pierwszych 8 tygodniach post-launch z szybkimi fixami, (4) nie redesign bez SEO/performance team. Redesign bez tego może stracić 20-40% rankingu na 3-6 miesięcy.

Co dalej

Gdy CWV są zielone, kolejny krok to pełen audit SEO techniczny – sprawdź SEO techniczne 2026 i najważniejsze błędy i priorytety naprawy. Dla problemów z indeksacją i crawl budget w e-commerce zobacz indeksację i crawl budget: diagnostykę i optymalizację.