Core Web Vitals: jak poprawić LCP, INP i CLS (poradnik z narzędziami)

Najważniejsze wnioski z tego poradnika

Poniższe punkty to esencja artykułu — jeśli masz 5 minut, przeczytaj przynajmniej tę sekcję.

• Od marca 2024 Google zastąpił metrykę FID nową — INP (Interaction to Next Paint), która mierzy responsywność wszystkich interakcji użytkownika, nie tylko pierwszej. Większość sklepów wciąż nie zareagowała. A powinna.
• Trzy progi do zapamiętania: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Przekroczenie któregokolwiek obniża ocenę całej strony.
• Google ocenia stronę na podstawie danych polowych (field data) z Chrome User Experience Report (CrUX), a nie wyników laboratoryjnych Lighthouse. Wynik 95/100 w Lighthouse nie gwarantuje zdania Core Web Vitals — widzimy to niemal przy każdym audycie.
• Strony, które zdają wszystkie trzy metryki, notują średnio o 24% niższy współczynnik odrzuceń i wyraźnie lepsze pozycje organiczne.
• LCP to najczęstszy problem w sklepach internetowych — główne przyczyny to nieskompresowane obrazy hero, brak preloadingu i wolny TTFB serwera.
• CLS naprawisz najszybciej: wystarczy dodać atrybuty width i height do każdego obrazu, iframe i slotu reklamowego.
• INP wymaga najgłębszych zmian — rozbijania długich zadań JavaScript, odraczania skryptów third-party i redukcji złożoności DOM.
• Jedno narzędzie nie wystarczy. Optymalny workflow to: Google Search Console (identyfikacja problemów) → PageSpeed Insights (diagnostyka) → Chrome DevTools (debugowanie) → monitoring RUM (walidacja w polu).

Czym są Core Web Vitals i dlaczego wpływają na ranking

Core Web Vitals to zestaw trzech metryk Google mierzących rzeczywiste doświadczenie użytkownika na stronie: szybkość ładowania (LCP), responsywność (INP) i stabilność wizualną (CLS). Google włączył je do sygnałów rankingowych w czerwcu 2021 i od tego czasu ich wpływ na pozycje rośnie — szczególnie w konkurencyjnych niszach e-commerce, gdzie dziesiątki sklepów walczą o te same frazy.

Każda metryka odpowiada na inne pytanie z perspektywy osoby odwiedzającej stronę. LCP: czy główna treść załadowała się szybko? INP: czy strona reaguje na moje kliknięcia? CLS: czy układ strony nie skacze mi przed oczami? Google ocenia je na poziomie 75. percentyla danych z przeglądarek Chrome (CrUX — Chrome User Experience Report). Co to oznacza w praktyce? Twoja strona musi działać dobrze dla zdecydowanej większości odwiedzających — nie tylko tych z szybkim łączem i nowym MacBookiem. A biorąc pod uwagę, że Polacy spędzają online średnio 3 godziny 44 minuty dziennie, z czego 76% na mobile (Gemius / PBI, 2025) — te metryki naprawdę muszą się zgadzać na telefonie.

Trzy progi, które musisz zapamiętać:

Ile stron faktycznie te progi spełnia? Niezbyt wiele. Według danych HTTP Archive z 2025 roku tylko ok. 48% wizyt mobilnych zdaje wszystkie trzy metryki jednocześnie (HTTP Archive, 2025). Ponad połowa stron w internecie nie spełnia minimalnych wymagań Google. Jeśli Twój sklep jest po zielonej stronie — masz przewagę, której większość sprzedawców nawet nie widzi.

Bo treść strony pozostaje najważniejszym czynnikiem rankingowym. Ale gdy kilka sklepów oferuje porównywalną jakość contentu — a w e-commerce tak właśnie jest, karty produktowe mają podobną strukturę — Core Web Vitals stają się czynnikiem rozstrzygającym. Następna sekcja pokaże, od której metryki zacząć.

