INP (Interaction to Next Paint) – co to jest?

Co to jest INP (Interaction to Next Paint)?

Interaction to Next Paint (INP) to metryka Core Web Vitals, która mierzy responsywność strony internetowej na działania użytkownika. Konkretnie – INP rejestruje czas od momentu interakcji (kliknięcie, dotknięcie ekranu, naciśnięcie klawisza) do chwili, gdy przeglądarka wyświetli wizualną odpowiedź na tę interakcję. Wynik INP to najgorsze opóźnienie spośród wszystkich interakcji w trakcie wizyty użytkownika na stronie (z wyłączeniem skrajnych wartości odstających).

Wyobraź sobie sytuację: klikasz przycisk „Dodaj do koszyka" w sklepie internetowym, a strona reaguje dopiero po dwóch sekundach. Przez ten czas nie widzisz żadnego potwierdzenia – nie wiesz, czy kliknięcie zadziałało. Właśnie takie opóźnienia mierzy INP. Im niższa wartość wyrażona w milisekundach, tym lepiej – oznacza to, że strona szybko reaguje na każdą interakcję.

INP uwzględnia trzy fazy każdej interakcji:

• Input delay – czas między interakcją użytkownika a rozpoczęciem przetwarzania przez przeglądarkę (np. gdy główny wątek JavaScript jest zajęty innym zadaniem)
• Processing time – czas wykonania kodu obsługi zdarzenia (event handlerów)
• Presentation delay – czas potrzebny przeglądarce na przeliczenie layoutu, wyrenderowanie zmian i wyświetlenie kolejnej klatki

Suma tych trzech faz daje łączny czas interakcji. INP wybiera spośród wszystkich interakcji podczas sesji tę o najwyższym opóźnieniu (a dokładniej – stosuje aproksymację percentyla 98., aby odrzucić pojedyncze skrajne przypadki). To sprawia, że metryka jest bardziej miarodajna niż poprzednie wskaźniki responsywności.

Z perspektywy pozycjonowania strony, INP stał się jednym z trzech filarów Core Web Vitals – obok LCP (Largest Contentful Paint) i CLS (Cumulative Layout Shift). Google oficjalnie włączył tę metrykę do sygnałów rankingowych w marcu 2024 roku, zastępując wcześniejszy wskaźnik FID.

INP zastępuje FID – co się zmieniło?

Przez lata Google korzystał z metryki FID (First Input Delay) jako wskaźnika responsywności w ramach Core Web Vitals. FID miał jednak poważne ograniczenia, które INP skutecznie eliminuje. Zrozumienie różnic między tymi metrykami pozwala lepiej diagnozować problemy z wydajnością stron.

FID mierzył wyłącznie opóźnienie wejściowe pierwszej interakcji – czyli czas między pierwszym kliknięciem lub dotknięciem a początkiem przetwarzania. Pomijał dwie kluczowe kwestie:

1. Tylko pierwsza interakcja – FID ignorował wszystkie kolejne interakcje użytkownika. Strona mogła mieć szybką reakcję na pierwsze kliknięcie, ale zacinać się przy każdym następnym – FID tego nie wykrywał.
2. Tylko faza input delay – FID nie uwzględniał czasu przetwarzania event handlerów ani czasu renderowania. Strona mogła mieć zerowe opóźnienie wejściowe, ale sam processing trwał 800 ms – FID pokazywał „doskonały" wynik.

W praktyce oznaczało to, że ponad 90% stron w internecie „zdawało" test FID z wynikiem poniżej 100 ms. Metryka była zbyt łagodna i nie oddawała rzeczywistego doświadczenia użytkowników. Wielu właścicieli stron miało pozornie świetne wyniki FID, podczas gdy ich użytkownicy narzekali na wolne działanie interfejsu.

INP rozwiązuje oba problemy. Po pierwsze – monitoruje wszystkie interakcje w trakcie całej sesji, nie tylko pierwszą. Po drugie – mierzy pełny cykl od kliknięcia do wyświetlenia odpowiedzi wizualnej, uwzględniając input delay, processing time i presentation delay. To daje znacznie dokładniejszy obraz responsywności strony.

