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.