Core Web Vitals 2026 — pomiar i naprawa LCP INP CLS

Core Web Vitals 2026 to trzy metryki użytkownika: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) oraz CLS (Cumulative Layout Shift). Kwalifikują się jako „dobre”, gdy 75 percentyl ruchu mobilnego i desktopowego mieści się poniżej progów 2,5 s, 200 ms i 0,1. Ten przewodnik pokazuje, jak je mierzyć w CrUX, PageSpeed Insights i RUM oraz jak naprawiać regresje krok po kroku.

W skrócie

LCP < 2,5 s na p75 — największy element widoczny w viewporcie musi wyrenderować się w tym czasie; najczęstsze przyczyny to powolny TTFB, brak fetchpriority="high" i obrazy bez preload.
INP < 200 ms na p75 — obejmuje wszystkie interakcje w sesji, nie tylko pierwszą; długie zadania JavaScript powyżej 50 ms są głównym problemem.
CLS < 0,1 — stabilność layoutu w całym czasie życia strony; reklamy, fonty bez size-adjust i obrazy bez atrybutów width/height to trzy najczęstsze źródła przesunięć.
Źródło prawdy dla Google: CrUX (Chrome UX Report) — dane terenowe z 28 dni; lab testy z Lighthouse są tylko wskazówką, nie podstawą oceny.
Kolejność naprawy: najpierw RUM i CrUX, potem hipoteza, potem lab test, potem fix, potem weryfikacja w CrUX po 28 dniach.

Dlaczego Core Web Vitals w 2026 decydują o widoczności

Core Web Vitals pozostają częścią sygnału page experience w algorytmie Google od czerwca 2021, a od marca 2024 INP zastąpił FID jako metryka responsywności. W 2026 próg kwalifikacji „dobre” obowiązuje dla 75 percentyla ruchu mobilnego i desktopowego osobno — jedna słaba metryka degraduje cały URL do kategorii „wymaga poprawy” lub „słabe”.

Wpływ CWV na rankingi nie jest tie-breakerem — według oficjalnej dokumentacji Google jest to jeden z wielu sygnałów, który przy równej jakości treści może rozstrzygnąć, który wynik wygra pozycję. W praktyce największą wartość CWV ma tam, gdzie konkurencja zaniedbała wydajność: w e-commerce, wydawnictwach i serwisach z intensywną reklamą.

Drugi wymiar to konwersje i zaangażowanie — Deloitte w 2020 pokazał, że 0,1 s skrócenia ładowania na urządzeniu mobilnym korelowało z 8,4% wzrostem konwersji w retail. Dane są stare, mechanizm aktualny: każda sekunda opóźnienia zwiększa bounce rate i obniża RPM reklamowy. CWV to więc nie tylko SEO, ale też bezpośredni przychód.

LCP, INP, CLS — definicje i progi 2026

Każda metryka mierzy inny wymiar doświadczenia użytkownika i reaguje na inne klasy problemów. Zrozumienie co dokładnie mierzy każda z nich jest warunkiem skutecznej diagnostyki — bez tego fix jest loteriąza.

LCP — Largest Contentful Paint

LCP mierzy czas, w którym największy element widoczny w viewporcie (hero obraz, nagłówek H1, wideo plakatu) wyrenderował się po nawigacji. Liczony jest od navigationStart. W 2026 elementy kandydatów to <img>, <image> w SVG, <video> z plakatem, blok tekstu w widocznym obszarze oraz tła CSS ładowane przez url().

Próg „dobre” to 2,5 sekundy na p75. Pomiędzy 2,5 a 4 s — „wymaga poprawy”. Powyżej 4 s — „słabe”. Ważne: LCP zmienia się dynamicznie w trakcie ładowania — ostatecznym kandydatem jest element z największą powierzchnią widoczną w momencie pierwszej interakcji użytkownika.

INP — Interaction to Next Paint

INP mierzy opóźnienie między interakcją użytkownika (kliknięcie, dotyk, klawisz) a następnym renderem po przetworzeniu zdarzenia. W odróżnieniu od dawnego FID, który liczył tylko pierwsze zdarzenie, INP agreguje wszystkie interakcje w sesji i raportuje 98 percentyl (lub maksimum, jeśli jest ich mało).