Oficjalna zmiana nastąpiła 12 marca 2024 roku. Od tego dnia Google zastąpił FID metryką INP we wszystkich raportach Core Web Vitals – zarówno w PageSpeed Insights, jak i w Search Console oraz Chrome UX Report. Dla wielu stron przejście na INP ujawniło problemy, które FID maskował. Według danych Chrome UX Report, po zmianie metryki odsetek stron z „dobrym" wynikiem responsywności spadł z ponad 90% do około 65%.

Jeśli prowadzisz sklep internetowy, ta zmiana jest szczególnie istotna. Sklepy mają dziesiątki interakcji na sesję – filtrowanie produktów, dodawanie do koszyka, otwieranie podstron, wypełnianie formularzy. FID sprawdzał tylko pierwsze kliknięcie; INP weryfikuje responsywność przy każdej z tych czynności.

Jak mierzyć INP strony?

Pomiar INP wymaga połączenia danych laboratoryjnych (syntetycznych) z danymi polowymi (od rzeczywistych użytkowników). Każde podejście ma swoje zastosowanie – laboratoryjne pomagają w diagnostyce, polowe pokazują faktyczny wynik uwzględniany przez Google.

Dane polowe (field data) – najważniejsze

Google wykorzystuje dane polowe z Chrome UX Report (CrUX) do oceny Core Web Vitals. To właśnie te dane wpływają na ranking. Oto narzędzia, z których warto korzystać:

• Google Search Console → Core Web Vitals – raport pokazujący, które strony mają dobry, wymagający poprawy lub słaby INP. Grupuje strony o podobnej strukturze, co ułatwia priorytetyzację. Jest to podstawowe narzędzie, po które powinieneś sięgnąć w pierwszej kolejności.
• PageSpeed Insights – po wpisaniu URL wyświetla dane CrUX dla konkretnej strony lub całej domeny. Sekcja „Discover what your real users are experiencing" pokazuje faktyczne wartości INP z ostatnich 28 dni.
• Chrome UX Report (BigQuery / CrUX API) – surowe dane percentylowe. Przydatne do analizy trendów w czasie lub porównywania się z konkurencją.
• Biblioteka web-vitals – skrypt JavaScript, który możesz osadzić na stronie, aby zbierać dane INP od własnych użytkowników i wysyłać je np. do Google Analytics 4. To najdokładniejsze źródło danych dla Twojej strony.

Dane laboratoryjne (lab data) – diagnostyka

Dane laboratoryjne nie są uwzględniane przez Google w rankingu, ale pomagają zidentyfikować i naprawić problemy:

• Chrome DevTools → Performance panel – nagrywanie interakcji w czasie rzeczywistym. Po kliknięciu elementu na stronie zobaczysz dokładny podział na input delay, processing time i presentation delay. Pozwala to wskazać konkretny „wąski gardło".
• Lighthouse – od wersji 10.0 raportuje Timespan Mode, w którym można mierzyć interakcje w trakcie nawigacji. Tryb standardowy (snapshot) nie mierzy INP, ponieważ wymaga rzeczywistych interakcji.
• Web Vitals Extension – rozszerzenie Chrome wyświetlające INP w czasie rzeczywistym podczas przeglądania strony. Klikasz, przewijasz, wypełniasz formularz – a rozszerzenie na bieżąco pokazuje najgorszą interakcję.

Praktyczna ścieżka pomiaru

Zalecamy następujące podejście: najpierw sprawdź dane polowe w Search Console, aby zidentyfikować strony z problemami. Następnie otwórz problematyczną stronę w Chrome DevTools (zakładka Performance) i odtwórz typowe interakcje użytkownika – kliknięcia w menu, formularze, przyciski. Analizuj waterfall, szukając długich zadań JavaScript (Long Tasks) blokujących główny wątek. Taki audyt SEO pod kątem wydajności pozwoli Ci precyzyjnie wskazać źródło problemów.

Jaki wynik INP jest dobry?

Google zdefiniował trzy progi oceny INP, analogicznie do pozostałych metryk Core Web Vitals:

Próg 200 ms to wartość, do której powinieneś dążyć. Badania nad percepcją czasu reakcji (model RAIL od Google) wskazują, że opóźnienia poniżej 200 ms są odbierane przez człowieka jako „natychmiastowe" lub „szybkie". Powyżej 200 ms użytkownik zaczyna świadomie zauważać zwłokę. Powyżej 500 ms doświadczenie staje się frustrujące – pojawia się niepewność, czy kliknięcie w ogóle zadziałało.

