Core Web Vitals w 2026 roku to wciąż trzy wskaźniki, ale środek ciężkości przesunął się na jeden z nich. INP (Interaction to Next Paint) zastąpił FID 12 marca 2024 roku i od tego momentu Google mierzy responsywność całej sesji, a nie tylko reakcji na pierwsze kliknięcie. To zmiana, która wywróciła wyniki serwisów z pozoru szybkich.
Warto od razu ustawić oczekiwania: core web vitals inp 2026 to problem o dużej wadze dla użytkownika i małej dla samego rankingu. Poniżej rozdzielamy jedno od drugiego na mechanizmach.
W skrócie
- Progi „dobry” dla 75. percentyla: INP do 200 ms, LCP do 2,5 s, CLS do 0,1.
- INP mierzy opóźnienie każdej interakcji w sesji (kliknięcia, dotknięcia, klawiatura), a raportowana jest praktycznie najgorsza z nich.
- Dane rankingowe pochodzą z pola (CrUX, okno 28 dni), nie z Lighthouse. Laboratoryjnym przybliżeniem INP jest TBT.
- Najczęstsza przyczyna złego INP w polskich serwisach to połączenie banera zgód, menedżera tagów i hydratacji frameworka w jednym momencie.
- Poprawa Core Web Vitals rzadko sama podnosi pozycje. Realny zysk to konwersja, zasięg crawlowania i rozstrzyganie remisów w konkurencyjnych SERP-ach.
INP, LCP i CLS: co się zmieniło
Zmieniła się definicja responsywności, nie liczba wskaźników. FID liczył wyłącznie opóźnienie wejścia przy pierwszej interakcji, więc strona mogła mieć świetny wynik i zacinać się przy każdym kolejnym kliknięciu. INP obejmuje pełny cykl: opóźnienie wejścia, czas obsługi zdarzenia oraz czas do następnego wyrenderowania klatki.
| Wskaźnik | Dobry | Wymaga poprawy | Słaby | Co mierzy |
|---|---|---|---|---|
| INP | do 200 ms | 200–500 ms | powyżej 500 ms | responsywność interakcji w całej sesji |
| LCP | do 2,5 s | 2,5–4,0 s | powyżej 4,0 s | czas pojawienia się głównego elementu treści |
| CLS | do 0,1 | 0,1–0,25 | powyżej 0,25 | stabilność układu po wczytaniu |
Praktyczna konsekwencja: INP jest wskaźnikiem „najsłabszego ogniwa”. Jedna ciężka interakcja na stronie produktowej, na przykład rozwinięcie wariantów albo otwarcie filtra, wystarczy, aby cały URL wylądował w koszyku „wymaga poprawy”.
Dane polowe kontra laboratoryjne
Do oceny w Search Console liczą się tylko dane polowe. Google czerpie je z raportu CrUX, czyli z anonimowych pomiarów od użytkowników Chrome, w oknie kroczącym 28 dni i na 75. percentylu. Oznacza to dwie rzeczy: po wdrożeniu poprawki wynik aktualizuje się tygodniami, a wynik opisuje najgorsze doświadczenie jednego z czterech użytkowników, nie średnią.
Lighthouse i PageSpeed Insights w sekcji laboratoryjnej nie raportują INP, bo nie mają skąd wziąć interakcji. Zamiast tego podają TBT (Total Blocking Time), który jest przybliżeniem: wysoki TBT prawie zawsze oznacza wysoki INP w polu, ale niski TBT nie gwarantuje niczego, bo ciężkie nasłuchy mogą siedzieć w elementach, których test nigdy nie kliknie.
- CrUX / Search Console: źródło prawdy dla oceny Google, opóźnione o 28 dni, grupuje URL-e we wzorce.
- RUM własny (biblioteka web-vitals w przeglądarce): ten sam pomiar, ale natychmiastowy i z podziałem na szablony oraz na konkretne elementy.
- Lighthouse / DevTools: tylko diagnostyka. Panel Performance pokazuje, która funkcja blokuje wątek główny.
Bez własnego RUM praca nad INP to zgadywanie. Minimalny zestaw to skrypt web-vitals wysyłający atrybucję (nazwa elementu, typ zdarzenia, szablon) do własnego zbioru danych. Dopiero wtedy wiadomo, że problemem jest przycisk dodania do koszyka, a nie „JavaScript”.
Najczęstsze przyczyny wysokiego INP
INP psuje się praktycznie zawsze na wątku głównym. Lista poniżej pokrywa większość przypadków z audytów serwisów contentowych i sklepów:
- Długie zadania powyżej 50 ms: pojedyncza funkcja obsługi zdarzenia, która liczy, sortuje albo przebudowuje DOM bez oddania kontroli przeglądarce.
- Hydratacja frameworka: React, Vue czy Angular przejmują statyczny HTML w tym samym momencie, w którym użytkownik zaczyna klikać. Kliknięcie czeka w kolejce.
- Duży DOM: kilka tysięcy węzłów powoduje, że każda zmiana klasy wymusza kosztowne przeliczenie układu i stylów.
- Synchroniczne operacje w obsłudze zdarzenia: zapis do localStorage, czytanie offsetWidth w pętli, parsowanie dużego JSON-a.
Dwa pierwsze punkty odpowiadają za większość wyników powyżej 500 ms. Lekarstwem nie jest usunięcie kodu, a rozbicie go: przekazanie ciężkiej części do Web Workera, oddanie kontroli przeglądarce po każdym fragmencie oraz natychmiastowa reakcja wizualna, zanim logika się policzy.
Osobny wątek to sposób dostarczania treści. Jeśli serwis renderuje się w pełni po stronie klienta, problemem jest nie tylko INP, lecz także to, co z takiej strony widzą roboty. Rozpisaliśmy to w materiale o tym, jak boty AI radzą sobie z renderowaniem JavaScriptu, bo dla GPTBota i Perplexity konsekwencje są dużo ostrzejsze niż dla Googlebota.
Skrypty firm trzecich i banery zgód
Baner zgód jest najczęstszym pojedynczym sprawcą złego INP w polskich serwisach, bo trafia dokładnie w pierwszą interakcję. Użytkownik wchodzi, klika „Akceptuję”, a to kliknięcie uruchamia kaskadę: zapis zgody, odblokowanie menedżera tagów, wczytanie analityki, pikseli reklamowych, czatu i testów A/B. Cały ten blok wykonuje się na wątku głównym, a pomiar przypisuje opóźnienie do kliknięcia w baner.
Dla tego jednego zdarzenia mówimy o setkach milisekund, czyli dość, by samodzielnie zepsuć 75. percentyl całego szablonu. Trzy poprawki, które zwykle wystarczają:
- Zapis zgody i zamknięcie banera wykonać natychmiast, a wczytywanie tagów odłożyć do następnej klatki lub do bezczynności przeglądarki.
- Ograniczyć liczbę tagów odpalanych na zdarzeniu zgody. Czat, mapy ciepła i narzędzia testowe nie muszą startować w tej samej sekundzie.
- Wczytywać skrypty firm trzecich z atrybutem defer albo przez facade (podmiana widgetu atrapą, która wczytuje prawdziwy skrypt po kliknięciu).
Przy diagnozie warto też sprawdzić, czy skrypty firm trzecich nie obciążają osobno samego crawlowania. Wzorce żądań widać najlepiej w logach serwera, a sposób ich czytania opisujemy w przewodniku po analizie logów pod crawlery AI.
Ile ruchu realnie zyskasz po poprawie
Uczciwa odpowiedź: samo wejście z „wymaga poprawy” na „dobry” rzadko przesuwa pozycje w sposób widoczny w Search Console. Page experience jest sygnałem rozstrzygającym remisy, a nie dźwignią. Jeśli strona jest 14. na zapytanie, przy którym konkurencja ma mocniejszy profil linków i lepsze pokrycie tematu, poprawa INP z 480 ms do 170 ms nie zrobi z niej trójki (szczegóły progów opisuje dokumentacja Google Search Central).
Zyski są realne, ale leżą w innych miejscach:
| Obszar | Mechanizm | Jak zmierzyć |
|---|---|---|
| Konwersja | mniej porzuceń na krokach wymagających kliknięcia (filtry, koszyk, formularz) | test A/B lub porównanie kohort przed i po wdrożeniu |
| Crawlowanie | szybsze odpowiedzi serwera zwiększają liczbę pobrań na dobę | statystyki indeksowania w Search Console, logi |
| Remisy w SERP | rozstrzyganie przy zbliżonej jakości i autorytecie stron | śledzenie pozycji w wąskiej grupie zapytań konkurencyjnych |
Jeśli po wdrożeniu poprawek ruch spada, przyczyny prawie nigdy nie ma w Core Web Vitals. Kolejność diagnozy przy nagłych spadkach rozpisaliśmy osobno w tekście o tym, jak znaleźć przyczynę spadku ruchu po aktualizacji Google.
Priorytetyzacja poprawek przy małym budżecie
Przy ograniczonym budżecie liczy się kolejność, bo pierwsze dwa kroki zwykle dają 80 procent efektu. Sprawdzona sekwencja:
- Zidentyfikuj szablon, nie URL. Search Console grupuje adresy, więc naprawa jednego typu strony obejmie tysiące URL-i.
- Odłóż wszystko, co odpala się na zgodzie. Jedna zmiana w konfiguracji menedżera tagów, zero pracy programistycznej w kodzie aplikacji.
- Rozbij najdłuższe zadanie na wątku głównym. Wystarczy jedno, to z panelu Performance, zwykle funkcja obsługi głównej akcji szablonu.
- Dodaj natychmiastową informację zwrotną. Stan wciśnięcia, szkielet listy, blokada przycisku. INP mierzy czas do następnego wyrenderowania, więc szybka zmiana wizualna poprawia wynik nawet przy tej samej logice.
- Dopiero potem optymalizuj LCP. Obraz bohatera, priorytet pobierania, czas odpowiedzi serwera.
Szerszy kontekst techniczny (rendering, schema, hreflang pod modele językowe) zebraliśmy w przewodniku o SEO technicznym w 2026 roku.
Najczęstsze błędy
- Optymalizacja pod wynik Lighthouse, a nie pod dane polowe. Wynik 100 na laptopie deweloperskim nie mówi nic o telefonie w sieci 4G.
- Ocena po średniej zamiast po 75. percentylu. Średnia ukrywa dokładnie te sesje, które decydują o ocenie.
- Pomiar dzień po wdrożeniu. Okno CrUX to 28 dni, więc pełny efekt widać po czterech tygodniach.
- Traktowanie Core Web Vitals jako strategii SEO. To higiena techniczna, która nie zastępuje pokrycia tematu ani autorytetu domeny.
FAQ
Czym dokładnie różni się INP od FID?
FID mierzył wyłącznie opóźnienie wejścia przy pierwszej interakcji na stronie, czyli czas od kliknięcia do rozpoczęcia obsługi zdarzenia. INP obejmuje wszystkie interakcje w sesji i cały ich cykl: opóźnienie wejścia, czas wykonania funkcji obsługi oraz czas do następnego wyrenderowania klatki. Raportowana jest praktycznie najgorsza interakcja (przy dużej liczbie zdarzeń wysoki percentyl).
Jaki INP jest wystarczająco dobry w 2026 roku?
Progiem „dobry” jest 200 ms na 75. percentylu danych polowych. Zakres 200–500 ms oznacza „wymaga poprawy”, powyżej 500 ms ocena jest słaba. Warto celować poniżej 150 ms, bo wynik na granicy progu oscyluje między kategoriami przy każdej zmianie struktury ruchu.
Czy poprawa Core Web Vitals podniesie moje pozycje?
Rzadko samodzielnie i rzadko w sposób mierzalny. Page experience działa jako czynnik rozstrzygający przy stronach o zbliżonej jakości i autorytecie. Jeśli brakuje treści odpowiadającej na intencję albo linków, poprawa INP tego nie nadrobi. Mierzalny zwrot pojawia się po stronie konwersji i crawlowania, więc tymi wskaźnikami warto rozliczać projekt.
Dlaczego PageSpeed Insights nie pokazuje mojego INP?
Sekcja laboratoryjna nie symuluje interakcji, więc nie ma z czego policzyć INP. Jej zamiennikiem jest TBT. Sekcja z danymi polowymi pokazuje INP tylko wtedy, gdy adres (albo domena) ma w CrUX wystarczającą próbkę ruchu z Chrome. Mniejsze serwisy często widzą wyłącznie dane dla całego źródła, więc rozwiązaniem jest własny pomiar RUM.
Ile czasu mija od wdrożenia poprawki do zmiany oceny?
Dane CrUX działają w oknie kroczącym 28 dni, więc pierwsze drgnięcie widać po kilku dniach, a pełny efekt po około czterech tygodniach. Raport w Search Console dodaje własne opóźnienie przetwarzania, zwykle kilka dni. Przyjmij 4–6 tygodni na potwierdzenie wdrożenia, a w tym czasie mierz własnym RUM.
Czy baner zgód trzeba usunąć, żeby poprawić INP?
Nie. Problemem nie jest samo istnienie banera, a to, że kliknięcie w „Akceptuję” uruchamia synchronicznie całą kaskadę skryptów. Wystarczy rozdzielić dwie rzeczy: zapis zgody i zamknięcie okna wykonać od razu, a wczytywanie tagów przenieść do kolejnej klatki renderowania lub do momentu bezczynności przeglądarki.
Co dalej
Zacznij od własnego pomiaru z atrybucją, bo bez niego nie wiadomo, który element psuje wynik szablonu. Potem odłóż skrypty odpalane na zgodzie i rozbij jedno najdłuższe zadanie, a ocenę weryfikuj po czterech tygodniach, nie po jednym dniu. Jeśli równolegle układasz prace techniczne na kwartał, warto zestawić je z listą kontrolną z przewodnika o SEO technicznym pod modele językowe, żeby poprawki wydajnościowe i te pod indeksację weszły jednym wdrożeniem.