Próg „dobre” to 200 ms, „wymaga poprawy” do 500 ms, „słabe” powyżej 500 ms. Metryka obejmuje trzy fazy: input delay (czekanie aż główny wątek będzie wolny), processing time (wykonanie handlera) i presentation delay (render po zmianach DOM). Największym winowajcą w 2026 roku są długie zadania JavaScript — każde powyżej 50 ms blokuje główny wątek.

CLS — Cumulative Layout Shift

CLS sumuje wszystkie nieoczekiwane przesunięcia layoutu w czasie życia strony. Każde przesunięcie ma wynik impact fraction × distance fraction, a finalny CLS to największa „sesja” (okno 5-sekundowe) tych przesunięć. Próg „dobre” to 0,1, „wymaga poprawy” do 0,25, „słabe” powyżej 0,25.

Typowe źródła przesunięć w 2026: banery cookies wstawiane po paint, reklamy Google AdSense bez zarezerwowanego miejsca, fonty webowe bez font-display: optional lub size-adjust, obrazy bez atrybutów wymiarów, oraz dynamicznie ładowane komponenty (np. recenzje, komentarze) nad linią contentu.

Tabela progów CWV 2026

Metryka	Dobre (p75)	Wymaga poprawy	Słabe	Jednostka
LCP	≤ 2,5 s	2,5-4,0 s	> 4,0 s	sekundy
INP	≤ 200 ms	200-500 ms	> 500 ms	milisekundy
CLS	≤ 0,1	0,1-0,25	> 0,25	bezwymiarowy
TTFB (pomocnicze)	≤ 0,8 s	0,8-1,8 s	> 1,8 s	sekundy
FCP (pomocnicze)	≤ 1,8 s	1,8-3,0 s	> 3,0 s	sekundy

TTFB i FCP to metryki pomocnicze — nie wchodzą do Core Web Vitals, ale silnie korelują z LCP. Jeśli TTFB jest w kolorze czerwonym, LCP nigdy nie będzie zielone bez interwencji na poziomie serwera lub CDN.

Jak mierzyć CWV — cztery źródła danych

Pomiar CWV zawsze łączy dwa typy danych: field data (realni użytkownicy, dane w CrUX) i lab data (syntetyczne testy w kontrolowanym środowisku). Google ocenia tylko field. Lab służy do diagnozy i szybkiej iteracji.

CrUX — Chrome UX Report

CrUX agreguje dane z przeglądarki Chrome od użytkowników, którzy włączyli synchronizację historii — dla dostatecznie popularnych URL-i Google publikuje p75 CWV z ostatnich 28 dni. Dostęp: CrUX API (URL-level lub origin-level), CrUX BigQuery (miesięczne snapshoty, możliwość analizy historycznej) oraz CrUX Vis Dashboard w Looker Studio.

Limity: URL musi mieć wystarczający wolumen ruchu, aby trafić do CrUX — strony poniżej ~1000 odsłon miesięcznie są agregowane na poziomie origin lub całkowicie brak danych. W takich przypadkach konieczny jest własny RUM.

PageSpeed Insights

PSI łączy dwa widoki: CrUX (field) dla URL-a w górnej sekcji i Lighthouse (lab) dla pojedynczego testu w dolnej. Field data są źródłem prawdy dla kwalifikacji CWV. Lab test pokazuje tylko jeden uruchom na zimnym cache z emulowanym urządzeniem Moto G4 i throttlingiem Slow 4G.

Najczęstszy błąd redaktorów i programistów to mylenie lab z field — strona z Lighthouse score 95 może mieć czerwone CWV w CrUX, bo realni użytkownicy mają wolniejsze urządzenia, gorszy internet i inne wzorce interakcji. Zawsze weryfikuj na p75 w CrUX.

Search Console — raport Core Web Vitals

W Search Console w zakładce „Podstawowe wskaźniki internetowe” Google grupuje URL-e w klastry o podobnym zachowaniu (tzw. URL groups) i raportuje liczbę „dobre / wymaga poprawy / słabe” dla mobile i desktop osobno. To najlepszy widok do priorytetyzacji — pokazuje które szablony (produkt, kategoria, artykuł) mają problem, a nie indywidualne URL-e.