Ocena w raporcie CrUX bazuje na 75. percentylu danych od rzeczywistych użytkowników. Oznacza to, że 75% wizyt na Twojej stronie musi osiągać INP ≤ 200 ms, aby strona otrzymała ocenę „Dobry". To ważna informacja – nawet jeśli mediana INP wynosi 120 ms, ale 30% użytkowników doświadcza INP powyżej 200 ms, strona nie zaliczy testu.

Jak wypadają typowe strony?

Na podstawie danych z Chrome UX Report i naszego doświadczenia w Noril.pl obserwujemy następujące zakresy wyników:

• Statyczne strony firmowe (niewiele JavaScriptu) – INP 50–120 ms. Zwykle bez problemów.
• Blogi na WordPressie – INP 100–300 ms. Zależy od liczby wtyczek i jakości szablonu.
• Sklepy e-commerce – INP 150–600 ms. Filtry, karuzele, dynamiczne listy produktów generują wiele ciężkich interakcji.
• Aplikacje SPA (React, Angular, Vue) – INP 100–800 ms. Duży rozrzut – dobrze zoptymalizowane SPA mogą mieć doskonały INP, ale źle napisane potrafią przekraczać sekundę.

Jeśli prowadzisz sklep online, warto regularnie monitorować INP – dynamiczne elementy interfejsu (filtry cenowe, warianty produktu, dodawanie do koszyka) to najczęstsze źródła problemów. Nawet niewielka poprawa INP może przełożyć się na wyższy współczynnik klikalności CTR i lepsze konwersje.

Najczęstsze przyczyny słabego INP

Słaby wynik Interaction to Next Paint INP niemal zawsze wynika z problemów z JavaScriptem. Przeglądarka dysponuje jednym głównym wątkiem (main thread), w którym przetwarza zarówno interakcje użytkownika, jak i wykonuje kod JavaScript. Gdy wątek jest zajęty – interakcje czekają w kolejce. Oto najczęstsze przyczyny:

1. Długie zadania JavaScript (Long Tasks)

Każde zadanie JavaScript trwające ponad 50 ms jest klasyfikowane jako „Long Task". Jeśli użytkownik kliknie przycisk w momencie, gdy główny wątek wykonuje 300-milisekundowe zadanie, musi czekać na jego zakończenie. To najczęstsza przyczyna wysokiego input delay – pierwszej fazy INP.

Typowe źródła Long Tasks:

• Inicjalizacja dużych bibliotek JavaScript przy starcie strony
• Przetwarzanie i parsowanie dużych porcji danych JSON
• Skomplikowane operacje na DOM (np. renderowanie setek elementów listy)
• Skrypty analityczne i reklamowe blokujące wątek główny

2. Zbyt ciężkie event handlery

Kod wykonywany w odpowiedzi na interakcję (np. onclick, oninput) może sam w sobie być wolny. Jeśli po kliknięciu przycisku uruchamiasz synchroniczne obliczenia, filtrujesz tysiące elementów tablicy lub wykonujesz wiele operacji na DOM – processing time rośnie. Klasyczny przykład: filtr produktów w sklepie, który po każdym kliknięciu checkboxa przelicza i rerenderuje całą listę 500 produktów.

3. Nadmiarowy JavaScript stron trzecich

Skrypty zewnętrzne – czaty, piksele śledzące, widgety social media, mapy, narzędzia A/B testowania – często wykonują ciężkie operacje na głównym wątku. Pojedynczy skrypt czatu na żywo potrafi dodać 200–400 ms do czasu odpowiedzi na interakcję. Kumulacja kilku takich skryptów tworzy poważny problem.

4. Duży i skomplikowany DOM

Gdy strona zawiera tysiące elementów DOM, faza presentation delay wydłuża się. Przeglądarka musi przeliczyć layout i wyrenderować zmiany – im więcej elementów, tym więcej obliczeń. Strony z DOM przekraczającym 3000 elementów często mają podwyższony INP wyłącznie z powodu kosztownego renderowania.

5. Brak optymalizacji renderowania CSS

Animacje CSS oparte na właściwościach takich jak width, height, top, left lub margin wymuszają przeliczanie layoutu (reflow) przy każdej klatce. Jeśli te animacje działają równocześnie z interakcją użytkownika, presentation delay gwałtownie rośnie. Animacje powinny korzystać z transform i opacity, które są obsługiwane przez GPU bez blokowania main thread.

