Core Web Vitals 2026 – jak poprawić LCP, INP, CLS

Od marca 2024 zestaw Core Web Vitals oficjalnie opiera się o trzy metryki: LCP, INP i CLS. INP zastąpił FID i jest znacznie trudniejszy do pasażu – mierzy responsywność przez całą sesję, a nie tylko pierwszą interakcję. Według Web Almanac 2025 około 41% mobilnych stron przechodzi wszystkie trzy progi CWV, na desktopie – 52%. Oznacza to, że blisko połowa Internetu nadal ma problem z podstawami wydajności.

Core Web Vitals to nie tylko SEO. Są to metryki, które mocno korelują z konwersją – według danych Google z web.dev case studies poprawa LCP o 1 sekundę potrafi dać 8-12% więcej dokończonych transakcji. W tym przewodniku rozkładamy każdą z trzech metryk na czynniki, pokazujemy, jak je zmierzyć, i dajemy konkretne techniki, które w 2026 działają.

Co się dowiesz:

• Aktualne progi Core Web Vitals 2026 (LCP 2.5s, INP 200ms, CLS 0.1)
• Jak poprawić LCP – preload, fonty, obrazy, TTFB
• Jak poprawić INP – JS bundle, third party, long tasks
• Jak poprawić CLS – wymiary elementów, fonty, reklamy
• Porównanie narzędzi: PageSpeed Insights, GSC, Lighthouse
• FAQ i typowe błędy

Spis treści

• Czym są Core Web Vitals w 2026
• LCP – Largest Contentful Paint
• INP – Interaction to Next Paint
• CLS – Cumulative Layout Shift
• Narzędzia do pomiaru – porównanie
• Lab vs field data – różnice
• Case study – optymalizacja strony
• FAQ

Czym są Core Web Vitals w 2026

Core Web Vitals to zestaw trzech metryk opisujących doświadczenie użytkownika na stronie: szybkość załadowania głównej treści, responsywność na interakcje i stabilność wizualną podczas ładowania. Google używa tych metryk jako sygnału rankingowego od 2021 roku (Page Experience Update), a od 2024 w nowej konfiguracji z INP.

Oficjalna dokumentacja: web.dev/vitals. Każda metryka ma trzy progi – dobra, wymaga poprawy, słaba. Żeby strona „przeszła” CWV, 75. percentyl wszystkich sesji musi mieścić się w progu „dobra”.

Progi Core Web Vitals 2026

Metryka	Co mierzy	Dobra	Wymaga poprawy	Słaba
LCP	Czas renderowania głównego elementu	≤ 2.5 s	2.5 – 4.0 s	> 4.0 s
INP	Opóźnienie odpowiedzi na interakcję	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	Suma nieoczekiwanych przesunięć layoutu	≤ 0.1	0.1 – 0.25	> 0.25

Dodatkowe metryki pomocnicze (nie CWV, ale powiązane): FCP (First Contentful Paint), TTFB (Time to First Byte), TTI (Time to Interactive), Total Blocking Time. Wszystkie pokazuje PageSpeed Insights.

Dlaczego CWV mają znaczenie

• SEO: sygnał rankingowy, szczególnie dla mobile
• Konwersja: szybsza strona = więcej transakcji, niższy bounce
• Koszt akwizycji: wolniejsze strony mają wyższy CPL w kampaniach
• Brand: laggujące strony są kojarzone z nieprofesjonalną firmą

LCP – Largest Contentful Paint

LCP mierzy czas od rozpoczęcia ładowania do momentu, w którym największy element widocznego obszaru (viewport) został wyrenderowany. Najczęściej jest to obrazek hero, wideo plakatowe lub duży nagłówek tekstowy. Cel: ≤ 2.5 s przy połączeniu 4G.

Co psuje LCP

1. Wolny TTFB (> 600 ms) – problem serwera, braku cache, ciężkiego backendu
2. Render-blocking CSS/JS – przeglądarka musi je pobrać i sparsować przed rysowaniem
3. Obrazek hero ładowany leniwie – paradoks: lazy loading powinien pominąć elementy above-the-fold
4. Brak preload dla krytycznych zasobów – obrazek LCP, fonty web
5. Brak CDN – dla użytkowników odległych od serwera latencja zabija LCP
6. Ciężkie fonty web bez font-display: swap
7. Niewyoptymalizowane obrazki – JPEG 2MB zamiast WebP 300KB

Techniki poprawy LCP

1. Preload dla obrazka hero

Umieść w sekcji head:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

W Next.js 15+ używaj next/image z atrybutem priority – biblioteka automatycznie dodaje preload.

2. Format WebP / AVIF