Dane w Search Console opierają się na CrUX, więc również na 28-dniowym oknie p75. Opóźnienie raportowania to zwykle 2-3 dni. Fix wprowadzony dziś będzie widoczny dopiero za 14-28 dni, gdy okno przesunie się wystarczająco, by odrzucić stare pomiary.

RUM — Real User Monitoring

RUM to zbieranie danych CWV bezpośrednio ze swoich użytkowników za pomocą biblioteki web-vitals od Google. Kod wklejony w <head> lub do aplikacji wysyła pomiary LCP, INP i CLS do własnego endpointu (GA4, BigQuery, Datadog, New Relic, self-hosted).

Minimalny snippet RUM w 2026:

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

function sendToAnalytics({name, value, id, rating}) {
  navigator.sendBeacon('/api/rum', JSON.stringify({
    metric: name, value, id, rating,
    url: location.pathname,
    connection: navigator.connection?.effectiveType
  }));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

RUM uzupełnia CrUX w trzech sytuacjach: niski wolumen ruchu (CrUX nie ma danych), potrzeba cięcia po wymiarach (urządzenie, geolokalizacja, typ strony) i szybka weryfikacja po deployu bez czekania 28 dni na CrUX.

Szczegóły konfiguracji i integracji z GA4 opisujemy w poradniku o zaawansowanej konfiguracji GA4 dla SEO — tam pokazujemy event schema pod CWV i jak budować custom dimensions dla segmentacji.

Jak poprawić LCP krok po kroku

Najczęstsza przyczyna słabego LCP w 2026 to kolejność żądań sieciowych w fazie krytycznej — przeglądarka nie wie z wyprzedzeniem, który zasób jest „tym największym”, więc go pobiera dopiero po sparsowaniu CSS. Poniższa sekwencja działań rozwiązuje 80% przypadków.

Krok 1 — zidentyfikuj element LCP

W DevTools Chrome otwórz zakładkę Performance, kliknij Record, przeładuj stronę, zatrzymaj. W sekcji „Timings” znajdziesz czerwony marker LCP — kliknij go, aby zobaczyć element DOM. W PSI element LCP jest podany tekstowo w sekcji diagnostyki.

W Lighthouse panelu alternatywnie użyj atrybutu elementtiming lub samego API Performance: new PerformanceObserver(list => list.getEntries().forEach(e => console.log(e.element))).

Krok 2 — optymalizuj TTFB

Jeśli TTFB przekracza 800 ms, LCP < 2,5 s jest praktycznie niemożliwe. Przyczyny: wolny backend (brak cache, ciężkie zapytania DB), brak CDN, słaba lokalizacja origin serwera. Remedia:

Statyczny cache dla stron publicznych (WP Super Cache, LiteSpeed Cache, Varnish, Cloudflare full page cache).
CDN z edge cache — Cloudflare, Fastly, BunnyCDN. Cel: TTFB poniżej 200 ms w 80% regionów.
HTTP/2 lub HTTP/3 — w 2026 HTTP/3 QUIC redukuje latency w mobile o 15-25% przy słabych połączeniach.
Server-side render cache dla SPA — Next.js ISR, Nuxt cache, dedykowany middleware na Cloudflare Workers.

Krok 3 — priorytetyzuj obraz LCP

Jeśli LCP to obraz hero, dodaj w HTML:

<img src="/hero.webp"
     alt="..."
     width="1200" height="630"
     fetchpriority="high"
     loading="eager"
     decoding="async">

Dodatkowo w <head>:

<link rel="preload" as="image"
      href="/hero.webp"
      fetchpriority="high"
      imagesrcset="/hero-800.webp 800w, /hero-1600.webp 1600w"
      imagesizes="100vw">

Nigdy nie stosuj loading="lazy" na elemencie LCP — to gwarantowany strzał w stopę. fetchpriority="high" jest obsługiwany przez Chrome od wersji 101 i ma priorytet nad domyślnym schedulerem przeglądarki.

Krok 4 — zoptymalizuj format i rozmiar

WebP redukuje rozmiar o 25-35% względem JPEG przy tej samej jakości. AVIF dodatkowe 20-30% względem WebP, ale dłuższy czas dekodowania — dla obrazów LCP powyżej 500 KB koszty dekodowania mogą niwelować zysk transferowy. Standard 2026: AVIF dla obrazów > 100 KB, WebP dla reszty.

Responsywne srcset z breakpointami 400w, 800w, 1200w, 1600w i odpowiednim sizes pozwala mobile’owi pobrać wersję 400 KB zamiast 1,5 MB. Automat w CDN (Cloudflare Polish, Imgix, Bunny.net Image Optimizer) wystarczy do 95% przypadków.

Krok 5 — eliminuj render-blocking resources

CSS i synchroniczny JS w <head> blokują render, a z nim LCP tekstowy. Rozwiązania: critical CSS inline (10-14 KB krytycznych styli), resztę przez <link rel="preload" as="style" onload="this.rel='stylesheet'">. Skrypty zewnętrzne (analityka, reklamy) przenieś do defer lub async i ładuj po interakcji, nie na DOMContentLoaded.

Jak poprawić INP krok po kroku

INP jest w 2026 najczęstszym powodem przejścia strony z „dobre” na „wymaga poprawy” — szczególnie w serwisach z reklamami, tagami marketingowymi i ciężkimi frameworkami SPA. Remedia są trudniejsze niż dla LCP, bo wymagają refaktoru kodu, a nie tylko metadanych.

Krok 1 — znajdź długie zadania

W DevTools Performance nagraj sesję z kilkoma interakcjami (scroll, klik, menu). Zadania dłuższe niż 50 ms zaznaczone są czerwonym znacznikiem „Long task”. Kliknij pasek, aby zobaczyć stos wywołań — najczęściej źródłem są: biblioteki analityczne, third-party widgety (chat, recenzje), hydracja SPA, i własny kod w handlerze zdarzenia.

Alternatywnie użyj API PerformanceObserver z typem longtask w RUM i agreguj dane per strona, aby zidentyfikować szablony z najgorszym INP.

Krok 2 — podziel długie zadania

Jeśli handler wykonuje 200 ms obliczeń, przeglądarka nie może narysować następnej klatki aż do końca. Rozwiązanie: scheduler.yield() w 2026 jest dostępny w Chrome i pozwala oddać wątek przeglądarce co N milisekund:

async function processLargeList(items) {
  for (const item of items) {
    processItem(item);
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield();
    }
  }
}