LCP — Largest Contentful Paint: co mierzy i jak go poprawić

LCP (Largest Contentful Paint) mierzy czas, po którym największy widoczny element strony — obraz hero, baner, nagłówek lub blok tekstu — pojawia się na ekranie użytkownika. Dobry wynik to poniżej 2,5 sekundy, a w praktyce e-commerce celuj w 1,8 s lub mniej.

Dlaczego akurat LCP jest koszmarem sklepów internetowych? Strony kategorii i karty produktowe pękają w szwach od dużych zdjęć, sliderów, dynamicznie ładowanych bannerów i skryptów third-party — chat, piksel Meta, Google Analytics. Każdy z tych elementów potencjalnie blokuje lub opóźnia renderowanie największego contentu. A 53% użytkowników mobilnych opuszcza stronę, jeśli ładuje się dłużej niż 3 sekundy (Google). Trzy sekundy. Tyle masz czasu, zanim klient zniknie.

Najczęstsze przyczyny słabego LCP w e-commerce

Słaby LCP w sklepach wynika z czterech źródeł: wolnego serwera (wysoki TTFB), niezoptymalizowanych obrazów, blokujących renderowanie zasobów CSS/JS i opóźnionego ładowania kluczowych zasobów.

1. Wysoki TTFB (Time to First Byte). Jeśli serwer odpowiada po 800 ms, LCP nie ma szans zejść poniżej progu. Hosting współdzielony za 30 zł/mies. często nie wystarcza dla sklepów z dużym katalogiem. Sprawdź TTFB w PageSpeed Insights — jeśli przekracza 600 ms, to sygnał do zmiany hostingu lub wdrożenia CDN. Koniec dyskusji.
2. Obrazy bez kompresji i nowoczesnych formatów. Zdjęcia produktowe w JPG o wadze 500 KB+ to zabójca LCP. Konwersja do WebP lub AVIF redukuje rozmiar o 30–50% bez widocznej utraty jakości. Widzimy to u każdego klienta — nikt nie optymalizuje zdjęć przed wrzuceniem do CMS-a.
3. Render-blocking CSS i JavaScript. Każdy plik CSS i JS wstawiony w <head> bez atrybutu async lub defer blokuje renderowanie strony. Typowy sklep na WooCommerce z 15 wtyczkami? Spokojnie dodaje 1,5 sekundy do LCP. Tylko dlatego, że ktoś zainstalował wtyczkę do animacji, z której korzysta jeden slider.
4. Brak preloadingu elementu LCP. Jeśli obrazem LCP jest baner hero, przeglądarka musi najpierw pobrać HTML, potem CSS, a dopiero potem odkrywa, że potrzebuje tego obrazu. Tag <link rel="preload"> informuje przeglądarkę o tym zasobie z wyprzedzeniem — i skraca łańcuch zależności.

Krok po kroku: jak obniżyć LCP poniżej 2,5 sekundy

Optymalizacja LCP wymaga działań na czterech poziomach: serwerze, zasobach, CSS i preloadingu. Poniższy plan pozwala obniżyć LCP nawet o 50–60% w ciągu kilku dni roboczych.

