Core Web Vitals w 2026 roku przestały być tematem wyłącznie dla programistów. Google zmienił sposób, w jaki ocenia wydajność witryn: interakcyjność (INP) ma dziś taką samą wagę rankingową jak czas ładowania, a ocena przeniosła się z poziomu pojedynczego adresu URL na poziom całej domeny. Oznacza to, że kilkanaście zaniedbanych podstron potrafi ciągnąć w dół pozycje całego serwisu. W tym artykule znajdziesz aktualne progi metryk, dane o tym ile realnie kosztuje wolna strona, konkretny plan naprawczy w siedmiu krokach oraz odpowiedź na pytanie, ile trwa i ile kosztuje optymalizacja wydajności.

Core Web Vitals 2026 – co dokładnie się zmieniło

Core Web Vitals to zestaw trzech metryk, którymi Google opisuje jakość doświadczenia użytkownika na Twojej stronie. Nie są to liczby z symulacji. Google zbiera je od realnych osób, które odwiedziły Twoją witrynę w przeglądarce Chrome, i publikuje w zbiorze Chrome UX Report (CrUX). To dlatego wynik z PageSpeed Insights potrafi wyglądać zupełnie inaczej niż to, co pokazuje Search Console.

W 2026 roku zaszły trzy zmiany, które mają realne konsekwencje dla firm.

1. INP zrównał się wagą z LCP i CLS

INP (Interaction to Next Paint) zastąpiło metrykę FID w marcu 2024 roku. Przez pierwsze miesiące traktowano je jako metrykę drugiej kategorii – ważną, ale mniej istotną niż czas ładowania. W 2026 roku ten stan się skończył. INP jest dziś pełnoprawnym sygnałem obok LCP i CLS.

Różnica jest fundamentalna. LCP mierzy, jak szybko użytkownik zobaczy główną treść. INP mierzy, jak szybko strona odpowie, gdy w coś kliknie. Klasyczne strony firmowe na WordPressie z kilkunastoma wtyczkami zwykle nie mają problemu z pokazaniem treści. Mają problem z tym, że po kliknięciu w menu, filtr lub przycisk „wyślij” nic się nie dzieje przez pół sekundy, bo główny wątek przeglądarki jest zablokowany skryptami.

2. Ocena przeszła z poziomu URL na poziom domeny

To zmiana, którą najłatwiej przeoczyć, a która najmocniej boli. Wcześniej można było zoptymalizować stronę główną i najważniejsze podstrony ofertowe, zostawiając archiwum bloga i stare landingi w spokoju. Dziś Google agreguje wyniki wydajności w skali całego origin. Jeśli znacząca część adresów w domenie ląduje w koszykach „Poor” lub „Needs Improvement”, pociąga to w dół ocenę także tych podstron, które same w sobie przechodzą progi.

Praktyczny wniosek dla właściciela firmy: nie da się już zoptymalizować wyłącznie strony głównej i uznać tematu za zamknięty. Optymalizacja musi objąć szablony, z których generowane są wszystkie typy podstron – wpisy blogowe, karty produktów, strony kategorii, landing page kampanijne.

3. Google testuje kolejną metrykę stabilności wizualnej

W branży sporo mówi się o rozszerzeniu pomiaru stabilności wizualnej poza samo ładowanie strony – tak, aby obejmował przeskoki układu również podczas przewijania i całej sesji użytkownika. CLS w obecnej formie mierzy głównie to, co dzieje się przy wejściu na stronę. Nie ma jeszcze potwierdzenia, że taka rozszerzona metryka stanie się czynnikiem rankingowym, więc nie warto budować wokół niej strategii. Warto natomiast już teraz nie dokładać do strony elementów, które przesuwają treść w trakcie scrollowania: lazy-loadowanych banerów bez zarezerwowanej wysokości, wyskakujących pasków cookies czy widgetów czatu wstrzykiwanych z opóźnieniem.

Trzy metryki i progi, które musisz znać