Dla starszych przeglądarek fallback to setTimeout(resolve, 0) lub requestIdleCallback. Kluczowe: nigdy nie wykonuj >50 ms synchronicznej pracy w handlerze zdarzenia.

Krok 3 — opóźnij third-party skrypty

Tag Manager, piksele, widgety chatu, systemy rekomendacji — każdy dodaje od 50 do 300 ms w głównym wątku. Strategia:

Consent Mode v2 + ładowanie GTM dopiero po uzyskaniu zgody.
Chat widget (Intercom, Tidio) — ładowany po requestIdleCallback lub dopiero po scrollu.
Reklamy — lazy loading poza viewportem z IntersectionObserver, z zarezerwowanym miejscem, żeby nie psuły CLS.
Third-party przeniesione na worker — Partytown w 2026 obsługuje GTM, GA4, Facebook Pixel i większość skryptów marketingowych.

Krok 4 — optymalizuj hydrację SPA

W Next.js, Remix, Nuxt hydracja to proces rekonstrukcji drzewa React/Vue po stronie klienta. Pełna hydracja całej strony w handlerze pierwszej interakcji blokuje INP. Rozwiązania: partial hydration (React Server Components, Astro islands, Qwik resumability) — hydrują się tylko interaktywne wyspy, nie cały dokument.

Szczegóły implementacyjne dla projektów Next.js i React opisujemy w osobnym materiale — jeśli budujesz SPA, przeczytaj nasz poradnik o SEO technicznym dla JavaScript SPA, gdzie porównujemy SSR, SSG, ISR i RSC pod kątem wpływu na CWV.

Krok 5 — zredukuj rozmiar JS bundle

Każde 100 KB JS to ~100 ms czasu parse + compile na średniej klasy Androidzie. Budżet 2026: < 170 KB gzipped JS na stronę typu content. Narzędzia: webpack-bundle-analyzer, Vite bundle visualizer, @next/bundle-analyzer. Techniki cięcia: dynamic import, tree shaking, code splitting per trasa, eliminacja polyfilli dla evergreen browsers (differential loading).

Jak poprawić CLS krok po kroku