1. Zmierz aktualny LCP na mobile w PageSpeed Insights — sprawdź zarówno dane polowe (Field Data), jak i wynik Lighthouse.
2. Zidentyfikuj element LCP — PageSpeed Insights wskaże go w sekcji „Largest Contentful Paint element”. Najczęściej to obraz hero lub pierwszy <h1>.
3. Jeśli element LCP to obraz: przekonwertuj na WebP/AVIF, dodaj <link rel="preload" as="image"> w sekcji <head>, ustaw fetchpriority="high", usuń loading="lazy" z tego konkretnego obrazu.
4. Inline’uj krytyczny CSS (powyżej linii zgięcia) i odrocz resztę arkuszy stylów. Narzędzie criticalCSS automatyzuje ten proces.
5. Odrocz nieistotny JavaScript: tagi analityczne, chat, piksele remarketingowe — przenieś je z <head> do <body> z atrybutem defer lub ładuj je po zdarzeniu DOMContentLoaded.
6. Sprawdź TTFB. Przekracza 600 ms? CDN (Cloudflare, Bunny.net), cache’owanie na serwerze (Redis, Varnish, LiteSpeed Cache) lub migracja hostingu. Nie ma trzeciej opcji.
7. Ponownie zmierz LCP. Dane polowe w CrUX odświeżą się po 28 dniach, ale wynik laboratoryjny zobaczysz natychmiast.

INP — co zastąpiło FID i dlaczego sklepy go nie zdają

INP (Interaction to Next Paint) zastąpił FID w marcu 2024 jako oficjalną metrykę responsywności w Core Web Vitals. O ile FID mierzył opóźnienie tylko pierwszej interakcji, INP ocenia wszystkie interakcje użytkownika na stronie i raportuje najgorszy wynik na 75. percentylu. Efekt? Zdecydowanie trudniejsza metryka do zdania.

Jak trudna? Dane z CrUX pokazują, że ok. 43% stron nie zdaje progu 200 ms dla INP — to najczęściej oblewany wskaźnik Core Web Vitals. CLS oblewa znacznie mniej stron, bo jego naprawa jest prostsza. INP to inna liga.

I tu pojawia się problem specyficzny dla e-commerce. Sklepy mają mnóstwo interakcji: filtry produktów, dodawanie do koszyka, otwieranie wariantów, quick view, rozwijane menu. Każda z tych akcji uruchamia JavaScript, a jeśli wątek główny przeglądarki jest zajęty przetwarzaniem innego skryptu — użytkownik czeka. I czeka. I odchodzi. Bo wzrost czasu ładowania z 1 do 3 sekund podnosi bounce rate o 32%, a przy 6 sekundach — o 106% (Google / Think with Google). Te liczby nie kłamią.

Jak poprawić INP: rozbijanie zadań i odraczanie skryptów

Poprawa INP wymaga trzech działań: rozbicia długich zadań JavaScript na mniejsze fragmenty (poniżej 50 ms), odroczenia skryptów third-party i redukcji złożoności DOM strony.

1. Zidentyfikuj najwolniejszą interakcję. W Chrome DevTools → zakładka Performance → nagraj sesję z interakcjami (klikanie filtrów, dodawanie do koszyka). Szukaj „Long Tasks” — bloków trwających ponad 50 ms.
2. Rozbij długie zadania (Long Tasks). Użyj scheduler.yield() lub setTimeout do podzielenia ciężkich operacji na mniejsze kawałki. Dzięki temu przeglądarka może odpowiedzieć na interakcję między fragmentami kodu.
3. Odrocz skrypty third-party. Piksele Meta, tagi Google Ads, czat na żywo, widgety social media — to wszystko blokuje wątek główny. Ładuj je z opóźnieniem (np. po requestIdleCallback) lub przez Partytown (przenosi skrypty do web workera).
4. Zmniejsz DOM. Strony z ponad 1500 elementami DOM mają wyraźnie gorszy INP. Paginuj długie listy produktów, leniwie ładuj sekcje poniżej widoku — opinie, powiązane produkty, bloki „ostatnio oglądane”.
5. Unikaj dużych re-renderów. Jeśli kliknięcie filtra produktów przebudowuje całą listę — zoptymalizuj logikę frontendu, żeby aktualizować tylko zmienione elementy. Brzmi banalnie, a robi ogromną różnicę.

CLS — stabilność wizualna, którą naprawisz najszybciej

