W marcu 2026 Google obniżył próg „dobry” dla LCP z 2,5 do 2,0 sekundy. Jeśli twoja strona ładowała się w 2,3 sekundy i cieszyłeś się zieloną ikoną w Search Console – teraz masz pomarańczową. To nie koniec zmian: INP awansowało do rangi równorzędnego sygnału rankingowego, a 43% serwisów nadal tego progu nie spełnia. Liczby są konkretne; działania też muszą być.
Core Web Vitals (CWV) to trzy metryki, którymi Google mierzy rzeczywiste doświadczenie użytkownika: szybkość ładowania (LCP), reaktywność na interakcje (INP) i stabilność wizualna (CLS). Weszły do algorytmu rankingowego w 2021 roku; jednak marcowy core update 2026 podniósł poprzeczkę wyraźniej niż jakikolwiek wcześniejszy krok. Strony z LCP powyżej 2,5 sekundy traciły na konkurencyjnych frazach od 2 do 4 pozycji – niezależnie od jakości treści czy profilu linków.
Co tak naprawdę mierzą te trzy liczby?
Core Web Vitals nie mierzą prędkości serwera ani czystości kodu. Mierzą odczuwalną jakość korzystania ze strony – to różnica, którą warto rozumieć zanim sięgniesz po jakiekolwiek narzędzia optymalizacyjne.
LCP: próg 2,0 s to nowe minimum
Largest Contentful Paint rejestruje moment, w którym największy widoczny element w oknie przeglądarki – najczęściej hero image, nagłówek H1 lub baner – w pełni się wyrenderował. Po marcowym core update 2026 obowiązuje nowa skala: poniżej 2,0 sekundy to wynik „dobry”; 2,0-4,0 s to „wymaga poprawy”; powyżej 4 sekund – wynik zły. Zaledwie 62% stron mobilnych osiągało dobry LCP przy starym progu 2,5 s (dane Web Almanac 2025); przy nowym progu ta liczba będzie niższa.
Dwaj główni winowajcy to nieskompresowane obrazy w nagłówku oraz skrypty blokujące renderowanie. Jeśli twój hero image waży 1,8 MB w formacie PNG, a CDN jest zlokalizowany wyłącznie w USA – wiesz, gdzie zacząć. Format WebP przy porównywalnej jakości daje plik 2-3 razy lżejszy; AVIF idzie jeszcze dalej, choć wsparcie przeglądarek bywa nierówne.
INP: równorzędny sygnał rankingowy od marca 2026
Interaction to Next Paint zastąpiło First Input Delay w marcu 2024, ale dopiero potwierdzenie Google z 18 marca 2026 (post na Search Central Blog) nadało mu pełny status sygnału rankingowego na równi z LCP i CLS. Różnica wobec starego FID jest zasadnicza: FID mierzył opóźnienie tylko pierwszej interakcji; INP analizuje każde kliknięcie, tapnięcie i wpisanie znaku podczas całej wizyty, a jako wynik bierze percentyl 98. Próg „dobry” to poniżej 200 ms; powyżej 500 ms to wynik słaby.
43% stron wciąż nie spełnia progu 200 ms – to najniższy wskaźnik zdawalności spośród wszystkich trzech metryk w 2026 roku. Serwisy z INP powyżej 200 ms w strefie „wymaga poprawy” traciły w marcu 2026 średnio 0,8 pozycji na konkurencyjnych frazach. Niewiele? Przy słowach kluczowych z dużym ruchem ta różnica potrafi kosztować tysiące wizyt miesięcznie.
CLS: stabilny próg, niestabilna rzeczywistość
Cumulative Layout Shift mierzy nieoczekiwane przesunięcia elementów podczas ładowania strony. Wynik 0,1 lub niższy to dobry próg – ten się nie zmienił. Powyżej 0,25 to katastrofa dla użytkownika, który właśnie kliknął przycisk, a ten nagle przeskoczył 150 pikseli w dół, bo załadowała się reklama displayowa. CLS ma najwyższy wskaźnik zdawalności spośród trzech metryk; problem wraca przy serwisach z reklamą dynamiczną i fontami webowymi bez zdefiniowanego font-display. Nota: CLS jest wciąż domeną Chromium – Safari nie mierzy tej metryki natywnie; propozycja Interop 2026 obejmuje jej ustandaryzowanie.
Dlaczego sam Lighthouse nie wystarcza – i co mierzyć zamiast niego
Wynik 94/100 w Lighthouse, a w Search Console większość URL-i oznaczonych „wymaga poprawy”. Brzmi absurdalnie? To sytuacja, w której wylądowałem przy audycie jednego z serwisów e-commerce dwa lata temu. Wyjaśnienie jest proste.
Lighthouse działa w warunkach laboratoryjnych: emulowany wolny telefon, czyste połączenie, zero plików cookie, zero rozszerzeń. Google nie używa tych danych do rankingów. Algorytm rankingowy opiera się na Chrome User Experience Report (CrUX) – zbiorczych, zanonimizowanych danych od prawdziwych użytkowników Chrome zebranych przez ostatnie 28 dni. Różnica między laboratorium a rzeczywistością bywa dramatyczna.
W tamtym projekcie winowajcą był widget live chatu ładowany asynchronicznie – niewidoczny dla testu laboratoryjnego, bo inicjalizował się po załadowaniu strony. Dla użytkownika z telefonem z 2022 roku blokował main thread przez 420 ms przy każdej interakcji. Efekt: INP wynosił 380 ms w CrUX mimo 94 punktów w Lighthouse.
Ważna rzecz do zapamiętania: LCP i INP uzyskały status „Baseline Newly Available” w grudniu 2025 (Safari 26.2 dołączyło do Chrome i Edge w ramach Interop 2025), więc biblioteka web-vitals.js mierzy je teraz we wszystkich głównych przeglądarkach. Jednak CrUX nadal zbiera dane wyłącznie z Chrome – dane Safari i Firefox do niego nie trafiają. Dla serwisów z dużą bazą użytkowników Apple warto wdrożyć własne Real User Monitoring niezależnie od Google Search Console.
Trzy narzędzia, które warto mieć otwarte równocześnie:
- Google Search Console (raport Core Web Vitals): Grupuje URL-e w segmenty i pokazuje, gdzie masz problem na skali całego serwisu. Dobry punkt startowy; widać tu to, co Google faktycznie widzi.
- PageSpeed Insights: Łączy dane laboratoryjne z CrUX dla konkretnego URL. Niezbędne do diagnozowania pojedynczych podstron – zwłaszcza po zmianie progu LCP, gdy strony przeskoczyły ze „zielonej” do „pomarańczowej” strefy.
- Chrome DevTools (zakładka Performance): Tu szukasz konkretnych long tasks blokujących INP; pokazuje call stack z dokładnością do milisekund i nie da się go oszukać.
Trzy zmiany, które dają wyniki szybciej niż 90% innych optymalizacji
Tysiąc porad o wydajności można znaleźć na web.dev i Stack Overflow. W praktyce – z własnego doświadczenia przy kilkudziesięciu serwisach – 80% poprawy LCP pochodzi zwykle z tych samych trzech źródeł. I żadne nie wymaga przepisania architektury.
Pierwsze: fetchpriority="high" na obrazie LCP. Jeden atrybut HTML. Może skrócić LCP o 300-800 ms, jeśli twój hero image nie był dotąd traktowany priorytetowo przez parser przeglądarki. Piszesz <img fetchpriority="high" src="hero.webp">. Tyle. Przy nowym progu 2,0 s ta oszczędność bywa różnicą między zieloną a pomarańczową ikoną w Search Console.
Drugie: font-display: swap w CSS dla fontów webowych. Bez tego deklaracja fontu blokuje renderowanie tekstu do czasu pobrania pliku .woff2 – przeglądarka wyświetla pustą przestrzeń lub zerowy LCP, aż font dotrze z serwera. Proste ustawienie; niedoceniane nagminnie.
Trzecie: audyt skryptów trzecich. Piksel Facebooka, Google Tag Manager z dwunastoma tagami, widget live chat, Hotjar i dwa inne narzędzia analityczne – każde z nich wykonuje JavaScript na main thread. Na jednym projekcie e-commerce usunięcie dwóch nieużywanych pikseli i opóźnienie wczytywania chata poprawiło INP z 380 ms do 160 ms. Zero zmian w kodzie produktu; zero dodatkowego budżetu deweloperskiego.
Efekty wdrożenia widać w Search Console po 4-6 tygodniach – tyle zajmuje zebranie nowego okna 28-dniowych danych CrUX i aktualizacja raportu.
Core Web Vitals kontra treść – co ma większy wpływ na ranking?
| Scenariusz | Wyniki CWV | Jakość treści | Typowy efekt |
|---|---|---|---|
| Mocna treść, wolna strona | Słabe (LCP >2,5 s) | Wysoka (E-E-A-T) | Straty 2-4 pozycji na konkurencyjnych frazach; traci do konkurencji łączącej treść z szybką stroną |
| Szybka strona, słaba treść | Dobre (zielone) | Niska (generyczna) | Bez efektu rankingowego; szybkość nie zastępuje merytoryki |
| Dobra treść i dobra szybkość | Dobre | Wysoka | Maksymalna widoczność; efekt mnożnikowy obu czynników; strony na pozycji 1 mają o 10% wyższy pass rate CWV niż te na pozycji 9 |
| Słaba treść i wolna strona | Słabe | Niska | Poważny problem rankingowy; ciężko naprawić szybko – każdy aspekt wymaga osobnej pracy |
Odpowiedź na to popularne pytanie brzmi: nie da się ich rozdzielić. Google traktuje CWV jako kryterium kwalifikujące, nie wyróżniające. Dobra szybkość nie winduje cię na szczyt – zła ściąga z niego. Różnicę robią treść, backlinki i E-E-A-T… ale tylko wtedy, gdy użytkownik dotrwa do ich przeczytania.
Dane są jednoznaczne: strony ładujące się poniżej 2 sekund mają 9% współczynnik odrzuceń; strony ładujące się powyżej 5 sekund – 38%. Każda sekunda opóźnienia powyżej progu LCP zwiększa bounce rate o 32%. Nawet najlepiej napisany artykuł nie pomoże, jeśli użytkownik go nie zobaczy.
Co się zmieniło w marcu 2026 – i jakie są praktyczne konsekwencje
Marcowy core update 2026 przyniósł dwie konkretne zmiany w Core Web Vitals – nie teorie, nie zapowiedzi. Fakty.
Pierwsza: Google obniżył próg „dobry” dla LCP z 2,5 sekundy do 2,0 sekundy. Strony z LCP w przedziale 2,0-2,5 s automatycznie przesunęły się do strefy „wymaga poprawy”. Według analizy DebugBear z marca 2026 serwisy z LCP powyżej 2,5 s traciły od 2 do 4 pozycji na zapytaniach komercyjnych. To nie jest drobna korekta – to zmiana wymagająca przeglądu infrastruktury obrazów i zasobów krytycznych na wielu stronach.
Druga zmiana: INP uzyskało potwierdzenie statusu równorzędnego sygnału rankingowego (post Google Search Central, 18 marca 2026). Wcześniej Google traktowało INP jako pełnoprawną metrykę CWV, ale w komunikatach zewnętrznych LCP dominował jako najważniejszy czynnik. Teraz wszystkie trzy metryki są oficjalnie równoważne. Serwisy z INP powyżej 200 ms odnotowały średni spadek o 0,8 pozycji – mało widowiskowy, ale skumulowany efekt przy kilkudziesięciu frazach jest zauważalny.
Jeden niuans, który warto znać: zmiany w twoich stronach odbijają się w rankingach z opóźnieniem 4-6 tygodni (tyle trwa zebranie nowego 28-dniowego okna CrUX). Nie panikuj więc, jeśli wdrożyłeś optymalizacje tydzień temu i jeszcze nie widzisz efektów w Search Console.
Najczęściej zadawane pytania
Jaki jest aktualny próg „dobry” dla LCP w 2026?
Po marcowym core update 2026 dobry LCP to poniżej 2,0 sekundy. Przedział 2,0-4,0 s to „wymaga poprawy”; powyżej 4,0 s – wynik słaby. To obniżenie o 0,5 s wobec poprzedniego progu 2,5 s oznacza, że serwisy, które jeszcze niedawno miały zielony status, teraz mogą znajdować się w strefie pomarańczowej bez żadnych zmian po swojej stronie.
Czy Core Web Vitals bezpośrednio wpływają na pozycje w Google?
Tak, jako kryterium kwalifikujące i – od marca 2026 – coraz silniejszy tiebreaker. Strony osiągające pozycję 1 mają o 10% wyższy wskaźnik zdanych Core Web Vitals niż strony na pozycji 9 przy porównywalnej jakości treści. Nie zastępują E-E-A-T ani profilu linków; jednak przy równorzędnych treściach wyniki CWV coraz wyraźniej decydują o kolejności wyników.
Dlaczego Lighthouse daje zielone wyniki, a Search Console czerwone?
Lighthouse emuluje konkretne urządzenie i łącze w warunkach laboratoryjnych – ignoruje pliki cookie, skrypty personalizacji, reklamy dla zalogowanego użytkownika i rozszerzenia przeglądarki. Search Console pokazuje dane CrUX od prawdziwych odwiedzających Chrome z ostatnich 28 dni. Widget live chatu, reklamy displayowe i skrypty A/B testów mogą dramatycznie obniżać field data bez śladu w teście laboratoryjnym.
Jak szybko można poprawić LCP po zmianie progu do 2,0 s?
Najszybsza zmiana to dodanie atrybutu fetchpriority="high" do obrazu LCP – jeden atrybut HTML, potencjalna oszczędność 300-800 ms bez żadnych zmian po stronie serwera. Kolejny krok to konwersja hero image do WebP lub AVIF (plik 2-3 razy lżejszy od PNG). Głębsza optymalizacja przez europejski CDN i eliminację render-blocking resources zajmuje tygodnie, ale daje trwałe efekty nie do osiągnięcia przez same „sztuczki front-endowe”.
Czym INP różni się od starego FID?
First Input Delay mierzył opóźnienie wyłącznie pierwszej interakcji użytkownika na stronie. INP analizuje każde kliknięcie, tapnięcie i wpisanie znaku przez całą sesję; jako wynik bierze percentyl 98, czyli niemal najgorzej obsłużoną interakcję. INP poniżej 200 ms to dobry wynik; powyżej 500 ms – słaby. Oficjalna zamiana nastąpiła w marcu 2024; status pełnoprawnego sygnału rankingowego INP uzyskało w marcu 2026.
Co powoduje wysoki CLS i jak go naprawić?
Typowe przyczyny to obrazy bez atrybutów width i height, reklamy wstrzykiwane dynamicznie bez zarezerwowanego kontenera oraz fonty webowe bez font-display: swap. Naprawa jest zwykle prosta: dodaj wymiary do obrazów i iFrame’ów, zarezerwuj przestrzeń dla reklam, ustaw font-display w arkuszu CSS. CLS poniżej 0,1 jest osiągalne dla niemal każdego serwisu bez przepisywania architektury. Uwaga: ustaw alert monitoringowy przy CLS powyżej 0,08 – to 80% progu Google, bufor przed wpadnięciem w „wymaga poprawy”.
Czy Core Web Vitals mają znaczenie dla stron z małym ruchem?
Jeśli serwis nie zbiera wystarczających danych CrUX (za mało użytkowników Chrome), raport w Search Console pozostaje pusty i Google nie ocenia CWV dla tych stron. Nie oznacza to jednak, że można zignorować wydajność – wskaźniki zachowania użytkowników (bounce rate, czas na stronie) wpływają na ocenę jakości pośrednio, a zła wydajność przekłada się na gorsze konwersje niezależnie od SEO.
Jak Core Web Vitals działają na stronach WordPress?
WordPress ma specyficzne wyzwania: pagebuilder’y generują ciężki DOM, wtyczki dokładają dziesiątki żądań HTTP, a motywy ładują fonty z zewnętrznych CDN bez optymalizacji. Podstawowe działania to: wtyczka do minifikacji JS/CSS (np. Autoptimize), konwersja obrazów do WebP przez Smush lub ShortPixel, włączenie lazy loading (wbudowane od WordPressa 5.5) i audyt aktywnych wtyczek w Chrome DevTools przed każdą decyzją o instalacji nowej. Przy nowym progu LCP 2,0 s opcjonalne CDN staje się praktycznie obowiązkowe dla serwisów z ruchem europejskim.
Co wdrożyć w tym tygodniu – i jakie są priorytety po zmianie progów
Szybkie wygrane niezmienne od lat: fetchpriority="high" na hero image, font-display: swap w CSS, wymiary na wszystkich obrazach i iFrame’ach. Trzy zmiany; żadna nie wymaga przepisania architektury. Razem potrafią przesunąć stronę ze strefy „wymaga poprawy” do „dobry” – ale przy nowym progu LCP 2,0 s margines błędu jest mniejszy niż rok temu.
Nowe priorytety po marcu 2026: ustaw alerty monitoringowe przy 80% progów Google (INP > 160 ms, LCP > 2,0 s, CLS > 0,08); rejestrujesz regresję zanim wpłynie na 28-dniowe okno CrUX. Wdróż bibliotekę web-vitals.js jeśli masz dużo użytkowników Safari – CrUX ich nie obejmuje, a twoje field data są wtedy niekompletne.
Jedno zastrzeżenie, które warto zapamiętać: zielone CWV to dziś konieczność, nie przewaga konkurencyjna. Naprawdę różnicuje treść – ekspercka, oparta na własnych danych i doświadczeniu, napisana dla konkretnego czytelnika. Szybkość to bilet wstępu. Bez niego nie wchodzisz do gry; z nim – musisz jeszcze wygrać grę osobno.
Źródła i dalsze informacje
- Google Search Central. „Understanding Core Web Vitals and Google Search Results.” developers.google.com
- web.dev Blog. „LCP and INP are now Baseline Newly Available” (grudzień 2025). web.dev
- DebugBear. „Core Web Vitals 2026: Impact of March Update on Rankings.” (marzec 2026). debugbear.com
