Core Web Vitals 2026: ile realnie ważą dla pozycji

Core Web Vitals wracają w każdej dyskusji o audycie technicznym, zwykle w dwóch skrajnych wersjach. Pierwsza mówi, że bez trzech zielonych wskaźników nie ma sensu walczyć o topowe pozycje. Druga, że to kosmetyka, która nie przekłada się na nic poza ładnym raportem. Obie są nieprawdziwe, a różnica między nimi kosztuje realne godziny pracy deweloperów. Poniżej rozkładamy na części to, co w 2026 roku faktycznie mierzy Google, jak mocno te dane ważą w rankingu i które poprawki mają najlepszy stosunek efektu do nakładu.

Aktualne metryki i progi

Zestaw pozostaje trzyelementowy i mierzy trzy różne rzeczy: szybkość załadowania głównej treści, responsywność interfejsu na działania użytkownika oraz stabilność układu strony. Od czasu, gdy INP zastąpił dawne FID, największe problemy sprawia właśnie druga pozycja, bo obnaża ciężkie skrypty, których wcześniejsza metryka po prostu nie widziała.

Dwie rzeczy w tej tabeli bywają pomijane, a decydują o interpretacji wyników. Po pierwsze, ocena opiera się na 75. percentylu, czyli liczy się doświadczenie trzech czwartych wizyt, a nie średnia. Jedna wolna podstrona nie zepsuje wyniku, ale powtarzalny problem na mobile już tak. Po drugie, dane raportowane przez Google pochodzą z okna kroczącego obejmującego 28 dni. Wdrożenie poprawki dzisiaj nie zmieni raportu jutro, a pełny obraz zobaczysz dopiero po miesiącu. To najczęstsza przyczyna wniosku „poprawiliśmy, a nic się nie stało”. Szczegóły definicji i sposób liczenia progów opisuje dokumentacja web.dev poświęcona Web Vitals.

Realny wpływ na ranking według danych

Google konsekwentnie opisuje sygnały związane z doświadczeniem strony jako element pomocniczy, a nie fundament rankingu. W praktyce oznacza to rolę języczka u wagi: przy dwóch stronach zbliżonych trafnością i autorytetem szybsza może wyjść wyżej, ale żadna wartość LCP nie wypchnie słabej treści przed lepszą. Kolejność priorytetów jest więc odwrotna niż w wielu ofertach agencyjnych, gdzie optymalizacja wydajności bywa sprzedawana jako główny lek na spadki widoczności.

Analizy korelacyjne prowadzone na dużych zbiorach adresów URL od lat pokazują ten sam wzorzec: związek między wynikami Core Web Vitals a pozycją istnieje, lecz jest słaby i mocno zależny od branży. W niszach, gdzie wszyscy publikują treści porównywalnej jakości, różnica bywa zauważalna. W tematach eksperckich, gdzie liczy się głębia materiału i profil linków, wskaźniki techniczne schodzą na dalszy plan. Warto też pamiętać, że wydajność wpływa na rankingi pośrednio, przez budżet indeksowania i sprawność robota, o czym piszemy szerzej w tekście o tym, jak działa Google od crawlowania po AI Overviews.

Wniosek operacyjny jest prosty. Jeżeli strona ma wyniki w kategorii „słaby”, poprawa jest inwestycją z wysokim priorytetem, bo usuwa realną barierę. Jeżeli mieści się już w progach „dobrych”, przesuwanie LCP z 2,1 s na 1,8 s rzadko zwraca się w postaci pozycji i lepiej przeznaczyć ten budżet na treść lub linkowanie.

Wpływ na konwersję, czyli drugi argument

Nawet gdyby wpływ na ranking był zerowy, biznesowe uzasadnienie zostaje. Tu dane są znacznie mocniejsze niż w przypadku pozycji, ponieważ pochodzą z testów A/B, a nie z korelacji. Głośne badanie Google i Deloitte „Milliseconds Make Millions” wykazało, że skrócenie czasu ładowania o zaledwie 0,1 s podnosiło współczynnik konwersji w handlu detalicznym o kilka procent, przy jednoczesnym wzroście średniej wartości koszyka. Podobne wnioski powtarzają się w publikacjach dużych serwisów medialnych i e-commerce.

Stabilność układu ma jeszcze bardziej bezpośrednie przełożenie. Przesuwający się przycisk to nie tylko liczba w raporcie, to kliknięcie w reklamę zamiast w „dodaj do koszyka” i porzucona sesja. Dlatego w argumentacji przed zarządem czy klientem CLS i INP sprzedają się lepiej niż LCP: łatwiej pokazać stratę, którą generują.