CLS (Cumulative Layout Shift) mierzy, ile razy układ strony przesunął się niespodziewanie podczas ładowania. Dobry wynik to poniżej 0,1. Ze wszystkich trzech metryk Core Web Vitals, CLS jest najłatwiejszy do naprawienia — bo jego przyczyny są mechaniczne, a nie architektoniczne.

A przesunięcie layoutu to jeden z najbardziej irytujących błędów UX, jakie istnieją. Użytkownik chce kliknąć „Dodaj do koszyka”, ale w ostatniej chwili załadował się baner reklamowy i zamiast tego trafia w link do regulaminu. W e-commerce to bezpośrednia utrata konwersji. Yahoo! JAPAN po naprawieniu CLS odnotował 15,1% więcej odsłon na sesję i 1,72% niższy bounce rate. Naprawa jednej metryki — konkretny wynik.

Typowe błędy CLS w sklepach na Shoper, WooCommerce i PrestaShop

Główne źródła CLS w polskich sklepach internetowych to: obrazy bez wymiarów, dynamicznie wstrzykiwane bannery, fonty bez font-display: swap i sloty reklamowe bez zarezerwowanej przestrzeni.

• Obrazy bez atrybutów width i height. Najczęstsza przyczyna — i najłatwiejsza do usunięcia. Gdy przeglądarka nie zna wymiarów obrazu, rezerwuje 0 pikseli, a po załadowaniu grafiki układ się przesuwa. Rozwiązanie: każdy <img> musi mieć jawne wymiary (lub aspect-ratio w CSS). Proste? Tak. A mimo to 44% stron WordPress na mobile wciąż nie zdaje Core Web Vitals (HTTP Archive, lipiec 2025).
• Fonty ładowane bez font-display: swap. Gdy Google Fonts ładuje się z opóźnieniem, tekst renderowany systemowym fontem nagle zmienia się na docelowy i zmienia wymiary. Dodaj font-display: swap w deklaracji @font-face i preloaduj pliki fontów.
• Dynamicznie wstrzykiwane bannery i widgety. Pop-up z zapisem na newsletter, pasek cookie consent, bannery promocyjne wstrzykiwane przez JavaScript — jeśli nie mają zarezerwowanej przestrzeni w layoutcie, powodują przesunięcia. I nie, użytkownik nie jest „przyzwyczajony”. On jest wściekły.
• Iframe i embeddy bez wymiarów. Wideo z YouTube, mapy Google, widgety czatu — bez jawnych wymiarów w atrybutach lub CSS powodują CLS. Łatwe do naprawienia, łatwe do przeoczenia.

Narzędzia do mierzenia Core Web Vitals — porównanie

Żadne pojedyncze narzędzie nie wystarczy do pełnej diagnostyki Core Web Vitals. Optymalne podejście łączy dane polowe (CrUX/GSC) do identyfikacji problemów z danymi laboratoryjnymi (Lighthouse/DevTools) do ich debugowania.

Jak to wygląda w codziennej pracy? Otwierasz Google Search Console → raport Core Web Vitals → mobile. Widzisz grupy URL oznaczone jako „Poor” lub „Needs Improvement”. Klikasz w grupę — GSC wskazuje przykładowe URL. Ten URL wklejasz do PageSpeed Insights i analizujesz diagnostykę. Potrzebujesz głębszego debugowania? Otwierasz stronę w Chrome DevTools, nagrywasz sesję w zakładce Performance. Identyfikacja problemu (dane polowe) + precyzyjna diagnostyka (dane laboratoryjne) — nie da się tego zrobić jednym narzędziem.

„Consistency is the biggest technical SEO factor.”

(pol. Spójność to najważniejszy czynnik technicznego SEO.)

Mueller ma rację — i ta zasada dotyczy też monitoringu Core Web Vitals. Jednorazowy audyt nic nie da, jeśli po miesiącu ktoś wrzuci nową wtyczkę i LCP wróci do czerwonego statusu. Spójność oznacza ciągłe sprawdzanie.

