LCP, INP, CLS — co naprawdę wpływa na wyniki

LCP, INP i CLS to trzy metryki, które Google traktuje jako page experience signals. Każda mierzy inny aspekt realnego doświadczenia użytkownika: jak szybko zobaczył najważniejszy element, jak szybko strona zareagowała na jego pierwszą interakcję, ile razy cokolwiek „skoczyło” mu pod palcem. W 2026 wszystkie trzy są mierzone w terenie – z realnych sesji – a nie w laboratorium.

Ten artykuł nie jest definicją Core Web Vitals – to macie już w przewodniku po CWV 2026. Tutaj rozkładamy każdą z trzech metryk na czynniki pierwsze: co wpływa realnie, co tylko „teoretycznie”, które optymalizacje mają ROI, a które są marnowaniem czasu. Na końcu – playbook 30-dniowy dla typowej strony.

Piszemy z doświadczenia agencji, która w 2024–2025 przeprowadziła 47 projektów optymalizacji CWV na stronach WordPress, Shopify, Magento i custom React/Next.js. Średni lift po 8 tygodniach: LCP z 3,4s na 1,8s, INP z 380ms na 140ms, CLS z 0,24 na 0,05. Pozycje SERP – średnio +3,2 rank, organic traffic +18% r/r dla stron, gdzie CWV były wcześniej „poor”.

LCP — co naprawdę wpływa na pomiar

Largest Contentful Paint mierzy czas od nawigacji do pojawienia się największego elementu widocznego w viewport. W 78% przypadków tym elementem jest główny obraz (hero image), w 15% blok tekstowy (H1 + paragraf intro), w 7% element wideo.

Pomiar zaczyna się w momencie user-perceived navigation start (nie DOM ready, nie TTFB – wcześniej). Kończy się, gdy ten największy element jest zaraportowany przez browser rendering engine. Strona „nigdy nie kończy” LCP – ostateczna wartość to ten największy element, jaki pojawił się do momentu pierwszej interakcji użytkownika.

Pięć rzeczy, które naprawdę ciągną LCP w dół

1. TTFB (Time to First Byte). Bez odpowiedzi serwera nie ma strony. TTFB > 600ms jest silnym sygnałem, że LCP nie zejdzie poniżej 2s. W Polsce 40% stron WordPress hostowanych na współdzielonych hostingach ma TTFB 700–1400ms. Migracja na VPS z SSD i CDN daje zwykle redukcję do 180–320ms.

2. Priorytet zasobu LCP. HTML parser znajduje obraz hero dopiero po sparsowaniu nagłówków. Użycie <link rel="preload" as="image"> w head, a w 2025 także fetchpriority="high" na <img>, daje przesunięcie rozpoczęcia pobierania o 400–800ms wcześniej. Szczegóły znajdziesz w metodyka audytu SEO.

3. Rozmiar i format obrazu. JPEG 180 KB vs WebP 42 KB to różnica 3x w czasie pobierania na 4G. W 2026 standardem jest AVIF lub WebP, responsive srcset dla 4 breakpointów (320, 640, 1024, 1920) i lazy-loading tylko dla obrazów below-the-fold – nigdy dla LCP image.

4. Render-blocking CSS. Gigantyczny plik CSS (globalny styles.css ważący 340 KB) opóźnia pierwszy render o 200–600ms. Critical CSS w head + reszta async lub defer to klasyczna optymalizacja, która w 2026 jest nadal niezbędna.

5. Web fonts bez font-display: swap. Font Google Fonts ładowany synchronicznie blokuje render tekstu do pobrania. font-display: swap każe przeglądarce pokazać tekst w zapasowym fałszywym foncie, dopóki właściwy nie przyjdzie – LCP mierzy widoczny tekst, nie „ostateczny” wygląd.

Trzy rzeczy, które wydają się ważne – a nie są

• Total bytes strony – strona 4 MB z dobrze priorytetyzowanym LCP image (400 KB, preload, fetchpriority=high) może mieć LCP 1,4s. Strona 800 KB źle skonfigurowana – LCP 3,2s.
• Number of requests – z HTTP/2 i HTTP/3 koszt dodatkowego requestu jest znikomy. 80 requestów dobrze rozłożonych w czasie jest szybsze niż 15 requestów w bottlenecku.
• GZIP/Brotli na wszystkim – dla obrazów (już skompresowane) kompresja GZIP daje 2–3% redukcji. To nie ruszy LCP. Brotli na HTML/CSS/JS – tak, warto.