Progi Google nie zmieniły się od lat i nadal obowiązują w tej samej postaci. Zmieniło się to, jak trudno je osiągnąć na realnym ruchu mobilnym.

Metryka	Co mierzy	Dobry wynik	Wymaga poprawy	Słaby
LCP	Czas do wyświetlenia największego elementu treści	do 2,5 s	2,5-4,0 s	powyżej 4,0 s
INP	Opóźnienie reakcji na kliknięcie lub dotknięcie	do 200 ms	200-500 ms	powyżej 500 ms
CLS	Skumulowane przesunięcia układu strony	do 0,1	0,1-0,25	powyżej 0,25

Kluczowa jest metodologia. Google nie patrzy na średnią, tylko na 75. percentyl. Oznacza to, że próg musi spełnić trzy czwarte Twoich użytkowników. Jeśli 70% odwiedzających ma świetne wyniki, a 30% korzysta ze starszych telefonów na słabym zasięgu, wynik w Search Console będzie odzwierciedlał doświadczenie tej gorszej grupy. To bardzo częsty powód rozjazdu między „u mnie działa szybko” a raportem Google.

Ile realnie kosztuje Cię wolna strona

Argument „Google Cię ukarze” jest najsłabszym powodem, żeby zająć się wydajnością. Core Web Vitals to jeden z wielu sygnałów rankingowych i nie przebije lepszej treści ani mocniejszego profilu linków. Prawdziwy argument leży gdzie indziej: wolna strona nie tyle psuje pozycje, co marnuje ruch, który już masz.

Dane rynkowe są tu wyjątkowo zgodne:

Według wspólnego raportu Google i Deloitte poprawa czasu ładowania o zaledwie 0,1 sekundy podnosiła konwersję w handlu detalicznym o 8,4%.
W eksperymencie Vodafone poprawa LCP o 31% przełożyła się na 8% wzrostu sprzedaży online, 15% więcej wartościowych leadów i 11% więcej wizyt w koszyku. Koszt prac zwrócił się w ciągu sześciu tygodni.
Powtarzalna reguła z wielu badań e-commerce mówi o mniej więcej 1% spadku konwersji na każde dodatkowe 100 ms opóźnienia.
Wśród sklepów internetowych wszystkie trzy progi Core Web Vitals przechodzi około 39% witryn. Reszta zostawia pieniądze na stole.

Przełóż to na własne liczby. Jeśli Twoja strona generuje 40 zapytań ofertowych miesięcznie, a średnia wartość zlecenia wynosi 6 000 zł, to 8% więcej konwersji oznacza ponad 19 000 zł dodatkowego przychodu rocznie. Przy budżecie optymalizacji rzędu kilku tysięcy złotych rachunek zamyka się w pierwszym kwartale. To ta sama logika, która stoi za budżetem na kampanie płatne – tyle że tutaj płacisz raz, a efekt działa na cały ruch, również ten organiczny.

Jest jeszcze drugi, świeższy powód. W 2026 roku coraz większa część zapytań kończy się bez kliknięcia, bo odpowiedź pojawia się w podsumowaniu AI. Ruch, który mimo wszystko trafia na Twoją stronę, jest więc cenniejszy niż rok temu – każda utracona sesja boli bardziej. Więcej o tej zmianie i o tym, jak się do niej dostosować, opisaliśmy we wpisie GEO w praktyce – jak pojawić się w odpowiedziach AI.

Dlaczego INP jest dziś największym problemem

W statystykach zbiorczych INP wygląda przyzwoicie – osobno próg przechodzi zdecydowana większość domen. Problem w tym, że rozkład jest bardzo nierówny. Proste strony wizytówkowe przechodzą INP bez wysiłku i zawyżają średnią. Serwisy, na których faktycznie coś się dzieje – sklepy, konfiguratory, strony z filtrowaniem, portale z kalkulatorami – wypadają dużo gorzej.

Typowe przyczyny słabego INP na stronach firmowych w Polsce:

Nadmiar wtyczek WordPress. Każda ładuje własny JavaScript na każdej podstronie, nawet tam, gdzie nie jest używana. Piętnaście wtyczek to często ponad 1 MB skryptów blokujących główny wątek.
Menedżery tagów bez higieny. Google Tag Manager z kilkunastoma tagami odpalanymi na All Pages, w tym pikselami, mapami ciepła i narzędziami do nagrywania sesji.
Widgety czatu i banery zgód. Wstrzykiwane synchronicznie, potrafią same z siebie dodać 200-400 ms opóźnienia do pierwszej interakcji.
Ciężkie buildery stron. Wizualne kreatory generują rozdmuchany DOM. Im więcej węzłów, tym droższe każde przeliczenie układu po kliknięciu.
Animacje na właściwościach wymuszających reflow. Animowanie width, height, top czy left zamiast transform i opacity oznacza przeliczanie układu w każdej klatce.

Dobra wiadomość jest taka, że INP zwykle naprawia się szybciej niż LCP. Nie wymaga przebudowy hostingu ani migracji obrazów – wymaga dyscypliny w tym, co i kiedy ładujesz.

Plan naprawczy w siedmiu krokach

Poniższa kolejność nie jest przypadkowa. Zaczyna się od działań o najwyższym stosunku efektu do nakładu, kończy na tych, które wymagają pracy programisty.

Zmierz stan wyjściowy na danych polowych. Otwórz raport Core Web Vitals w Google Search Console i zanotuj liczbę adresów w każdym koszyku, osobno dla mobile i desktop. To Twój punkt odniesienia. PageSpeed Insights użyj dopiero w drugim kroku, do diagnozy przyczyn.
Zrób audyt wtyczek i skryptów zewnętrznych. Wypisz wszystko, co ładuje się na stronie. Przy każdej pozycji odpowiedz na pytanie: czy to generuje przychód lub jest wymagane prawem. Jeśli nie – usuń. To zwykle najtańszy sposób na kilkaset milisekund.
Napraw obrazy. Format WebP lub AVIF, wymiary dopasowane do rzeczywistego kontenera, atrybuty width i height w kodzie, lazy loading dla wszystkiego poniżej pierwszego ekranu i wyłącznie dla tego. Obraz w sekcji hero nigdy nie powinien być lazy-loadowany, bo to on zwykle decyduje o LCP.
Zarezerwuj miejsce dla elementów dynamicznych. Baner cookies, widget czatu, reklamy, osadzone filmy – każdy z nich musi mieć zdefiniowaną wysokość w CSS, zanim się załaduje. To jednorazowa robota, która zwykle zamyka temat CLS.
Odroczy i podziel JavaScript. Skrypty analityczne i marketingowe ładuj z atrybutem defer albo po pierwszej interakcji użytkownika. Kod potrzebny tylko na jednej podstronie ładuj wyłącznie tam. Duże biblioteki dziel na mniejsze paczki.
Popraw czas odpowiedzi serwera. TTFB powyżej 600 ms sprawia, że dobrego LCP nie osiągniesz żadną optymalizacją frontendu. Cache po stronie serwera, sensowny hosting, CDN dla zasobów statycznych. W przypadku sklepów – osobno przemyślany cache dla stron kategorii.
Ustal budżet wydajnościowy i pilnuj go. Zapisz w dokumentacji projektu maksymalny rozmiar strony w kilobajtach i limit skryptów zewnętrznych. Bez tego za rok wrócisz do punktu wyjścia, bo ktoś doda kolejny piksel i kolejną wtyczkę.

Technologia strony a wydajność – co ma znaczenie, a co nie

Powtarzający się mit brzmi: „WordPress jest wolny, trzeba przejść na Next.js”. To uproszczenie, które kosztuje firmy niepotrzebne budżety. Dobrze zbudowany WordPress z lekkim motywem, kilkoma wtyczkami i porządnym cache przechodzi Core Web Vitals bez problemu. Źle zbudowany Next.js z pięcioma bibliotekami animacji i nieoptymalizowanymi obrazami polegnie tak samo.