CLS jest paradoksalnie najłatwiejszy do naprawy — wystarczy dyscyplina w rezerwowaniu miejsca. Problem polega na tym, że jedno miejsce w layoucie zapomniane przez programistę może zepsuć CLS dla całego szablonu.

Krok 1 — dodaj wymiary do wszystkich mediów

Każdy <img>, <video>, <iframe> musi mieć atrybuty width i height (lub odpowiednik w CSS aspect-ratio). Przeglądarka rezerwuje wtedy pole zanim zasób się pobierze. Dla <picture> z wieloma <source> — wymiary na zewnętrznym <img> wystarczą, jeśli proporcje są identyczne.

Krok 2 — zarezerwuj miejsce na reklamy

AdSense i Google Ad Manager dynamicznie wybierają rozmiar slot’u. Rozwiązanie: statyczna wysokość kontenera reklamowego per breakpoint, z fallbackiem na największy dopuszczalny rozmiar. Wtrącenie treści po deklaracji slotu (np. zakupowe karuzele) musi następować przed paintem, nie po.

Krok 3 — stabilizuj fonty

Font Flash of Unstyled Text (FOUT) i Flash of Invisible Text (FOIT) generują shift, gdy font webowy się załaduje. Remedia w 2026:

font-display: optional dla krytycznych fontów — pokazuje fallback jeśli webfont nie załadował się w 100 ms.
size-adjust, ascent-override, descent-override — dopasowanie metryk fallback font do webfontu, dzięki czemu shift wynosi 0 przy wymianie.
Preload krytycznych fontów z <link rel="preload" as="font" crossorigin>.
Subsetting — tylko glify potrzebne do języka, redukcja rozmiaru o 70-80%.

Krok 4 — kontroluj cookie bannery i pop-upy

Cookie banner wstawiany u góry strony po paint = CLS ≥ 0,3 na starcie. Rozwiązanie: banner renderowany jako overlay z position: fixed, nie w flow dokumentu. Pop-upy po scroll — również position: fixed, z własnym z-index i bez wpływu na layout dokumentu.

Krok 5 — oznacz animacje jako transform/opacity

Animacje szerokości, wysokości, marginesów, positioning (top/left) wywołują layout shift. Używaj transform: translate i opacity — te własności są handled by compositor thread, nie wpływają na CLS. Jeśli animacja jest nieoczekiwana (np. accordion otwierający się automatycznie), CLS jest liczony; jeśli w reakcji na user input w ciągu 500 ms — nie jest.

Najczęstsze błędy przy poprawianiu CWV

Większość projektów popełnia te same błędy — ich świadomość oszczędza 2-3 iteracje fix-deploy-weryfikacja.

Optymalizacja pod Lighthouse zamiast CrUX. Wynik 95 w Lighthouse nie oznacza zielonych CWV. Lighthouse to lab, CrUX to prawda.
Pomiar na desktopie zamiast mobile. Google ocenia mobile i desktop osobno — najczęściej mobile jest słabsze i to ono decyduje o kolorze w Search Console.
Lazy-loading na LCP. loading="lazy" na obrazie hero opóźnia jego żądanie o 200-500 ms. Zawsze eager + fetchpriority="high".
Ignorowanie TTFB. Strona z TTFB 1,5 s nie osiągnie LCP < 2,5 s bez fundamentalnej zmiany infrastruktury.
Traktowanie CWV jako jednorazowego projektu. CWV degraduje z każdym deployem — bez CI check na budżet wydajności regresje wracają co sprint.
Pomijanie 3rd party. Tagi marketingowe i reklamy odpowiadają w medianie za 40% INP i 30% LCP. Bez ich audytu fix core’u nie wystarcza.
Cache bez purge strategy. CDN z TTL 24 h serwuje stary HTML przez dobę po deployu — CrUX widzi mieszankę wersji, weryfikacja trwa 2x dłużej.

Budżet wydajności i CI — jak utrzymać zielone CWV

Wydajność bez budżetu i automatycznej kontroli regresuje w ciągu 3-6 miesięcy. Standard 2026 dla serwisu produkcyjnego: performance budget w CI, który blokuje merge, jeśli przekroczony.

Narzędzia CI:

Lighthouse CI — uruchamia Lighthouse na każdym PR, porównuje z baseline, blokuje jeśli score spada o N punktów.
WebPageTest Server — self-hosted lub chmura, głębsze metryki (TCP, SSL, CPU time) i film z ładowania.
SpeedCurve, Calibre — synthetic RUM dla zespołów, alerty na regresje w metrykach CWV.
Własny RUM + alerting — Grafana/Datadog, alert gdy p75 LCP przekracza próg przez >30 min.

Przykładowy budżet dla szablonu artykułu:

Metryka	Budżet	Alert przy	Block merge przy
LCP (lab, mobile)	< 2,0 s	> 2,2 s	> 2,5 s
INP (lab, mobile)	< 150 ms	> 180 ms	> 200 ms
CLS	< 0,05	> 0,08	> 0,1
JS transferred	< 170 KB	> 200 KB	> 250 KB
Total bytes	< 1 MB	> 1,3 MB	> 1,5 MB

Budżet lab jest ostrzejszy niż próg field (CrUX), bo lab nie widzi prawdziwego throttlingu mobile i rzeczywistych wzorców interakcji — margines 20-25% jest wskazany. Oficjalną dokumentację Core Web Vitals i najnowsze aktualizacje metryk znajdziesz w dokumentacji web.dev/vitals.

Specyfika CWV dla popularnych stacków w 2026

Optymalizacja CWV różni się znacznie w zależności od technologii — te same zasady w WordPress, Next.js i Shopify wymagają innych narzędzi.

WordPress — motyw, wtyczki, cache

WordPress w 2026 odpowiada za ~43% stron w internecie i dominuje także w polskim SEO. Najczęstsze bottlenecki: bloated motywy (Divi, Avada, nadmiernie rozbudowany Elementor), 40+ wtyczek z własnym CSS/JS, brak object cache, domyślne zapytania WP_Query bez limitów.

Szybka checklist:

Motyw z natywnym FSE (Twenty Twenty-Four, GeneratePress, Kadence) — mniej kodu, mniej third-party dependencies.
Wtyczka cache: LiteSpeed Cache (jeśli hosting na LiteSpeed/OpenLiteSpeed), WP Rocket jako płatna opcja z autokonfiguracją, Cachify jako minimalista.
Object cache (Redis lub Memcached) — eliminacja powtarzających się zapytań do DB. Redukcja TTFB z 800 ms do 150 ms to typowy efekt.
CDN na poziomie Cloudflare z APO (Automatic Platform Optimization) dla WordPress — cache HTML na edge, redukcja TTFB globalnie.
Lazy loading obrazów natywny w WP od 5.5 — wystarczy, bez dodatkowych wtyczek.
Wyłącz emoji, embed, oEmbed requesty, jeśli nie są używane — 3-5 requestów mniej na stronę.

Next.js i React — App Router i RSC

Next.js 14+ z App Router i React Server Components zmienił reguły gry dla INP. RSC renderuje część drzewa na serwerze, tylko interaktywne fragmenty trafiają do klienta jako Client Components. W idealnym świecie strona artykułu ma < 50 KB JS zamiast dawnych 300-500 KB.

Praktyka: <Link> z prefetch kontrolowanym, <Image> z automatycznym srcset i lazy loading, streaming SSR dla szybszego TTFB, ISR (Incremental Static Regeneration) dla stron kategorii. Pitfall: nadmierne użycie "use client" — każdy komponent oznaczony client eliminuje korzyść z RSC.

Shopify — motyw Online Store 2.0

Shopify w 2026 wymaga motywów Online Store 2.0 z sekcjami JSON. Bottlenecki: aplikacje z inline JS, app embed bez limitów, hero z obrazem 2 MB. Rozwiązania: audyt aplikacji (Shopify Web Performance dashboard w Admin), lazy app embeds, <img> srcset z img_url filtrami Liquid ({{ img | img_url: '800x' }}), Shopify Oxygen / Hydrogen dla headless commerce przy stawkach enterprise.

Magento/Adobe Commerce — ciężki frontend

Magento historycznie ma słabe CWV ze względu na RequireJS, Knockout i CSS merging. W 2026 standardem jest migracja frontendu na PWA Studio (React + Apollo) lub Hyvä Themes (Alpine.js + Tailwind) — redukcja JS z 500 KB do 50-100 KB, realny skok LCP o 40-60%.

Case: serwis wydawniczy — redukcja LCP z 4,1 s do 1,8 s