INP — metryka, która zastąpiła FID w 2024

Interaction to Next Paint zastąpił First Input Delay w marcu 2024. Kluczowa różnica: FID mierzył tylko pierwsze kliknięcie, a INP mierzy wszystkie interakcje (click, tap, keypress) i raportuje 75-percentyl. To znacznie bardziej wymagająca metryka.

INP składa się z trzech części. Input delay (czas od eventu do rozpoczęcia handlera). Processing time (czas wykonania handlera). Presentation delay (czas od zakończenia handlera do następnego paintu). Całość musi zmieścić się ≤ 200ms, żeby być „good”.

Gdzie ginie INP

Long tasks (> 50ms). JavaScript wykonujący się ponad 50ms blokuje main thread i odkłada każdą interakcję. Na stronach z ciężkim React/Vue/Angular bez code splittingu main thread jest zablokowany 200–1200ms w pierwszych sekundach po załadowaniu – każde kliknięcie w tym oknie ma INP powyżej 500ms.

Third-party skrypty. Google Tag Manager, Hotjar, Intercom, AB test tools – razem łatwo 800ms+ long tasks. Każdy dodany skrypt trzeba zaważyć: czy daje wartość proporcjonalną do kosztu INP?

React re-renders bez memoizacji. Niewłaściwe użycie useState wywołujące renderowanie całego drzewa komponentów zamiast jego fragmentu – częsty powód INP 300–800ms w aplikacjach Next.js. Rozwiązania: React.memo, useMemo, useCallback, podział stanu na mniejsze komponenty. Temat szerzej omawiamy w pełny przewodnik SEO 2026.

Synchroniczny DOM manipulation w handlerze. Kod typu „po kliknięciu pobierz 200 elementów, zmień im klasę, usuń połowę” jest zabójczy dla INP. Zamiast tego: użyj requestIdleCallback, requestAnimationFrame, lub przesuń do worker threada.

Optymalizacje, które działają – przykład z projektu

Klient: e-commerce na Magento 2, 8000 produktów, INP mobile P75 = 580ms (przed). Optymalizacje, które wykonaliśmy w 6 tygodni:

1. Code splitting. Rozbicie jednego bundle.js (1,8 MB) na 12 chunków ładowanych on-demand – INP spadło o 140ms.
2. Usunięcie niewykorzystanego JS. Deprecated moduł chat live, stary system AB testów – 320 KB mniej – INP spadło o 60ms.
3. Lazy-load third-party. Hotjar i Intercom ładowane po 3s idle – INP w pierwszych 10s sesji spadło o 110ms.
4. Memoizacja product grid. React.memo na kartach produktów – INP przy hoverach/filtrowaniu spadło o 80ms.
5. Przeniesienie analytics do worker threada. GTM + custom tracking przez Partytown – INP spadło o 50ms.

Rezultat końcowy: INP P75 = 148ms (good). Conversion rate mobile +6,4% po 3 miesiącach (przypisanie w miare możliwe – wykluczyliśmy inne zmiany w tym okresie).

CLS — metryka UX, której nie możesz zignorować

Cumulative Layout Shift mierzy sumę wszystkich nieoczekiwanych przesunięć elementów na stronie od załadowania do pierwszej interakcji użytkownika. Każde przesunięcie ma wagę (impact fraction × distance fraction). Strona dobrze zaprojektowana ma CLS 0,00–0,05. Strona źle – 0,25–0,80.

CLS ma największy rozdźwięk między lab a field. W Lighthouse często widać CLS 0,05 (green), podczas gdy CrUX (field data) pokazuje 0,24 (poor). Powód: Lighthouse uruchamia się w sterylnych warunkach, w polu strona ładuje dynamic content, reklamy, A/B testy – wszystko to generuje shifty, których lab nie widzi.

Sześć źródeł shiftów, które eliminujecie w pierwszej kolejności

1. Obrazy bez width i height. Przeglądarka rezerwuje przestrzeń dopiero po załadowaniu obrazu – wszystko pod nim „skacze” w dół. W 2026 standardem jest ustawianie w HTML atrybutów width/height (ratio-aware) lub CSS aspect-ratio. Efekt: zero shiftu z obrazów.

