SEO 2026-04-22 12 min czytania

Core Web Vitals 2026 — praktyczny przewodnik (LCP, CLS, INP)

Core Web Vitals to trzy metryki jakości strony, które Google używa jako czynnik rankingowy od 2021. W 2026 INP zastąpił FID, a benchmarki się zaostrzyły. Strona z dobrymi CWV ma +20-40% konwersji i średnio 1-2 pozycje wyżej w rankingu dla konkurencyjnych zapytań. Poniżej pełen przewodnik: co to jest, jak mierzyć, jak optymalizować dla WordPress i Next.js.

TL;DR — benchmarki 2026

LCP (ładowanie)
≤ 2.5s
≥ 4.0s = POOR
CLS (stabilność)
≤ 0.1
≥ 0.25 = POOR
INP (interakcje)
≤ 200ms
≥ 500ms = POOR

Wartości liczone jako 75 percentyl wizyt z CrUX (Chrome User Experience Report).

3 metryki — szczegółowo

LCP

Largest Contentful Paint

Mierzy
Percepcja szybkości ładowania

Czas do wyrenderowania największego widocznego elementu (hero image, heading).

GOOD
≤ 2.5s
POOR
≥ 4.0s

CLS

Cumulative Layout Shift

Mierzy
Wizualna stabilność

Suma wszystkich niechcianych przesunięć layoutu podczas ładowania.

GOOD
≤ 0.1
POOR
≥ 0.25

INP

Interaction to Next Paint

Mierzy
Responsywność interakcji

Najdłuższy czas reakcji na interakcję (click, tap, keypress) podczas wizyty.

GOOD
≤ 200ms
POOR
≥ 500ms

Dlaczego Core Web Vitals mają znaczenie?

1. Ranking Google

Od 2021 CWV są oficjalnym czynnikiem rankingowym. Realnie: dla zapytań konkurencyjnych gdzie wszyscy mają dobre SEO, CWV rozstrzygają top 3. Różnica między „good" a „poor" CWV = średnio 2-5 pozycji w rankingu.

2. Konwersja

Amazon: 100ms dodatkowego opóźnienia = -1% sprzedaży. Walmart: 1s poprawy LCP = +2% konwersji. Dla polskiego SMB realistycznie: strona z LCP 1.5s vs 4.0s = różnica 20-40% konwersji (user zrezygnuje jeśli czeka za długo).

3. AI Overviews i Google AI

Google AI Overviews preferują szybkie źródła (LCP ≤ 2.0s w testach). Dla AI search (ChatGPT web, Perplexity, Claude) strona musi być szybko fetchowana. Strona z 4s+ LCP jest „pominięta" przez AI crawlers na rzecz szybszych konkurentów.

Narzędzia do mierzenia CWV

Google Search Console

Best for daily monitoring — real field data z Twojej domeny, podzielone na good/needs-improvement/poor URL.

  • Bezpłatne
  • Real user data
  • Email alerty gdy pogorszenie
  • Per-URL breakdown
🔗 search.google.com/search-console

PageSpeed Insights

Best for debugowania pojedynczego URL — Lighthouse + CrUX field data + konkretne suggestions.

  • Szczegółowe sugestie
  • Lab + field data
  • Breakdown mobile vs desktop
  • Free
🔗 pagespeed.web.dev

Chrome DevTools Performance

Best dla developerów — szczegółowa analiza timeline, long tasks, render blocking.

  • Pełna kontrola
  • Real-time profiling
  • Network throttling
  • Free w Chrome
🔗 chrome://inspect

Cloudflare Web Analytics

Real User Monitoring (RUM) + Core Web Vitals z real wizyt — bez cookies.

  • Privacy-friendly
  • Bez cookies
  • Integracja z CDN
  • Free do 10M wizyt/mies
🔗 cloudflare.com

Vercel Analytics

Dla projektów na Next.js — CWV per route z alertami.

  • Najlepszy dla Next.js
  • Per-route breakdown
  • Real user data
  • $10-50/mies
🔗 vercel.com/analytics

Web-Vitals JS library

Custom tracking — wysyłaj CWV do dowolnego analytics (GA4, PostHog, Mixpanel).

  • Full customization
  • Działa wszędzie
  • Bezpłatna biblioteka
  • Recommendowana przez Google
🔗 github.com/GoogleChrome/web-vitals

Jak optymalizować — checklist per metryka

Optymalizacja LCP

  • Preload hero image (link rel="preload")
  • WebP/AVIF zamiast JPG/PNG (-30-50% rozmiar)
  • Critical CSS inline (pierwsza partia)
  • CDN (Cloudflare, Bunny CDN)
  • Szybki hosting (TTFB ≤ 500ms)
  • Async/defer dla JS niekrytycznego
  • Usuń render-blocking resources