Pomiar: dane polowe kontra laboratoryjne

Rozróżnienie tych dwóch źródeł to warunek sensownej pracy. Dane polowe pochodzą od rzeczywistych użytkowników Chrome i to one trafiają do oceny w Search Console. Dane laboratoryjne to symulacja w kontrolowanym środowisku, na przykład wynik Lighthouse w PageSpeed Insights. Symulacja jest powtarzalna i świetnie nadaje się do debugowania, ale nie odzwierciedla realnego ruchu.

Kluczowa pułapka dotyczy INP. Metryka wymaga faktycznych interakcji, więc test laboratoryjny jej nie zmierzy i podstawia w zamian wskaźnik zastępczy, zwykle Total Blocking Time. Zdarza się więc, że narzędzie pokazuje komplet zielonych ocen, podczas gdy dane polowe raportują poważny problem z responsywnością. Sensowny proces wygląda tak: raport Core Web Vitals w Search Console wskazuje grupy adresów do naprawy, PageSpeed Insights diagnozuje pojedynczy szablon, a crawler zbiera obraz całego serwisu. Do tego ostatniego zadania przydaje się konfiguracja opisana w naszym poradniku o audycie w Screaming Frog, którą łatwo rozszerzyć o integrację z PageSpeed API.

Mierz zawsze na poziomie szablonu, nie pojedynczego URL. Jeżeli karta produktu ma problem z LCP, ma go zwykle sto tysięcy kart produktu, a jedna poprawka w motywie zamyka cały temat.

Poprawki o największym zwrocie

Przy ograniczonym budżecie kolejność wdrożeń ma większe znaczenie niż ich liczba. Poniższa lista jest uszeregowana według stosunku efektu do nakładu pracy, na podstawie typowych wdrożeń na stronach opartych o CMS.

1. Czas odpowiedzi serwera i cache strony. Wysokie TTFB podnosi każdą pozostałą metrykę. Pełne cache stron plus sensowny hosting daje zwykle największy pojedynczy skok wyniku LCP przy minimalnej ingerencji w kod.
2. Obraz LCP. Element odpowiedzialny za LCP nie może być ładowany leniwie. Ustaw dla niego wysoki priorytet pobierania, podaj nowoczesny format (WebP lub AVIF) i realne wymiary zamiast skalowanej w przeglądarce grafiki o szerokości 3000 pikseli.
3. Skrypty firm trzecich. Czaty, testy A/B, heatmapy i piksele reklamowe to najczęstsze źródło złego INP. Odrocz je do momentu pierwszej interakcji albo usuń te, których nikt nie analizuje.
4. Fonty. Hostuj lokalnie, ogranicz liczbę krojów i wag, ustaw wyświetlanie zastępcze w czasie ładowania. To tania poprawka, która jednocześnie obniża CLS i skraca renderowanie tekstu.
5. Rezerwacja miejsca. Jawne wymiary obrazów, osadzeń wideo i slotów reklamowych likwidują większość przesunięć układu. Banery zgody i paski powiadomień powinny mieć zarezerwowaną przestrzeń, a nie wpychać treść w dół.

Najczęstsze błędy na WordPressie

Na WordPressie problemy powtarzają się w zaskakująco stałym zestawie. Numerem jeden jest globalne leniwe ładowanie obejmujące grafikę nagłówkową, przez co strona sama opóźnia własny LCP. Numerem dwa: kolekcja wtyczek optymalizacyjnych działających równolegle, gdzie dwie wersje minifikacji potrafią wzajemnie się znosić i psuć układ. Numer trzy to slider na pierwszym ekranie, który ładuje kilka ciężkich obrazów naraz i niemal zawsze przegrywa z prostą, statyczną sekcją.

Dochodzi do tego agresywne odraczanie JavaScriptu, włączane hurtem w panelu wtyczki. Bywa skuteczne, ale potrafi rozłożyć koszyk albo formularz, więc każdą zmianę tego typu trzeba testować na kluczowych ścieżkach, nie tylko na stronie głównej. Warto na koniec zaznaczyć jedno rozgraniczenie, bo powraca w audytach jako fałszywa diagnoza: wolna strona rzadko jest powodem, dla którego treść nie trafia do wyników. Jeżeli podstrony w ogóle nie pojawiają się w Google, przyczyny są zwykle inne i opisaliśmy je w materiale o tym, dlaczego strona nie jest indeksowana. Wydajność poprawia jakość obsługi już zindeksowanych adresów, nie zastępuje naprawy indeksacji.

FAQ