2. Reklamy Google AdSense/AdManager. Banner ładuje się async i wypycha content o 250–600 pikseli. Rozwiązanie: minimum height dla slotu reklamowego, proszone przez Google w ich guidelines od 2022.

3. Web fonts bez size-adjust. Fallback font ma inne metryki niż webfont – po załadowaniu tekst „skacze”. Dyrektywa size-adjust: 105% w @font-face dopasowuje fallback do webfontu. Zera CLS zamiast 0,08.

4. Dynamicznie wstawiany banner cookie. Banner pojawiający się 500ms po załadowaniu strony powoduje shift 200–400px. Rozwiązanie: banner jako overlay (position: fixed dół lub góra) zamiast wstawiony w flow.

5. Lazy-loading iframe (YouTube, Maps). Iframe bez rezerwacji wysokości powoduje shift równy wysokości wideo. Atrybut height jest niezbędny.

6. CSS late-loaded. Strona renderuje się najpierw bez stylów, potem po pobraniu CSS się przemeblowuje. To najgorszy UX i największy CLS. Critical CSS inline w head eliminuje problem.

Jak mierzyć CWV dobrze — RUM vs lab

Największy błąd w optymalizacji CWV: optymalizowanie pod Lighthouse zamiast pod realnymi użytkownikami. Lighthouse to symulator – testuje jedną konfigurację (emulowany iPhone, 4G slow). CrUX (Chrome User Experience Report) to real user data z prawdziwych sesji Chrome 28-dniowych.

Google do rankingu używa CrUX, nie Lighthouse. Dlatego metryki muszą być mierzone w terenie. Trzy źródła danych:

Źródło	Typ	Kiedy używać	Ograniczenia
Google Search Console — Core Web Vitals report	CrUX aggregated	Weryfikacja statusu good/needs improvement/poor per URL pattern	Agregacja per group URL, brak granularności sesji
PageSpeed Insights — Field Data	CrUX per URL	Konkretne strony, porównanie do średniej	Tylko dla URL z dostatecznym ruchem
CrUX API	Raw data	Custom dashboardy, trendy historyczne	Wymaga API key, limit dzienny
Lighthouse (PSI lab, DevTools)	Lab simulation	Debugging, testowanie zmian przed deployem	Nie odpowiada realnym użytkownikom
Własny RUM (web-vitals.js, SpeedCurve, Calibre)	Field real-time	Szczegóły segmentów (device, country, viewport)	Wymaga wdrożenia, koszt narzędzia

Co patrzyć w RUM — segmentacja

Pomiar średnich ukrywa problem. Zawsze segmentujcie:

• Device type – mobile P75 vs desktop P75 różnią się często 2x.
• Geolocation – użytkownicy z DACH często mają lepszy CWV niż użytkownicy z PL (hosting EU nie jest wszędzie równy).
• Effective connection type – 4G vs 3G vs slow-2G. INP/LCP zachowują się inaczej.
• Page type – homepage, listingowa, produkt, blog, checkout – każdy ma inne profile.
• First vs returning visitor – cache pomaga returning, homepage pierwszego visita jest najwolniejsza.

CWV jako sygnał rankingowy — jak mocno?

Google oficjalnie potwierdził w 2021 i zaktualizował w 2024, że CWV są częścią page experience signals. W praktyce waga jest umiarkowana – CWV działają jako tie-breaker między dwiema stronami o podobnej relevance i autorytecie, nie jako pierwotny czynnik rankingowy.

Własne obserwacje (47 projektów, 2024–2025): strony z CWV wszystkich trzech metryk „good” mają średnio +2,8 pozycji lepiej niż porównywalne strony z „poor”. Ale tylko wtedy, gdy content i linki są na porównywalnym poziomie. Strona z słabym contentem i idealnym CWV nie wygra z mocnym contentem i średnim CWV.

Gdzie CWV liczy się najbardziej

• Mobile-first SERP – mobile CWV mają większą wagę niż desktop (Google indeksuje mobile).
• Kompetytywne nisze – gdy 10 stron walczy o ten sam keyword, CWV często decyduje top 3 vs top 10.
• E-commerce produktowe – przeciętnie widzimy wyraźniejszy efekt niż na informacyjnych blogach.
• Local SERP – mobile-first + lokalne intenty preferują szybkie strony.