Serwis wydawniczy z 2 mln UU miesięcznie miał LCP p75 = 4,1 s na mobile, Search Console oznaczyło wszystkie szablony artykułów jako „słabe”. Projekt trwał 6 tygodni, 3 sprinty, budżet ~45 000 zł.

Audyt i diagnostyka (tydzień 1-2). CrUX pokazał, że LCP = obraz hero w 88% URL-i. Network waterfall: hero.jpg 450 KB ładowany z priorytetem low, po CSS i JS tracking. TTFB = 620 ms (Cloudflare cache miss co 5 requestów).

Fix pierwszy (sprint 1). Dodanie fetchpriority="high" + preload dla obrazu hero w Liquid/PHP szablonie. Konwersja JPEG do WebP przez Cloudflare Polish. Efekt w RUM po 3 dniach: LCP p75 spadł z 4,1 s do 2,9 s.

Fix drugi (sprint 2). Migracja reklam na lazy load z IntersectionObserver, przeniesienie GTM na Partytown worker, inline’owanie critical CSS (12 KB). Efekt: LCP 2,9 s → 2,1 s, INP 290 ms → 160 ms.

Fix trzeci (sprint 3). Optymalizacja cache Cloudflare (custom cache rules + APO), eliminacja render-blocking fontów przez font-display: optional. Efekt finalny po 28 dniach w CrUX: LCP 1,8 s, INP 145 ms, CLS 0,04. Wszystkie szablony w Search Console na zielono.

Efekt biznesowy: +12% sesji organicznych w ciągu 90 dni (prawdopodobnie w części dzięki CWV, w części dzięki core update w tym samym oknie), +18% RPM reklamowy (krótszy czas ładowania = więcej wyświetleń reklam w sesji). ROI projektu: 4 miesiące.

Priorytetyzacja — co naprawiać najpierw, gdy wszystko jest czerwone

Jeśli serwis ma słabe LCP, INP i CLS jednocześnie, kolejność działań jest kluczowa — naprawa w złej kolejności marnuje 2-3 sprinty. Rekomendowana sekwencja:

Najpierw TTFB i LCP. Szybszy TTFB ułatwia wszystkie pozostałe metryki. Cache, CDN i HTTP/3 zwykle dają największy skok przy najmniejszym nakładzie pracy.
Następnie CLS. Najłatwiejszy do fix — atrybuty wymiarów, rezerwacja slotów reklamowych, font-display: optional. Daje szybki win w 1-2 dni.
Na końcu INP. Najtrudniejszy, bo wymaga refaktoru JS, audytu third-party i często zmian architektury. 3-6 tygodni w średnim projekcie.

Wyjątek: jeśli INP jest masowo czerwone (np. > 500 ms) z powodu jednej konkretnej biblioteki (np. stary slider Owl Carousel, Select2), usunięcie tej jednej zależności daje natychmiastowy efekt i można zacząć od niej.

Monitorowanie po deployu — co sprawdzić w pierwszych 48 godzinach

Po wdrożeniu poprawki cykl weryfikacji wygląda następująco:

Godziny 0-2: lab test (Lighthouse, PSI) na produkcji — czy fix w ogóle się wdrożył. Sprawdź critical path: HTML, CSS, JS w Network tab.
Godziny 2-48: RUM — czy realni użytkownicy widzą poprawę. Cięcie po device, kraju, szablonie. Wolumen 1000+ sesji daje już stabilny median.
Dni 2-7: CrUX API — najwcześniejsze sygnały zmiany p75, ale dane wciąż uśredniają stare pomiary.
Dni 14-28: pełny efekt widoczny w CrUX i Search Console. 28 dni to pełny zestaw danych p75 po fixie.

Najczęstszy błąd na tym etapie: zbyt wczesna deklaracja sukcesu. Lab zielony + RUM zielony ≠ CrUX zielony. Dopiero po 14 dniach można zacząć wyciągać wnioski z danych terenowych.

FAQ — najczęstsze pytania

Czy Core Web Vitals to czynnik rankingowy w 2026?