Konwersja z JPG na WebP daje średnio 25-35% mniej wagi przy tej samej jakości. AVIF jeszcze lepszy (50%), ale gorsze wsparcie w starszych przeglądarkach. Serwuj oba z fallbackiem przez <picture>.

3. Font-display: swap + preload fontów

<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-var.woff2" crossorigin>

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-display: swap;
}

4. Krytyczny CSS inline

Dla strony powyżej fold wyodrębnij critical CSS i umieść w <style> w head. Reszta ładuje się asynchronicznie przez MDN link rel=”preload”. Narzędzia: Critical, CriticalCSS, PurgeCSS dla usuwania nieużywanych reguł.

5. Hosting i TTFB

TTFB powyżej 600 ms to sygnał, że backend lub hosting są wąskim gardłem. Rozwiązania: cache aplikacyjny (Redis), cache stron (Varnish, Nginx), statyczne generowanie (SSG), przejście na hosting managed z SSD. Dla WordPressa wtyczki: WP Rocket, W3 Total Cache. Dla Next.js – deploy na Vercel, VPS z PM2 i Nginx, lub edge na Cloudflare.

6. CDN dla zasobów statycznych

Cloudflare (free plan wystarcza), Bunny CDN, Amazon CloudFront. Obrazki, CSS, JS, fonty blisko użytkownika = niższa latencja.

W Studio Kalmus po migracji klienta z WooCommerce (1.2 TTFB) na Next.js 16 ISR z Vercel (180 ms TTFB) LCP spadł z 4.8s do 1.6s, a konwersja wzrosła o 14% w 6 tygodni.

INP – Interaction to Next Paint

INP zastąpił FID (First Input Delay) w marcu 2024. Różnica: FID mierzył tylko pierwszą interakcję, INP bierze pod uwagę wszystkie interakcje w sesji i raportuje 75. percentyl. Jest wymagający – progi są ostrzejsze niż to, do czego przywykły agencje pracujące z FID.

INP mierzy czas od kliknięcia / tap / naciśnięcia klawisza do wyrenderowania następnej klatki, która zawiera wizualną odpowiedź na tę akcję. Cel: ≤ 200 ms.

Co psuje INP

1. Long tasks JS (> 50 ms) – blokują główny wątek
2. Third party scripts – Facebook Pixel, chatboty, heatmap, GTM z ciężkimi tagami
3. Ciężka hydracja React / Next.js – duży bundle JS do wykonania
4. Synchroniczne operacje przy evencie – np. formatowanie tabeli w onClick
5. Reklamy i widgety uruchamiane na starcie zamiast on demand
6. Nieefektywne animacje na właściwościach layoutowych

Techniki poprawy INP

1. Code splitting i lazy loading JS

Dla Next.js: dynamic import dla komponentów nie-krytycznych. Dla vanilla React: React.lazy + Suspense. Cel: initial bundle < 170 KB gzip.

const HeavyChart = dynamic(() => import('./HeavyChart'), { ssr: false });

2. Odsuwaj third party scripts

Używaj defer, async lub next/script strategy="lazyOnload". Najlepsze narzędzia: Google Tag Manager z lazy firing, Partytown (przenosi scripts na web worker).

3. Dziel długie zadania

Używaj scheduler.yield() lub setTimeout(fn, 0) do przerywania długich operacji. Web.dev: optimize long tasks.