Gdzie CWV ma mniejszą wagę

• Nisze z małą konkurencją (CWV poor nie przeszkadza, gdy top 10 ma średnio taki sam problem).
• Brandowe keywordy (intent silny, pages bez alternatywy).
• YMYL topics – tam E-E-A-T przeważa wszystko.

Debugging INP — które narzędzia robią robotę

INP jest najtrudniejszą metryką do zdebugowania, bo problem pojawia się tylko podczas interakcji – trudno go złapać w lab. Dwie techniki:

Chrome DevTools Performance panel

Nagraj sesję, kliknij na problematyczny element, obejrzyj timeline. Interesują cię: (1) „Long tasks” markery, (2) „Event handler” blocks – ile ms trwały, (3) „Style recalc” i „Layout” zdarzenia – ile razy się przeliczają. W 90% przypadków problem widać na osi czasu.

web-vitals.js z attribution

Biblioteka web-vitals.js od Google (v3+) ma tryb attribution, który raportuje INP z kontekstem: nazwa eventu, nazwa elementu (jeśli ma id), czas każdej fazy. Wdrożenie 30 linii kodu – wysyłasz raporty do własnego endpointu lub do GA4, analizujesz trendy.

Przykład raportu dla jednej sesji z INP 640ms: {event: 'click', element: '#cart-button', phases: {inputDelay: 12, processingTime: 580, presentationDelay: 48}}. Wniosek: problem w handlerze cartButton – tam szukać.

Real user monitoring tools

• SpeedCurve RUM (149 USD/mies.) – dashboardy, segmentacja, alerty.
• Calibre (89 USD/mies.) – bardziej techniczny, integracje z CI/CD.
• Datadog RUM (koszt na podstawie wolumenu) – dla firm z już wykupionym Datadogiem.
• Custom GA4 + BigQuery (koszt infrastruktury) – najwięcej elastyczności, największy overhead ustawienia.

Obrazy — największy lewar dla LCP

W 78% projektów, gdzie startujemy z LCP > 3s, głównym powodem są źle skonfigurowane obrazy. Nawet po migracji na szybki hosting, bez optymalizacji obrazów LCP nie schodzi poniżej 2,5s.

Checklist obrazu LCP

1. Format: AVIF (preferowany) lub WebP z fallbackiem PNG/JPEG przez <picture>.
2. Rozmiar: responsive srcset dla 3-4 breakpointów; nie serwuj 1920px desktop na 375px mobile.
3. Wymiary w HTML: zawsze atrybut width i height (lub aspect-ratio w CSS) – zabezpieczenie CLS.
4. Preload: <link rel="preload" as="image" fetchpriority="high"> dla hero image.
5. Decoding: atrybut decoding="sync" dla LCP image, async dla reszty.
6. Lazy-loading: NIGDY na LCP image; zawsze below-the-fold.
7. CDN z image optimization (Cloudflare, Cloudinary, ImageKit) – automatyczna konwersja formatów per device.

Case – WordPress blog branżowy

Przed: LCP P75 mobile = 4,1s. Hero image 2400×1600 JPEG 480 KB, brak srcset, lazy=”lazy” ustawione przez plugin SEO.

Zmiany (1,5 dnia pracy developera): (1) konwersja do AVIF przez plugin ShortPixel, (2) srcset 480/768/1200/1920, (3) usunięcie lazy na hero, (4) preload w head, (5) fetchpriority=high.

Po: LCP P75 mobile = 1,8s. Mediana obrazu 58 KB. Pozycja w SERP dla głównego keyword +4 w 5 tygodni.

WordPress – najczęstsze pułapki CWV

W Polsce 60% stron to WordPress. Typowe problemy CWV na WP mają powtarzalny wzór – opisujemy je szczegółowo w dedykowanym przewodniku WordPress Core Web Vitals, tutaj skrót.

Pięć kwestii, które pogrążają WP