Tak, ale o umiarkowanej wadze. CWV to jeden z sygnałów page experience obok HTTPS, mobile-friendliness i braku intruzyjnych reklam. Nie pokona słabej treści, ale przy równej jakości merytorycznej może rozstrzygnąć, która strona wygra pozycję. Największy wpływ CWV ma w branżach konkurencyjnych, gdzie wiele wyników ma podobną jakość — e-commerce, wydawnictwa, porównywarki.

Czym różni się INP od starego FID?

FID mierzył tylko opóźnienie pierwszej interakcji i tylko input delay. INP agreguje wszystkie interakcje w sesji i liczy pełne opóźnienie do następnego paintu (input delay + processing + presentation). INP jest znacznie trudniejszy do zaliczenia — wiele serwisów, które miały zielone FID, wpadło w czerwień po zamianie z marca 2024.

Dlaczego moja strona ma zielony Lighthouse a czerwony CrUX?

Lighthouse to lab — testuje z konkretnego urządzenia, konkretnej sieci, konkretnej lokalizacji, na zimnym cache. CrUX to dane od realnych użytkowników z całego świata, z różnymi urządzeniami i połączeniami. Typowe źródło rozbieżności: Lighthouse nie symuluje reklam i zgody na cookies, które dokładają 200-400 ms INP w produkcji. Zawsze optymalizuj pod CrUX.

Ile kosztuje utrzymanie zielonych CWV w 2026?

Jednorazowa optymalizacja średniego serwisu WordPress: 3 000-15 000 zł (audyt, fixy w motywie, konfiguracja cache, CDN). Utrzymanie: 500-2 000 zł miesięcznie za monitoring RUM, performance budget w CI i okresowe audyty. Dla e-commerce i dużych wydawnictw koszty są wyższe (15 000-80 000 zł za pełen projekt), ale ROI w postaci konwersji i RPM reklamowego zwraca się w 3-6 miesięcy.

Jak długo czekać na efekty po wdrożeniu fixu?

W lab (Lighthouse, PSI test) natychmiast. W RUM — w ciągu godzin, jeśli masz wolumen ruchu. W CrUX i Search Console — 14-28 dni, bo Google liczy p75 z okna 28-dniowego. Nie zmieniaj kolejnych rzeczy zanim nie zobaczysz stabilnego wyniku w CrUX, bo trudno będzie potem przypisać efekt konkretnemu fixowi.

Co robić, gdy CrUX nie ma danych dla mojej strony?

Oznacza to niski wolumen ruchu (mniej niż ~1000 odsłon miesięcznie dla URL-a lub origin). Opcje: użyć danych origin-level zamiast URL-level, zainstalować własny RUM (biblioteka web-vitals + endpoint) i zbierać dane samodzielnie, lub polegać na lab testach z konserwatywnym marginesem (próg lab 20-30% poniżej progu field). Własny RUM jest najbezpieczniejszy, bo widzi prawdziwych użytkowników.

Czy AMP nadal poprawia CWV w 2026?

Od 2022 AMP nie jest już wymagany do pojawienia się w Top Stories i nie daje premii rankingowej. Nadal jednak wymusza dobre CWV poprzez restrykcyjny runtime. W 2026 większość wydawców zrezygnowała z AMP, bo dobrze zoptymalizowana zwykła strona osiąga te same wyniki bez ograniczeń AMP HTML. Jeśli masz wybór — buduj „zwykłą” stronę z performance budget, nie AMP.

Co zrobić z third-party skryptami, których nie mogę usunąć (klient wymaga)?

Trzy poziomy obrony: (1) Partytown — przeniesienie wykonania na Web Worker, eliminacja wpływu na główny wątek; (2) lazy loading — skrypt ładowany po pierwszej interakcji, scrollu lub z opóźnieniem 3-5 s; (3) self-hosting z proxy — hostuj kopię skryptu u siebie, aby uniknąć latency third-party CDN. Udokumentuj wpływ każdego tagu w RUM, pokaż dane klientowi — często jest otwarty na zmianę, gdy widzi liczby.

Co dalej

Poprawa Core Web Vitals to tylko jeden element SEO technicznego — jeśli chcesz objąć cały obszar, zacznij od naszej checklisty audytu SEO technicznego 2026, a potem wróć do CWV z listą priorytetów. Dla serwisów o dużej skali warto też sprawdzić, jak na wydajność wpływa optymalizacja crawl budget — szybsze ładowanie to więcej odwiedzin robota i szybsza indeksacja nowych treści.