Dane polowe vs laboratoryjne — co naprawdę liczy Google

Google do oceny Core Web Vitals w rankingu używa wyłącznie danych polowych (field data) z Chrome User Experience Report, a nie wyników testów Lighthouse. To fundamentalna różnica — i największe źródło złudzeń wśród właścicieli sklepów.

Dane laboratoryjne (lab data) to symulowane testy. Lighthouse otwiera stronę na wirtualnym urządzeniu, w kontrolowanych warunkach sieciowych, i mierzy metryki. Wynik jest mniej więcej powtarzalny, ale nie odzwierciedla rzeczywistości. Twoi klienci wchodzą na sklep z różnych urządzeń, z różnymi prędkościami internetu, w różnych lokalizacjach. Lighthouse tego nie widzi.

Dane polowe (field data) to anonimowe dane od prawdziwych użytkowników Chrome, którzy odwiedzili Twoją stronę. Google zbiera je w 28-dniowym oknie kroczącym i raportuje w CrUX. To te dane wpływają na ranking. Jeśli Lighthouse pokazuje LCP 1,8 s, a CrUX 3,5 s — Google widzi 3,5 s. I nic z tym nie zrobisz, poza faktycznym przyspieszeniem strony.

Strony z niskim ruchem (nowe sklepy, niszowe produkty, staging) mogą nie mieć wystarczająco dużo danych w CrUX. W takim wypadku Google może użyć danych agregowanych na poziomie domeny (origin) zamiast poszczególnych URL. Dla nowych stron dane laboratoryjne to jedyne źródło do debugowania — ale nie łudź się, że wynik Lighthouse 95/100 oznacza sukces. Po zdobyciu ruchu prawdziwe liczby mogą wyglądać zupełnie inaczej. Widzimy to regularnie.

Po wdrożeniu poprawek dane polowe w GSC odświeżą się w ciągu ok. 28 dni. Efekt naprawy CLS we wtorkowy wieczór zobaczysz w raporcie dopiero za miesiąc. Dlatego monitoruj równolegle wyniki w Lighthouse — zmiany widzisz od razu, choćby orientacyjnie.

Core Web Vitals a pozycjonowanie sklepów — realne wpływy

Core Web Vitals nie zastąpią dobrego contentu i silnego profilu linków, ale w konkurencyjnych kategoriach e-commerce — gdzie dziesiątki sklepów oferują te same produkty — mogą być czynnikiem decydującym o pozycji w top 10.

Skrócenie ładowania strony o zaledwie 0,1 sekundy przekłada się na wzrost konwersji o 8% i wzrost wydatków klienta o 10% (Deloitte / Google). A organik to nadal największy kanał ruchu w polskim e-commerce — odpowiada za 44,56% wizyt, daleko przed płatnymi kampaniami, które generują zaledwie 7,7% (Harbingers + Openfield, 2025). Każda stracona pozycja w organiku to realna strata przychodów.

„Good SEO is really having good content for people.”

(pol. Dobre SEO to po prostu dobre treści dla ludzi.)

Sullivan ma rację — treść jest fundamentem. Ale w praktyce e-commerce wygląda to tak: masz dwa sklepy z podobnymi kartami produktowymi, zbliżonymi linkami i porównywalnym autorytetem. Ten, który zdaje Core Web Vitals, wygrywa. W branżach jak elektronika, moda czy kosmetyki — gdzie konkurencja jest brutalna — ułamki sekundy mają realne przełożenie na ruch i przychód.

„W projektach, które prowadziliśmy dla sklepów na Shoper i WooCommerce, poprawa Core Web Vitals z czerwonego do zielonego statusu przynosiła wzrost ruchu organicznego rzędu 15–30% w ciągu dwóch miesięcy. Nie dlatego, że CWV to magiczny przełącznik — ale dlatego, że szybsza strona = niższy bounce = lepsze sygnały behawioralne = wyższe pozycje. To efekt kaskadowy.”