• Page builder Elementor/Divi – generują 3–5x więcej DOM nodes niż klasyczny Gutenberg. LCP i INP cierpią. Alternatywa: blocks native, Kadence, GenerateBlocks.
• Shared hosting z TTFB 600ms+ – migracja na VPS z PHP 8.3 + OPcache + object cache (Redis) redukuje TTFB do 150–250ms.
• Slider/Carousel w hero – wielkie biblioteki JS (Swiper, Slick) ładowane synchronicznie. Usunąć slider (ROI niski i tak) lub zastąpić statycznym hero.
• Lazy-loading pluginy ustawiające lazy na wszystkim – łącznie z LCP. Sprawdzić ustawienia i wyłączyć lazy dla hero.
• Fonty Google Fonts lokalnie – bez font-display:swap, bez preload, bez subsetów. Każdy z tych błędów = 100–300ms LCP.

E-commerce – specyfika Shopify, Magento, WooCommerce

E-commerce ma inne wyzwania niż content sites. Strony produktowe mają dużo obrazów, widget’ów (rozmiar, kolor, recenzje), zewnętrznych skryptów (chat, analytics, retargeting).

Shopify

Themes 2.0 są lepsze niż 1.0, ale wszystkie mają dług technologiczny: jQuery, sekcje blocków, async scripts. INP P75 na średnim Shopify = 280–420ms. Optymalizacje: theme custom (nie z marketplace), usunięcie niepotrzebnych apek, Shopify Online Store 2.0 sections z lazy sections, CDN z image optimization.

Magento 2

Magento jest znany z najgorszego CWV w e-commerce. LCP P75 standardowej instalacji to 4–6s. Optymalizacje: full page cache (Varnish), Redis, flat catalog, usunięcie nieużywanych modułów, PHP 8.2+, custom theme z minimalnym CSS/JS.

WooCommerce

Lepszy niż Magento, gorszy niż Shopify w defaultach. Optymalizacje: object cache (Redis), fragments caching (mini-cart), usunięcie AJAX cart na mobile, LiteSpeed Cache lub WP Rocket.

Playbook 30 dni — optymalizacja CWV dla typowej strony

Plan wdrożenia dla firmy, która dostała w Search Console status „needs improvement” lub „poor” na którymś z CWV.

Dni 1–7: diagnoza

• Pobieranie CrUX data z PageSpeed Insights dla top 20 URL.
• Segmentacja: mobile vs desktop, który URL ma który problem.
• Lighthouse na 5 reprezentatywnych stronach – identyfikacja root cause.
• Wdrożenie web-vitals.js lub SpeedCurve dla ciągłego RUM.
• Raport baseline: LCP/INP/CLS P75 dla każdego segmentu.

Dni 8–21: implementacja

• Quick wins: <img width/height>, font-display:swap, lazy poza LCP.
• Obrazy: konwersja do WebP/AVIF, responsive srcset, preload LCP.
• JS: code splitting, lazy-load third-party, defer nie-kritycznego.
• CSS: critical inline, reszta async.
• CWV config: Cloudflare lub hosting CDN + cache.

Dni 22–30: weryfikacja i iteracja

• Nowy raport RUM – porównanie przed/po.
• Search Console CWV report odświeżanie (28 dni CrUX – pełny efekt widoczny 4–6 tyg. później).
• Lighthouse CI w pipeline – alerty przy regresach.
• Identyfikacja pozostałych 20% problemów – plan na kolejny sprint.

Integracja z GA4, CrUX API i pipeline CI/CD

CWV bez ciągłego monitoringu to jednorazowy sprint optymalizacji – po 3 miesiącach strona regresuje do stanu wyjściowego. Jedyny sposób utrzymania statusu „good” to wbudowanie CWV w stały pipeline inżynierski.

GA4 jako storage dla RUM

Biblioteka web-vitals.js (Google) wysyła raporty do dowolnego endpointu. Najtańsze rozwiązanie: GA4 events z custom parametrami (metric_name, metric_value, page_type, device, country). Koszt: zerowy, bo GA4 jest darmowy. Ograniczenie: agregacja tylko w GA4 Explorations lub BigQuery – brak natywnego dashboardu.

Przykład integracji: onLCP(({value, name}) => gtag('event','web_vitals',{name, value: Math.round(value), page_type: pageType})). W GA4 explorations filtrujemy po name=’LCP’, agregujemy per page_type, wyciągamy P75. Koszt wdrożenia: 2-4 godziny seniora frontend.