Optymalizacja CLS

  • width/height dla KAŻDEGO obrazu
  • Reserved space dla reklam / embed
  • font-display: optional (nie swap)
  • Banery cookie jako fixed (nie insert)
  • Unikaj dynamicznych insertów „nad" contentem
  • Preload fontów + weight odpowiedni
  • Skeleton screens dla dynamicznego contentu

Optymalizacja INP

  • Podziel długie JS tasks (<50ms)
  • Web workers dla ciężkich obliczeń
  • Code splitting (lazy loading)
  • Defer niekrytyczny JS
  • useDeferredValue, useTransition (React)
  • Usuń niepotrzebne 3rd party scripts
  • Ogranicz Google Tag Manager

WordPress vs Next.js — realne wyniki CWV

StackLCP (typowe)CLSINP
WordPress bare (shared hosting, bez cache)4.0-6.5s 🔴0.1-0.3 🟡400-800ms 🔴
WordPress + WP Rocket + Cloudflare1.8-2.5s 🟢0.05-0.12 🟢200-350ms 🟡
WordPress Elementor (ciężki design)2.5-4.0s 🟡0.15-0.25 🟡400-600ms 🔴
Shopify (standard theme)2.0-3.5s 🟡0.05-0.1 🟢180-350ms 🟡
Webflow1.5-2.2s 🟢0.03-0.08 🟢150-250ms 🟢
Next.js (SSG + Vercel/Cloudflare)0.8-1.5s 🟢0.02-0.05 🟢80-180ms 🟢

Źródło: uśrednione dane z ~200 stron zaudytowanych przez GMWEB 2024-2026. Realne wyniki zależą od contentu, implementacji, hostingu. Przedziały pokazują typowe „best case" do „worst case" dla każdego stacka.

Wniosek:

Next.js wygrywa out-of-the-box, ale WordPress z WP Rocket + Cloudflare dogania go w 85% przypadków. Różnica staje się widoczna dopiero przy dużym ruchu (100k+ wizyt/mies) lub przy wymaganiach premium (real-time, heavy JS). Dla typowego SMB WP z dobrym setupem = wystarczająco dobre CWV.

Case study: polska strona firmowa z CWV POOR → GOOD

Przed audytem (WordPress + Elementor + shared hosting):

LCP
4.8s 🔴
CLS
0.32 🔴
INP
680ms 🔴

Wykonane optymalizacje (12h pracy, 3500 zł):

  • 1. Migracja z shared na VPS z Nginx + PHP 8.2 (LCP -1.5s)
  • 2. Cloudflare CDN + caching rules (LCP -0.6s, INP -150ms)
  • 3. WP Rocket + Cloudflare APO (LCP -0.3s)
  • 4. Konwersja 47 JPG/PNG na WebP (LCP -0.4s)
  • 5. Preload hero image + logo fonts (LCP -0.3s)
  • 6. Width/height na wszystkich 120 obrazach (CLS -0.18)
  • 7. Cookie banner reimplementacja fixed-bottom (CLS -0.09)
  • 8. Usunięcie 8 niepotrzebnych wtyczek (INP -180ms)
  • 9. GTM ograniczony do 3 tagów (INP -90ms)
  • 10. Podział długich JS tasks + defer dla 4 skryptów (INP -80ms)

Po audycie:

LCP
1.7s 🟢
CLS
0.05 🟢
INP
180ms 🟢

Rezultat biznesowy: W ciągu 90 dni po wdrożeniu — wzrost ruchu organicznego +42%, wzrost konwersji (formularze kontaktowe) +28%, spadek bounce rate -15%. ROI: zwrot inwestycji 3 500 zł w ok. 6-8 tygodni.

Najczęstsze pytania

Czym są Core Web Vitals?

Core Web Vitals (CWV) to zestaw trzech metryk jakości user experience strony wprowadzonych przez Google: LCP (Largest Contentful Paint — jak szybko ładuje się największy element), CLS (Cumulative Layout Shift — ile elementy skaczą podczas ładowania), INP (Interaction to Next Paint — responsywność na interakcje). Od 2021 są czynnikiem rankingowym Google. W 2024 INP zastąpił FID jako trzecia metryka. W 2026 dobre CWV to must — słabe = utrata pozycji + konwersji.

Jakie są benchmarki Core Web Vitals 2026?

LCP: GOOD ≤ 2.5s, NEEDS IMPROVEMENT 2.5-4.0s, POOR ≥ 4.0s. CLS: GOOD ≤ 0.1, NEEDS IMPROVEMENT 0.1-0.25, POOR ≥ 0.25. INP: GOOD ≤ 200ms, NEEDS IMPROVEMENT 200-500ms, POOR ≥ 500ms. Google uwzględnia 75 percentyl — aby strona była „good", 75% wizyt musi mieć dobry wynik. Dane: CrUX (Chrome User Experience Report) — real field data, nie lab. Sprawdź: pagespeed.web.dev lub Search Console > Core Web Vitals.