async function processItems(items) {
  for (const item of items) {
    processItem(item);
    if (shouldYield()) {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

4. Web Workers dla ciężkich obliczeń

Przeniesienie parsowania, szyfrowania, transformacji danych na web worker zdejmuje obciążenie z głównego wątku. Dla React: use-workerized-reducer. MDN: Web Workers API.

5. Animacje na GPU

Używaj transform i opacity, nie top/left/width/height. Pierwsze działają na kompozytorze GPU, drugie wymuszają relayout CPU.

6. Debounce i throttle w inputach

Dla wyszukiwarek z autocomplete użyj debounce 150-250 ms. Bez tego każde stuknięcie klawisza triggeruje full re-render.

7. Virtualizacja list

Dla list powyżej 100 elementów użyj react-window lub react-virtual. Renderowanie tylko widocznych itemów drastycznie poprawia INP.

CLS – Cumulative Layout Shift

CLS mierzy sumę nieoczekiwanych przesunięć layoutu podczas sesji. Wartość bezwymiarowa: 0 = brak przesunięć, 0.1 = dobry wynik, 0.25+ = słaby. Przesunięcie powodowane przez interakcję użytkownika (np. rozwinięcie menu) nie liczy się.

Co psuje CLS

1. Obrazki bez atrybutów width i height – przeglądarka nie wie, ile miejsca zarezerwować
2. Reklamy i iframe bez wymiarów – wskakują po załadowaniu
3. Fonty web z FOUT – zmiana fontu zmienia wymiary tekstu
4. Banery cookie wypychane z opóźnieniem
5. Dynamicznie wstrzykiwany content powyżej istniejącej treści
6. Animacje na właściwościach layoutowych (nie transform)

Techniki poprawy CLS

1. Zawsze width i height na obrazkach

Przeglądarki obliczą aspect ratio automatycznie z atrybutów, jeszcze zanim obrazek się załaduje.

<img src="/hero.webp" width="1200" height="630" alt="...">

2. Rezerwuj miejsce na reklamy i iframe

Jeśli wiesz, że wskoczy slot 300×250, daj kontenerowi:

.ad-slot { min-height: 250px; width: 300px; }

3. Font-display i font-optical-sizing

Używaj font-display: swap + dobierz font systemowy o podobnych metrykach jako fallback. Narzędzie: web.dev font fallbacks.

4. Fixed positioning dla banerów cookie

Baner cookie powinien być position: fixed na bottom, nie wypychać treści od góry.

5. Skeleton screens dla dynamicznego contentu

Zamiast pustego miejsca, które się wypełni – pokaż kontener z szarym tłem o finalnych wymiarach.

6. CSS containment

Użyj contain: layout dla kontenerów, żeby izolować ich layout od reszty strony.

Narzędzia do pomiaru Core Web Vitals

Narzędzie	Cena	Typ danych	CrUX	Recommendations	Zastosowanie
Google PageSpeed Insights	Free	Lab + Field	Tak	Tak	Podstawowa diagnostyka
Google Search Console (raport CWV)	Free	Field (28 dni)	Tak	Nie	Monitoring historyczny
Lighthouse (Chrome DevTools)	Free	Lab	Nie	Tak	Lokalny debug
web.dev measure	Free	Lab	Nie	Tak	Single-shot audit
WebPageTest	Free / Pro od 20 USD/mc	Lab (advanced)	Opcjonalnie	Tak	Waterfall, filmstrip, multi-location
Chrome UX Report (CrUX)	Free (BigQuery)	Field (25. mln stron)	Tak	Nie	Analiza konkurencji
RUM custom (np. Sentry, Datadog)	Od 30 USD/mc	Field (własny)	Nie	Nie	Enterprise real user monitoring

W Studio Kalmus standardowo pracujemy z PageSpeed Insights + GSC (raport Core Web Vitals) + Lighthouse do lokalnego debugu. Dla e-commerce dochodzi WebPageTest z filmstrip do wizualnej analizy ładowania.

Lab vs field data – dlaczego to jest mylące

Lab data (PageSpeed Insights: „Analizowano stronę…”) to wynik pojedynczego testu w standardowych warunkach (środowisko laboratoryjne, Chrome, MotoG4, Slow 4G). Kontrolowalne, powtarzalne, ale nierealne.

Field data (CrUX – Chrome User Experience Report) to agregacja anonimowych pomiarów od realnych użytkowników Chrome, którzy odwiedzili stronę w ostatnich 28 dniach. Wymaga próbki minimum – małe strony mogą nie mieć danych CrUX.

Google rankinguje na field data

Co oznacza, że wynik z PageSpeed „Dobry – 95/100” może współistnieć z ostrzeżeniem „Nie przechodzi CWV” w sekcji Field. Przyczyna: Twój lokalny lab ma gigabit, realni użytkownicy mają LTE w terenie. Zawsze patrz na field.

Dlaczego wyniki się rozjeżdżają

• Lab testuje jedno urządzenie – użytkownicy mają setki konfiguracji
• Lab używa zimnego cache – użytkownicy wracający mają ciepły
• Third party scripts (np. chatbot) pokazują się dla zalogowanych użytkowników, a lab ich nie widzi
• CDN cache na poziomie regionu – lab z jednej lokalizacji nie pokaże realnej latencji globalnej

Case study – optymalizacja strony firmowej

Krótki zapis realizacji z 2025 dla klienta z branży usług lokalnych z woj. mazowieckiego. Strona na WordPress + Elementor, ~80 podstron.

Stan wyjściowy

• LCP mobile: 4.8 s (słaby)
• INP mobile: 420 ms (słaby)
• CLS mobile: 0.28 (słaby)
• PageSpeed Mobile: 34/100

Interwencja (3 tygodnie)

1. Migracja hostingu na managed SSD + wdrożenie WP Rocket (cache + critical CSS)
2. Konwersja wszystkich obrazków na WebP, dodanie width/height
3. Preload obrazka hero + fontów web
4. Usunięcie nieużywanych wtyczek Elementor (10 z 32)
5. Przeniesienie chatbota Tawk.to na lazy load (po scroll)
6. CDN Cloudflare na zasoby statyczne
7. Poprawa bannera cookie – zmiana pozycji na fixed bottom

Stan po optymalizacji

• LCP mobile: 1.9 s (dobra)
• INP mobile: 180 ms (dobra)
• CLS mobile: 0.05 (dobra)
• PageSpeed Mobile: 89/100

Efekty biznesowe w 60 dniach: ruch organiczny +22%, średni czas sesji +17%, współczynnik odrzuceń -11%, konwersja formularza kontaktowego +9%. Całkowity koszt interwencji: jeden sprint techniczny. Jeśli rozważasz podobny projekt, zobacz nasze realizacje stron internetowych i projekty UX/UI.

Najczęstsze błędy przy optymalizacji CWV

• Optymalizacja tylko lab data – 95/100 w PageSpeed, a field czerwony
• Ignorowanie mobile – desktop jest łatwiejszy, ale Google indeksuje mobile first
• Przesadne lazy loading – obrazek LCP leniwie = katastrofa
• Blokowanie render bez potrzeby – inline CSS powyżej 14 KB spowalnia rendering
• Brak monitoringu po zmianach – regression nie jest widoczna od razu
• Ufanie plugin-om bez weryfikacji – „cache plugin” bez testu A/B może pogorszyć CLS
• Pomijanie third party – GTM, Facebook Pixel, chatbot – wszystkie do audytu

FAQ – najczęstsze pytania o Core Web Vitals

Czy Core Web Vitals są sygnałem rankingowym?

Tak, od czerwca 2021 (Page Experience Update). Są sygnałem pomocniczym – nie zastąpią jakości treści, ale między dwoma podobnymi stronami Google wybierze szybszą. Wpływ jest silniejszy na mobile niż desktop.

Co to jest INP i czym różni się od FID?

INP (Interaction to Next Paint) zastąpił FID (First Input Delay) w marcu 2024. FID mierzył tylko pierwszą interakcję, INP raportuje 75. percentyl wszystkich interakcji w sesji. Jest bardziej wymagający i lepiej odzwierciedla doświadczenie użytkownika.

Jak szybko widać efekty poprawy CWV w GSC?

Raport w Google Search Console aktualizuje się co 28 dni (okno CrUX). Realnie pierwsze zmiany widać po 7-14 dniach od wdrożenia, pełny obraz – po 28 dniach. Wpływ na ranking – od kilku tygodni do kilku miesięcy.

Czy WordPress z Elementorem może osiągnąć dobre CWV?

Tak, ale wymaga pracy: wyłączenie nieużywanych widgetów, WP Rocket lub W3 Total Cache, konwersja obrazków na WebP, dobry hosting (nie shared za 10 zł/mc). W praktyce strony na Elementorze rzadziej osiągają zielone CWV niż te w Next.js / Astro – natura stack-a.

Czy CWV dotyczą Single Page Application?

Tak, ale są mierzone inaczej – każda nawigacja wewnątrz SPA jest traktowana jak soft navigation. Google pracuje nad dedykowanym modelem CWV dla SPA – na razie pomiar zwraca LCP i INP z pierwszego view.

Czy lazy loading obrazków szkodzi CWV?

Może szkodzić, jeśli leniwie ładujesz obrazek hero / LCP. Dla elementów above-the-fold używaj eager loading + fetchpriority=”high”. Dla reszty – lazy.

Jaki jest realny wpływ CWV na konwersję?

Według case studies Google: poprawa LCP o 1 s zwiększa konwersję 8-12%. INP poniżej 200 ms zmniejsza porzucenia formularzy. CLS poniżej 0.1 poprawia doświadczenie – mniej „przypadkowych kliknięć” przez skakanie layoutu.

Podsumowanie

Core Web Vitals w 2026 to zestaw trzech metryk: LCP (2.5 s), INP (200 ms) i CLS (0.1). Nie są srebrną kulą SEO, ale są fundamentem doświadczenia na stronie i sygnałem rankingowym dla Google. Zaczynaj od LCP – to najczęstszy problem: wolny hosting, ciężkie obrazki, brak preload. Potem INP: tnij JavaScript, odsuwaj third party, dziel długie zadania. Na końcu CLS: wymiary na obrazkach, rezerwacja miejsca na dynamiczny content.

Mierz zarówno lab (PageSpeed, Lighthouse), jak i field (GSC, CrUX). Google patrzy na field. Po każdej istotnej zmianie w kodzie lub treści sprawdzaj regression – uniknięcie jednej linijki CSS może zepsuć CLS, dodanie jednego skryptu trackingu – INP.