CrUX API — dane historyczne i konkurencja

CrUX API umożliwia pobieranie danych CWV dla dowolnej publicznej strony – w tym konkurencji. To unikalna przewaga: wiesz, jakie CWV ma twój topowy konkurent na mobile, i czy ty jesteś lepszy.

Praktyka: cotygodniowy job w Airflow lub GitHub Actions pobiera dane dla 50 stron (własne top pages + 10 konkurentów), zapisuje do BigQuery, wyświetla w dashboardzie Looker Studio. Koszt: kilka godzin seniorskiego inżyniera + darmowa infrastruktura.

Lighthouse CI w GitHub Actions

Każdy pull request powinien mieć automatyczny audit CWV. Lighthouse CI (oficjalne narzędzie Google) w GitHub Actions uruchamia Lighthouse na deploy preview i porównuje z main. Threshold: regresja >5% LCP lub INP blokuje merge.

Wdrożenie: plik lighthouserc.js z URL-ami do testowania, job w .github/workflows/, artefakt z raportem w każdym PR. Koszt: 1 dzień DevOps. Efekt: zero regresji z nowych deployów – największy długoterminowy zysk.

PageSpeed Insights Webhook dla alertów

Codzienne sprawdzenie statusu CWV przez PSI API + Slack webhook przy zmianie z „good” na „needs improvement”. Skrypt 50 linii Node.js, uruchamiany cron. Koszt operacyjny: zero. Wartość: reakcja w 24h zamiast 4 tygodni.

Zespół i role — kto pracuje nad CWV w 2026

CWV to nie zadanie „SEO specjalisty w wolnej chwili”. To cross-functional work – frontend developer, DevOps i SEO analityk muszą współpracować.

Skład zespołu dla średniej firmy

Rola	Zaangażowanie	Wynagrodzenie PL (brutto)	Zakres
Frontend senior	20–30% etatu na 3 mies.	14–22 tys. zł/mies.	Code splitting, image optimization, React performance
DevOps / SRE	10–15% etatu	16–24 tys. zł/mies.	CDN, cache, TTFB, hosting tuning
SEO analityk techniczny	15–25% etatu	8–14 tys. zł/mies.	CrUX analiza, prioryt. zadań, raportowanie do biznesu
Product manager	5% etatu	15–20 tys. zł/mies.	Decyzje trade-off UX vs performance (reklamy, chat, AB testy)

Freelance stack dla mniejszych firm

Dla firmy 1–10 osób bez własnego frontendu: agencja CWV-focused kosztuje 5–18 tys. zł za pierwszy sprint optymalizacji + 2–4 tys. zł/mies. retainer na monitoring i naprawy. Model jest skuteczny dla branż, gdzie strona to główny kanał sprzedaży.

ROI optymalizacji CWV — realne liczby

Pytanie, które powinna zadać sobie każda firma przed inwestycją w CWV: jaki jest business case? Trzy wymiary:

1. Konwersja

Research Amazon 2006: każde 100ms opóźnienia = 1% mniej sprzedaży. Replikacje w 2020 i 2023 (Google, Cloudflare, Akamai) potwierdziły zależność, choć liczby są mniejsze dziś – średnio 0,5–0,9% sprzedaży na 100ms dla e-commerce, 0,2–0,4% dla leadgen.

Praktycznie: strona robiąca 100 tys. zł miesięcznie, optymalizacja LCP z 3,5s na 1,8s = średnio +4–6% przychodu = 4–6 tys. zł/mies. Zwrot z inwestycji 15 tys. zł (typowy koszt optymalizacji) w 3–4 miesiące.

2. Ranking SEO

Z 47 projektów 2024–2025: średni lift pozycji po 2–3 miesiącach od optymalizacji CWV to +3,2 pozycji dla stron, które wcześniej były w top 20. Dla top 3 efekt mniejszy (+0,5–1,2). Dla poza top 20 efekt większy (+5–8) – ale tam CWV nie jest jedynym problemem.

3. User experience metrics

• Bounce rate spada średnio -8–15% po dużej poprawie LCP.
• Pages per session rośnie +5–12%.
• Session duration +10–18%.
• Mobile conversion rate rośnie wyraźniej niż desktop (2–3x większa dźwignia).