Czy Core Web Vitals wpływają na ranking w Google?

Tak, od 2021 CWV są oficjalnym czynnikiem rankingowym. Ale Google podkreśla że to tylko JEDEN z 200+ czynników — nie oczekuj, że perfect CWV da Ci top 1. Realny wpływ: jeśli Ty i konkurent jesteście podobni w SEO, CWV decydują. Dla zapytań konkurencyjnych różnica 1 pozycji = często różnica CWV. Dodatkowo CWV wpływają BEZPOŚREDNIO na konwersję — strona z LCP 1.5s ma 20-40% wyższą konwersję niż z 4.0s. Amazon: 100 ms opóźnienia = -1% sprzedaży.

Jak zmierzyć Core Web Vitals?

Trzy główne źródła: (1) Google Search Console > Core Web Vitals — real field data dla Twojej domeny, podzielone na dobre/średnie/słabe URL. (2) PageSpeed Insights (pagespeed.web.dev) — analiza pojedynczego URL z lab data (Lighthouse) + field data (CrUX). (3) Chrome DevTools > Performance — szczegółowy debug dla developera. Dodatkowe: web-vitals JS library (monitoring real user), Cloudflare Web Analytics, Vercel Analytics. Do codziennego monitoringu używaj Search Console, do debugowania PageSpeed Insights.

Dlaczego moja strona WordPress ma złe Core Web Vitals?

Typowe przyczyny dla WordPress: (1) zbyt wiele wtyczek (każda dodaje JS/CSS), (2) brak cache (musisz mieć WP Rocket lub W3 Total Cache + Cloudflare), (3) zdjęcia nieoptymalizowane (brak WebP/AVIF, nie-lazy), (4) wolny hosting (shared hosting vs dedicated), (5) Elementor/WPBakery generujące ciężki kod (każda sekcja = osobny wrapper DIV), (6) fonty z Google Fonts ładowane synchronicznie. Rozwiązanie: WP Rocket + Cloudflare + optymalizacja obrazów (WebP) + usunięcie niepotrzebnych wtyczek + swap z Elementora na bloki Gutenberga.

Jak zoptymalizować LCP?

LCP = czas do wyrenderowania największego elementu (zwykle hero image lub main heading). Optymalizacja: (1) preload hero image: <link rel="preload" as="image" href="hero.webp">, (2) optymalizacja obrazów: WebP zamiast JPG (-30% rozmiar), AVIF dla Chrome (-50%), srcset dla responsive, (3) critical CSS inline, (4) eliminacja render-blocking resources (async/defer dla JS niezbędnego), (5) szybki serwer (TTFB ≤ 500ms), (6) CDN (Cloudflare), (7) dla hero text: font-display: optional lub swap + preload fontu, (8) cache strategii (service worker dla repeat visits).

Jak zoptymalizować CLS?

CLS = niechciane przesunięcia layoutu. Top przyczyny: (1) obrazy bez width/height attributes (zawsze dodawaj!), (2) reklamy / embed-y wstawiane dynamicznie (rezerwuj miejsce CSS-em), (3) fonty powodujące FOIT/FOUT (używaj font-display: optional), (4) banery cookie wstawiane na górze (używaj fixed position nie insert), (5) dynamicznie pojawiające się CTA / promocje. Golden rule: każdy element musi mieć REZERWOWANE miejsce od początku ładowania. Nigdy nie insertuj contentu „nad" istniejący content (push down).

Jak zoptymalizować INP (nowa metryka 2024)?

INP = responsywność na interakcje (click, tap, keypress). Od marca 2024 zastąpił FID. Optymalizacja: (1) redukuj długie zadania JS (>50ms) — dziel na mniejsze, (2) defer/async nie-krytyczny JS, (3) użyj web workers dla ciężkich obliczeń, (4) unikaj synchronicznego setTimeout/setInterval w handlers, (5) dla React: użyj useDeferredValue, useTransition, (6) code splitting (lazy loading komponentów), (7) remove niepotrzebne third-party scripts (Google Tag Manager, ads). Dla WordPress: usuń wolne wtyczki (check wt. Pingdom), ogranicz GTM do minimum.

Twoje Core Web Vitals są na czerwono?

Umów bezpłatny audyt CWV. Przeanalizujemy Twoją stronę w PageSpeed Insights + Search Console, wskażemy konkretne przyczyny i oszacujemy koszt optymalizacji (2 500-8 000 zł dla większości projektów). ROI zwykle 2-3 miesiące przez poprawę konwersji.

Umów bezpłatny audyt CWV