INP (ang. Interaction to Next Paint) to wskaźnik Core Web Vitals, który mierzy, jak szybko strona odpowiada wizualnie na interakcje użytkownika — kliknięcia, dotknięcia i naciśnięcia klawiszy — w trakcie całej wizyty. Wynik do 200 ms Google uznaje za dobry, a powyżej 500 ms za słaby. Od marca 2024 roku INP zastąpił wskaźnik FID w zestawie Core Web Vitals, dlatego dla marketera i specjalisty SEO jest to jeden z trzech sygnałów jakości strony (obok LCP i CLS), które Google raportuje w Search Console i uwzględnia w ocenie doświadczenia użytkownika.
Jak działa INP?
INP nie mierzy tylko pierwszej interakcji, jak robił to FID. Przeglądarka rejestruje opóźnienie każdej interakcji na stronie i na koniec wizyty raportuje jedną z najgorszych wartości (dla stron z bardzo wieloma interakcjami pomijane są pojedyncze skrajne odchylenia). Na poziomie całej witryny Google patrzy na 75. percentyl odwiedzin — czyli wynik, który osiąga co najmniej 75% użytkowników.
Każda interakcja składa się z trzech faz, które sumują się do wartości INP:
| Faza | Co obejmuje | Typowa przyczyna opóźnień |
|---|---|---|
| Opóźnienie wejścia (input delay) | Czas od interakcji do rozpoczęcia obsługi zdarzenia | Zajęty główny wątek, długie zadania JavaScript, skrypty stron trzecich |
| Czas przetwarzania (processing time) | Wykonanie kodu obsługującego zdarzenie | Ciężka logika w handlerach, synchroniczne wywołania, brak podziału pracy |
| Opóźnienie prezentacji (presentation delay) | Czas do wyrenderowania kolejnej klatki | Duże zmiany DOM, kosztowne style, wymuszone przeliczanie układu |
Do INP wliczają się kliknięcia myszą, dotknięcia na ekranach dotykowych i naciśnięcia klawiszy. Nie są mierzone najechanie kursorem (hover) ani przewijanie strony.
Jak zmierzyć INP?
INP jest wskaźnikiem polowym, czyli opiera się na danych od prawdziwych użytkowników. Do jego kontroli służą:
- Google Search Console — raport Core Web Vitals grupuje adresy URL według statusu „dobry”, „wymaga poprawy” i „słaby”.
- PageSpeed Insights — pokazuje dane z Chrome UX Report (CrUX) dla konkretnego adresu lub całej domeny.
- Chrome DevTools — panel Performance pozwala odtworzyć interakcję i zobaczyć, która z trzech faz generuje opóźnienie.
- Biblioteka web-vitals — umożliwia wysyłanie wyników INP do własnej analityki, np. do GA4.
Szczegółowy opis metodologii znajduje się w dokumentacji Google na web.dev.
Jakie progi obowiązują w 2026 roku?
- Dobry: 200 ms lub mniej — strona reaguje na tyle szybko, że użytkownik odczuwa ją jako natychmiastową.
- Wymaga poprawy: od 200 do 500 ms — opóźnienie jest zauważalne, zwłaszcza na słabszych urządzeniach mobilnych.
- Słaby: powyżej 500 ms — użytkownicy często klikają ponownie, co pogłębia problem i podnosi współczynnik porzuceń.
Najczęstsze błędy obniżające INP
- Ładowanie ciężkich skryptów tagów marketingowych, chatów i map bez odroczenia (defer) lub ładowania na żądanie.
- Długie zadania JavaScript blokujące główny wątek — każde zadanie powyżej 50 ms opóźnia obsługę interakcji.
- Kosztowne operacje w obsłudze zdarzeń, np. przeliczanie całego koszyka po każdym kliknięciu w filtr produktów.
- Brak natychmiastowej informacji zwrotnej — nawet jeśli operacja trwa dłużej, przeglądarka powinna najpierw pokazać zmianę stanu (np. podświetlenie przycisku), a resztę wykonać asynchronicznie.
- Optymalizowanie wyłącznie pod testy laboratoryjne, podczas gdy INP zależy od realnych urządzeń i rzeczywistych sesji.
INP w praktyce ICBM
W pracy nad wydajnością traktujemy INP jako wskaźnik „drugiego wrażenia”: LCP odpowiada za to, jak szybko strona się pokaże, a INP — czy będzie się nią dało wygodnie posługiwać. Najczęściej w sklepach internetowych źródłem problemu są filtry, konfiguratory produktów i skrypty stron trzecich, które konkurują o główny wątek z interfejsem. W ramach audytu strony identyfikujemy konkretne interakcje generujące opóźnienia, rozdzielamy je na trzy fazy i wskazujemy, które zmiany dadzą największy efekt w danych CrUX. Więcej pojęć z tego obszaru znajdziesz w kategorii SEO w bazie wiedzy.
Najczęściej zadawane pytania
Czym INP różni się od FID?
FID mierzył wyłącznie opóźnienie pierwszej interakcji i tylko fazę oczekiwania na obsługę zdarzenia. INP obejmuje wszystkie interakcje w trakcie wizyty i pełny czas do wyrenderowania kolejnej klatki, dlatego lepiej odzwierciedla rzeczywistą responsywność strony. Od marca 2024 roku FID nie jest już częścią Core Web Vitals.
Czy INP wpływa na pozycje w Google?
INP jest jednym z sygnałów Core Web Vitals, które Google wykorzystuje w ocenie doświadczenia strony. Nie jest to czynnik dominujący — treść i linki pozostają ważniejsze — ale słabe wyniki mogą przeważyć przy porównywalnych stronach. Ważniejszy bywa efekt biznesowy: wolna reakcja interfejsu przekłada się na niższą konwersję.
Dlaczego INP w Lighthouse wygląda inaczej niż w Search Console?
Lighthouse to test laboratoryjny wykonywany na jednym urządzeniu bez realnych interakcji, więc INP może w nim nie występować lub być tylko przybliżony. Search Console i PageSpeed Insights korzystają z danych CrUX od prawdziwych użytkowników Chrome, w tym na słabszych telefonach. Do oceny statusu Core Web Vitals liczą się wyłącznie dane polowe.