FAQ — najczęstsze pytania

Czy LCP poniżej 2,5s wystarczy, żeby Google uznał stronę za „good”?

Tak, ale musi to być P75 – czyli 75% wszystkich pomiarów z 28 dni musi być ≤ 2,5s. Jeden pomiar 2s nie wystarczy, jeśli 30% użytkowników ma 3,5s. Pilnuj CrUX data, nie pojedynczych testów Lighthouse. Dodatkowo: musisz pilnować trendu, bo regresje pojawiają się ciągle (nowy plugin, zmiana hero image, third-party update).

Co różni INP od FID i dlaczego jest trudniejszy?

FID mierzył tylko pierwszą interakcję i brał input delay (czas od eventu do rozpoczęcia handlera). INP mierzy wszystkie interakcje i raportuje 75-percentyl całego cyklu (input delay + processing + presentation). Strona z FID 80ms może mieć INP 400ms, bo w ciągu sesji pojawia się kilka ciężkich interakcji. INP ujawnia problemy, których FID nie widział.

Czy CLS 0,1 to już dobry wynik czy trzeba schodzić niżej?

0,1 jest progiem „good” Google – 75% użytkowników musi mieć ≤ 0,1. Strony premium osiągają 0,00–0,03. Schodzenie poniżej 0,05 rzadko daje dalszy wzrost rankingu, ale daje lepszy UX subiektywnie. Nie optymalizuj obsesyjnie – skup się na INP jeśli masz już CLS 0,05, tam jest zwykle więcej do wyciśnięcia.

Jak często Google odświeża CrUX data?

CrUX aktualizuje się codziennie, ale okno to 28 dni. Oznacza to, że efekt twoich optymalizacji pojawia się stopniowo: dzień 1 po deployu widzisz ułamek poprawy (1/28), pełny efekt po 28 dniach. Raportowanie w Search Console ma dodatkowe opóźnienie 3–5 dni. Łącznie pełny wynik widoczny w GSC po 31–33 dniach od wdrożenia.

Czy warto używać Lighthouse jako benchmarku?

Lighthouse jest świetny do debugowania i weryfikacji zmian w środowisku developerskim, ale nie odpowiada metryce rankingowej. Używaj go do: (1) testów regresji przed deployem, (2) identyfikacji root cause, (3) CI/CD alertów. Nie używaj do: raportowania klientowi stanu CWV, porównań z konkurencją, decyzji biznesowych. Do tych rzeczy służy CrUX i realny RUM.

Ile kosztuje optymalizacja CWV dla typowej strony?

WordPress blog/landing (do 50 URL): 3–8 tys. zł za pełną optymalizację LCP+INP+CLS do statusu „good” (8–20 godzin senior developera + narzędzia). WordPress e-commerce 200–2000 produktów: 15–40 tys. zł. Custom aplikacja Next.js/React z 100k+ URL: 50–150 tys. zł. Shopify Plus / Magento Enterprise: 40–80 tys. zł. ROI zwykle 3–8 miesięcy z racji wzrostu konwersji.

Czy CWV będzie bardziej ważny w 2027 roku?

Google zasygnalizował w 2024, że page experience signals będą stopniowo wzmacniane – każda iteracja CWV (FID→INP, możliwy kolejny krok 2026–2027) podnosi wymagania. Nowe metryki eksperymentalne: Responsiveness (szersza kategoria), Smoothness (animacje). Kierunek jest jasny: strony wolne i niestabilne tracą ranking. Inwestycja w infrastrukturę wydajności ma rosnącą wartość.

Czy dark mode albo inne skórki wpływają na CWV?

Pośrednio, tak. Dark mode z prefers-color-scheme wymaga dodatkowych styli CSS – jeśli nie są dobrze zoptymalizowane, mogą dodawać 20–50ms LCP. Toggle light/dark przez JavaScript z localStorage powoduje krótki flash – technika „FART” (Flash of Incorrect Theme) – rozwiązanie: inline script w head przed CSS. CLS ryzyko minimalne, jeśli layout się nie zmienia między trybami.

Co dalej

Na początek sprawdź przewodniku Core Web Vitals 2026. Gdy opanujesz podstawy, przejdź do checklisty optymalizacji WordPress pod CWV — tam czekają zaawansowane techniki.