6. Brak debounce/throttle na intensywnych interakcjach

Pola wyszukiwania z autouzupełnianiem, suwaki cenowe, zdarzenia scroll – bez mechanizmu ograniczania częstotliwości wywołań (debounce lub throttle) generują setki zdarzeń na sekundę. Każde zdarzenie uruchamia event handler, co przeciąża główny wątek i powoduje, że kolejna „duża" interakcja trafia na zablokowany wątek.

Jak poprawić INP na stronie?

Poprawa wyniku INP wymaga systematycznego podejścia. Poniżej przedstawiamy sprawdzone techniki, które stosujemy w ramach optymalizacji stron naszych klientów. Każda z nich adresuje konkretną fazę interakcji.

Redukcja input delay – odblokowanie głównego wątku

Dzielenie długich zadań (yield to main thread). Zamiast wykonywać jeden ciągły blok kodu przez 300 ms, podziel go na mniejsze fragmenty. Użyj scheduler.yield() (nowe API) lub setTimeout(0) między krokami, aby przeglądarka mogła obsłużyć oczekujące interakcje między fragmentami. To najskuteczniejsza pojedyncza optymalizacja dla INP.

Opóźnione ładowanie niekrytycznego JavaScriptu. Skrypty, które nie są potrzebne do pierwszej interakcji, powinny być ładowane z atrybutem defer lub dynamicznie po załadowaniu strony. Dotyczy to zwłaszcza skryptów analitycznych, widgetów czatu i narzędzi marketingowych. Strategia: załaduj je po zdarzeniu load lub przy pierwszej interakcji użytkownika.

Eliminacja nieużywanego JavaScriptu. Narzędzie Coverage w Chrome DevTools pokazuje, jaki procent załadowanego kodu jest faktycznie wykonywany. Na typowej stronie 40–60% JavaScriptu nigdy się nie uruchamia. Usunięcie lub odłożenie tego kodu bezpośrednio zmniejsza obciążenie main thread.

Skrócenie processing time – optymalizacja event handlerów

Minimalizacja pracy w event handlerach. Event handler powinien robić absolutne minimum – zaktualizować stan i zlecić renderowanie. Ciężkie obliczenia (sortowanie, filtrowanie, walidacja) przenieś do Web Workerów, które działają w osobnym wątku i nie blokują main thread.

Wykorzystanie requestAnimationFrame. Zmiany wizualne powinny być grupowane i wykonywane w ramach requestAnimationFrame. Dzięki temu przeglądarka może zoptymalizować renderowanie, zamiast przeliczać layout po każdej pojedynczej zmianie DOM.

Wirtualizacja list. Jeśli wyświetlasz długie listy produktów, wyników lub komentarzy, użyj wirtualizacji (np. biblioteki virtual-scroller lub react-window). Zamiast renderować 1000 elementów, renderuj tylko te widoczne w viewporcie – np. 20. To drastycznie zmniejsza koszt aktualizacji DOM.

Redukcja presentation delay – szybsze renderowanie

Upraszczanie struktury DOM. Dąż do utrzymania liczby elementów DOM poniżej 1500. Usuń zbędne wrappery i zagnieżdżenia. Każdy dodatkowy element to dodatkowa praca przy przeliczaniu layoutu. W praktyce oznacza to rezygnację z nadmiarowych div-ów i stosowanie płaskich struktur HTML.

Unikanie wymuszania layout/reflow. Odczytywanie właściwości geometrycznych (np. offsetHeight, getBoundingClientRect()) po modyfikacji DOM wymusza synchroniczny reflow. To tzw. „layout thrashing" – jedno z najkosztowniejszych zjawisk w przeglądarce. Grupuj odczyty i zapisy do DOM osobno.

Stosowanie właściwości CSS content-visibility: auto. Ta właściwość informuje przeglądarkę, że elementy poza viewportem nie muszą być renderowane. Dla stron z dużą ilością treści poniżej „złamania" (below the fold) – np. długich artykułów blogowych czy stron kategorii – to prosta optymalizacja dająca natychmiastowe rezultaty.

Audyt i monitorowanie

Poprawa INP to nie jednorazowa akcja, lecz ciągły proces. Każda zmiana na stronie – nowy skrypt, aktualizacja wtyczki, dodanie widgetu – może pogorszyć wynik. Regularne monitorowanie danych polowych w Search Console i analiza trendów w Google Analytics 4 pozwolą szybko wychwycić regresje. W Noril.pl rekomendujemy comiesięczny przegląd metryk Core Web Vitals jako element audytu technicznego SEO.