Technologia zaczyna mieć znaczenie dopiero przy określonej skali i określonym typie interfejsu. Jeśli budujesz stronę z rozbudowanym filtrowaniem, konfiguratorem produktu albo panelem klienta, architektura frontendowa faktycznie przekłada się na INP. Jeśli budujesz stronę firmową z ofertą, realizacjami i blogiem – decyduje jakość wykonania, nie wybór stacku. Rozpisaliśmy to szczegółowo we wpisie WordPress czy Next.js – którą technologię wybrać dla strony firmowej.

W praktyce trzy czynniki mają większy wpływ na wynik niż nazwa frameworka: liczba i waga skryptów zewnętrznych, jakość obsługi obrazów oraz konfiguracja cache i hostingu. Każdy z nich da się poprawić bez migracji.

Ile trwa i ile kosztuje optymalizacja Core Web Vitals

Zakres zależy od stanu wyjściowego, ale w praktyce projekty układają się w trzy scenariusze.

Zakres	Co obejmuje	Czas	Orientacyjny budżet
Audyt i szybkie poprawki	Diagnoza, czyszczenie wtyczek i tagów, obrazy, rezerwacja miejsca dla elementów dynamicznych	3-5 dni roboczych	1 500 – 3 500 zł netto
Pełna optymalizacja wydajności	Powyższe plus podział i odroczenie JS, konfiguracja cache, poprawa TTFB, refaktoryzacja krytycznego CSS	2-4 tygodnie	4 000 – 12 000 zł netto
Przebudowa frontendu	Nowy, lekki motyw lub migracja na architekturę headless dla serwisów z rozbudowaną interakcją	6-12 tygodni	od 15 000 zł netto

Dwie uwagi praktyczne. Po pierwsze, nie zamawiaj przebudowy, zanim nie sprawdzisz, ile da sam audyt i szybkie poprawki – w większości stron firmowych to wystarcza, żeby wyjść z czerwonego zakresu. Po drugie, rozliczaj wykonawcę na danych polowych z Search Console po 28 dniach, a nie na wyniku z PageSpeed Insights zrobionym w dniu odbioru. Wynik 100/100 w laboratorium przy słabym wyniku w CrUX oznacza, że optymalizowano pod narzędzie, a nie pod użytkownika.

Core Web Vitals a lokalne SEO – dlaczego to się łączy

Firmy z Częstochowy, Katowic czy Gliwic, które walczą o widoczność na frazy lokalne, mają zwykle konkurencję o zbliżonej sile treści i profilu linków. W takim układzie sygnały jakości strony stają się realnym różnicowaniem. Przy dwóch podobnie zoptymalizowanych serwisach szybsza strona wygrywa dwukrotnie: w rankingu i w konwersji.

Dochodzi jeszcze specyfika ruchu lokalnego. Zapytania typu „hydraulik Częstochowa” czy „gabinet stomatologiczny Katowice” są w przytłaczającej większości mobilne i często wykonywane w ruchu, na słabszym łączu. To dokładnie ten segment użytkowników, który decyduje o Twoim 75. percentylu. Jeśli optymalizujesz stronę patrząc na wynik desktopowy, mierzysz nie to, co trzeba.

Praktyczna kolejność dla firmy lokalnej: najpierw uporządkowana wizytówka Google i spójne dane NAP, potem treść odpowiadająca na lokalne intencje, a równolegle wydajność strony docelowej. Rozbiliśmy ten proces na etapy we wpisie Local SEO dla małych firm – 10 kroków do lokalnej widoczności w Google.

FAQ – najczęstsze pytania o Core Web Vitals

Czy Core Web Vitals naprawdę wpływają na pozycje w Google?

Tak, ale jako jeden z wielu sygnałów, nie jako czynnik decydujący. Google konsekwentnie komunikuje, że trafność i jakość treści są ważniejsze. Wydajność działa jako czynnik rozstrzygający między stronami o zbliżonej jakości merytorycznej – a w większości branż lokalnych właśnie w takiej sytuacji jesteś. Niezależnie od rankingu, szybsza strona konwertuje lepiej, i to jest silniejszy argument biznesowy.