— Tomasz Węsierski, założyciel Westom, ekspert SEO i e-commerce

Każde 100 ms opóźnienia w ładowaniu strony obniża konwersję o 7%. To nie jest teoria — to dane, które bezpośrednio przekładają się na przychód Twojego sklepu. Optymalizacja Core Web Vitals to nie koszt. To inwestycja z szybkim zwrotem.

Jeśli prowadzisz pozycjonowanie strony i nie monitorujesz Core Web Vitals — pracujesz z jedną ręką za plecami. Dobry content bez szybkiej strony to jak świetna oferta w sklepie, do którego nikt nie może wejść, bo drzwi się zacięły.

Plan działania: od audytu do zielonego raportu w GSC

Poniższy plan prowadzi od pierwszego pomiaru do pełnego zdania Core Web Vitals w Google Search Console. Działaj etapami — nie próbuj naprawiać wszystkiego naraz. Zacznij od metryki, która oblewa najwięcej URL.

1. Etap 1: Pomiar bazowy (1 dzień). Otwórz Google Search Console → Core Web Vitals → Mobile. Zanotuj, ile URL jest w statusie Poor, Needs Improvement i Good. Sprawdź, która metryka dominuje w problemach.
2. Etap 2: Diagnostyka top 5 stron (2 dni). Wybierz 5 najważniejszych stron (strona główna, top kategorie, bestsellery). Przetestuj je w PageSpeed Insights — osobno mobile i desktop. Zapisz: element LCP, wynik INP (jeśli są dane polowe), źródła CLS.
3. Etap 3: Naprawy CLS (1–3 dni). Dodaj width i height do wszystkich obrazów. Zarezerwuj miejsce na bannery i iframe. Dodaj font-display: swap. CLS to metryka, którą naprawisz najszybciej i z najniższym ryzykiem regresji.
4. Etap 4: Naprawy LCP (3–7 dni). Skompresuj i skonwertuj obrazy (WebP/AVIF). Dodaj preload elementu LCP. Inline’uj krytyczny CSS. Odrocz nieistotny JS. TTFB > 600 ms? CDN albo migracja hostingu.
5. Etap 5: Naprawy INP (1–2 tygodnie). Zidentyfikuj Long Tasks w DevTools. Rozbij ciężkie skrypty. Odrocz third-party. Zmniejsz DOM. To najtrudniejszy etap — może wymagać zmian w architekturze frontendu. Nie obchodź tego — jeśli INP jest czerwony, trzeba go rozwiązać u podstaw.
6. Etap 6: Monitoring (28+ dni). Ustaw alerty w narzędziu monitorującym (DebugBear, GSC, lub prosty skrypt z CrUX API). Rekomendowane progi alertów: INP > 160 ms, LCP > 2,0 s, CLS > 0,08 — czyli 80% wartości progowych Google. Dzięki temu zareagujesz, zanim problem trafi do raportu CrUX.
7. Etap 7: Walidacja. Po ~28 dniach sprawdź raport Core Web Vitals w GSC. URL przeszły na „Good”? Sukces. Nie przeszły? Wróć do PageSpeed Insights i powtórz diagnostykę na problematycznych grupach. Bez frustracji — to iteracyjny proces.

Optymalizacja Core Web Vitals to nie jednorazowa akcja — to element ciągłego procesu technicznego SEO. Każda aktualizacja sklepu, nowa wtyczka, zmiana szablonu lub dodanie skryptu reklamowego może spowodować regresję. Monitoring jest tak samo ważny jak sama naprawa. Bo strona, której nikt nie sprawdza, prędzej czy później zwolni — to tylko kwestia czasu. Jeśli szukasz kompleksowego podejścia do wydajności i tworzenia stron internetowych, które zdają Core Web Vitals od startu — to inwestycja, która zwraca się w lepszych pozycjach i wyższych konwersjach.