INP a pozycjonowanie w Google

Od marca 2024 roku INP jest oficjalną częścią sygnału Page Experience, który Google uwzględnia w algorytmie rankingowym. Razem z LCP i CLS tworzy trójkę Core Web Vitals – metryk mierzących jakość doświadczenia użytkownika na stronie. Ale jak duży jest faktyczny wpływ INP na pozycje w wynikach wyszukiwania?

Trzeba powiedzieć wprost: Core Web Vitals to jeden z wielu sygnałów rankingowych i nie jest najważniejszy. Treść, linki, autorytet domeny, dopasowanie do intencji wyszukiwania – te czynniki nadal mają zdecydowanie większą wagę. Google wielokrotnie potwierdzał, że strona z doskonałą treścią i słabymi CWV może rankować wyżej niż strona z idealnymi metrykami, ale słabą zawartością.

Jednak w sytuacji, gdy dwie strony są porównywalne pod względem treści i autorytetu – Core Web Vitals stają się czynnikiem rozstrzygającym. To tak zwany „tie-breaker" – przewaga, która może przesądzić o pozycji 3. vs 5. w wynikach wyszukiwania. Na konkurencyjnych frazach, gdzie dziesiątki stron walczy o pierwszą stronę, każdy sygnał ma znaczenie.

Jest też aspekt pośredni, który bywa ważniejszy od bezpośredniego wpływu na ranking. Wolna, niereaktywna strona generuje gorsze sygnały behawioralne:

• Wyższy współczynnik odrzuceń – użytkownicy opuszczają stronę, gdy ta nie reaguje na ich działania
• Krótszy czas sesji – frustracja prowadzi do szybszego zamknięcia karty
• Mniejsza konwersja – każde 100 ms opóźnienia interakcji to statystycznie 0,5–1% spadek konwersji
• Niższy CTR przy kolejnych wizytach – użytkownicy zapamiętują wolne strony i omijają je w przyszłości

Te sygnały wpływają na ranking silniej niż sam wynik Core Web Vitals. Jeśli pozycjonujesz stronę i inwestujesz w treści, linkbuilding, zdobywanie pozycji zero, a jednocześnie ignourujesz responsywność – podcinasz gałąź, na której siedzisz. Doskonałe treści na wolnej stronie generują mniejszy ruch, niższe zaangażowanie i gorszy zwrot z inwestycji ROAS.

Warto też pamiętać o kontekście mobilnym. Ponad 60% ruchu w Polsce pochodzi z urządzeń mobilnych, które mają słabsze procesory niż komputery stacjonarne. Interakcja, która na desktopie zajmuje 150 ms, na smartfonie z niższej półki może trwać 400–600 ms. Google ocenia Core Web Vitals oddzielnie dla urządzeń mobilnych i desktopów – i to wynik mobilny ma zazwyczaj większe znaczenie dla rankingu. Firmy lokalne, inwestujące w SEO lokalne, powinny szczególnie zwracać na to uwagę, ponieważ ich klienci najczęściej szukają usług właśnie z telefonu.

Poprawa INP jest szczególnie opłacalna dla branż o wysokiej interaktywności serwisów: e-commerce, SaaS, portale ogłoszeniowe, serwisy z formularzami. Jeśli Twoja strona to statyczny landing page z kilkoma podstronami, INP prawdopodobnie nie będzie problemem. Ale jeśli prowadzisz sklep internetowy lub portal z zaawansowanym interfejsem – INP może być metryką, która odróżnia Cię od konkurencji. W kontekście opłacalności SEO jest to optymalizacja, która oprócz wpływu na pozycje bezpośrednio przekłada się na doświadczenie klienta i konwersje.

Pamiętaj również, że rozwój AI w wyszukiwarkach nie zmienia znaczenia Core Web Vitals. Niezależnie od tego, jak ewoluują algorytmy Google, szybka i responsywna strona zawsze będzie preferowana – zarówno przez wyszukiwarki, jak i przez użytkowników. Inwestycja w pozycjonowanie powinna obejmować nie tylko treści i linki, ale również solidne fundamenty techniczne, na czele z Interaction to Next Paint INP.