Mam 95 punktów w PageSpeed Insights, a Search Console pokazuje problem. Dlaczego?

Bo to dwa różne pomiary. Wynik punktowy w PageSpeed Insights pochodzi z symulacji Lighthouse na modelowym urządzeniu i łączu. Search Console pokazuje dane polowe zebrane od Twoich realnych użytkowników z ostatnich 28 dni, na 75. percentylu. Jeśli sporo Twojego ruchu to starsze telefony na słabym zasięgu, wynik polowy będzie gorszy niż laboratoryjny. Zawsze podejmuj decyzje na podstawie danych polowych.

Jak szybko zobaczę efekt po wdrożeniu poprawek?

W PageSpeed Insights natychmiast, w danych laboratoryjnych. W Search Console po około 28 dniach, bo tyle wynosi okno agregacji CrUX. Pełna stabilizacja raportu zajmuje zwykle 4-8 tygodni od wdrożenia. To normalne i nie oznacza, że poprawki nie zadziałały – trzeba po prostu poczekać na wypełnienie okna pomiarowego nowymi danymi.

Czy wtyczka optymalizacyjna do WordPressa wystarczy?

Wtyczki cache i optymalizacji potrafią rozwiązać sporą część problemów z LCP, zwłaszcza w prostych witrynach. Nie rozwiążą jednak problemów z INP, jeśli źródłem opóźnień są skrypty zewnętrzne i rozdmuchany DOM – te trzeba usunąć u źródła, nie zminifikować. Traktuj wtyczkę jako uzupełnienie, nie zamiennik audytu. Agresywna konfiguracja bez testów potrafi też popsuć wygląd strony, więc każdą zmianę weryfikuj na środowisku testowym.

Czy muszę przebudowywać stronę, żeby przejść Core Web Vitals?

W większości przypadków nie. Przebudowa jest uzasadniona, gdy strona opiera się na ciężkim builderze generującym setki zbędnych węzłów DOM, gdy motyw nie był aktualizowany od lat albo gdy serwis ma rozbudowaną warstwę interaktywną, której obecna architektura nie udźwignie. W pozostałych sytuacjach audyt plus optymalizacja wystarczają, żeby wyjść na zielone. Zacznij od diagnozy, a decyzję o przebudowie podejmij dopiero na jej podstawie.

Czy Core Web Vitals mają znaczenie dla widoczności w odpowiedziach AI?

Nie bezpośrednio – systemy generujące odpowiedzi AI cytują źródła głównie na podstawie trafności i wiarygodności treści, a nie czasu ładowania. Pośrednio jednak ma to znaczenie: strona musi być sprawnie indeksowalna i dostępna dla robotów, a wolny, przeciążony skryptami serwis utrudnia crawl. Poza tym ruch z odpowiedzi AI jest mniejszy i bardziej wartościowy, więc tym bardziej nie warto go tracić na wolno ładującej się stronie docelowej.

Jeśli chcesz sprawdzić, w jakim stanie jest Twoja witryna, i dostać konkretną listę priorytetów zamiast ogólników, zajrzyj do naszej oferty SEO i optymalizacji technicznej albo napisz do nas. Zobacz też, jak wygląda to w praktyce w naszych realizacjach.

Informacja. Artykuł ma charakter informacyjny i przedstawia stan wiedzy oraz rynku na sierpień 2026. Przytoczone dane pochodzą z publicznie dostępnych raportów branżowych i analiz zbioru Chrome UX Report – Google może zmieniać progi, metodologię pomiaru i zestaw metryk bez wcześniejszej zapowiedzi. Podane widełki cenowe i czasowe mają charakter orientacyjny i zależą od zakresu projektu, stanu wyjściowego witryny oraz przyjętej technologii.

Core Web Vitals 2026 – jak szybkość strony wpływa na pozycje w Google i sprzedaż