Interaction to Next Paint (INP): jak zdiagnozować i naprawić opóźnienia reakcji na stronie w 2026

Interaction to Next Paint (INP) mierzy coś, co użytkownik czuje natychmiast: klikam, stukam, wpisuję, a strona albo odpowiada od razu, albo przez ułamek sekundy udaje martwą. Ten ułamek sekundy ma znaczenie. Na stronie firmowej może oznaczać porzucony formularz, nieotwarte menu mobilne albo klienta, który wraca do wyników Google.

W 2026 roku nie wystarczy już patrzeć na ogólny wynik PageSpeed Insights. Trzeba wiedzieć, gdzie reakcja strony faktycznie się zacina, na jakich urządzeniach i przy których interakcjach. INP pomaga znaleźć ten problem, ale tylko wtedy, gdy czytasz dane we właściwej kolejności.

Co dokładnie mierzy INP?

INP opisuje czas od interakcji użytkownika do następnego widocznego odświeżenia interfejsu. Interakcją może być kliknięcie przycisku, stuknięcie w menu, wpisanie znaku w formularzu albo użycie elementu sterującego na stronie.

W praktyce:

• do 200 ms to wynik dobry,
• od 200 do 500 ms wymaga poprawy,
• powyżej 500 ms jest problemem dla UX i Core Web Vitals.

Ważne: INP nie mierzy samego pobierania strony. Strona może mieć dobry LCP, wyglądać szybko po wejściu, a mimo to reagować wolno po pierwszym kliknięciu. Dlatego wpis o Core Web Vitals i poprawie wydajności strony warto traktować jako szerszy kontekst, a ten poradnik jako procedurę dla samej responsywności.

Objawy słabego INP, które widać bez narzędzi

Zanim otworzysz wykresy, sprawdź stronę jak normalny użytkownik. Najczęstsze sygnały:

• menu mobilne otwiera się z wyczuwalnym opóźnieniem,
• przycisk formularza nie reaguje od razu po kliknięciu,
• pole tekstowe przycina się podczas wpisywania,
• przewijanie zacina się, gdy ładuje się widget czatu, mapa albo skrypt analityczny,
• kliknięcie w filtr, karuzelę albo zakładkę nie daje natychmiastowej zmiany wizualnej.

Jeśli takie objawy pojawiają się na kilkuletnim telefonie, nie ignoruj ich tylko dlatego, że na Twoim laptopie wszystko działa płynnie. INP najczęściej psuje się na słabszych procesorach i przy większej liczbie skryptów w tle.

Krok 1: sprawdź Google Search Console

Google Search Console jest pierwszym miejscem, bo pokazuje dane z prawdziwych wizyt, a nie jednorazową symulację. Wejdź w raport podstawowych wskaźników internetowych i sprawdź grupy adresów oznaczone jako wymagające poprawy albo słabe.

Zwróć uwagę na trzy rzeczy:

1. Czy problem dotyczy mobile, desktopu, czy obu widoków.
2. Które grupy URL są oznaczone jako problematyczne.
3. Czy problem dotyczy INP, czy innej metryki.

Jeśli Search Console pokazuje słaby INP dla wielu podobnych adresów, zwykle winny jest wspólny element: globalny skrypt, menu, formularz, banner cookies, widget czatu albo ciężki komponent ładowany na całym serwisie.

Krok 2: potwierdź problem w PageSpeed Insights

PageSpeed Insights łączy dane rzeczywiste z testem laboratoryjnym. W przypadku INP najpierw patrz na sekcję danych rzeczywistych, jeśli jest dostępna. To tam zobaczysz, czy Chrome User Experience Report potwierdza problem.

Dopiero potem analizuj Lighthouse. Lighthouse nie klika strony tak jak człowiek, więc nie zawsze złapie konkretną wolną interakcję. Może jednak pokazać tropy:

• długie zadania na głównym wątku,
• zbyt duży JavaScript,
• ciężkie skrypty firm trzecich,
• wysoki Total Blocking Time,
• zbyt kosztowne renderowanie po starcie strony.

Więcej o różnicy między laboratorium a realnym użytkownikiem opisałem we wpisie Dlaczego PageSpeed Insights kłamie.

Krok 3: nagraj interakcję w Chrome DevTools

Najważniejsza diagnoza dzieje się w Chrome DevTools. Otwórz zakładkę Performance, włącz nagrywanie, wykonaj problematyczną interakcję i zatrzymaj profil. Testuj na throttlingu CPU, bo inaczej szybki komputer może ukryć problem.

Szukaj:

• długich zadań blokujących główny wątek,
• event handlerów, które robią zbyt dużo pracy,
• kosztownych przeliczeń stylów i layoutu,
• dużych paczek JavaScript wykonywanych tuż po interakcji,
• skryptów zewnętrznych uruchamianych w złym momencie.

Jeśli kliknięcie w menu uruchamia setki milisekund JavaScriptu, problem nie leży w animacji. Problemem jest praca wykonywana zanim przeglądarka zdąży pokazać zmianę.

Co najczęściej psuje INP?

Za dużo JavaScriptu na starcie

Strony oparte na ciężkich motywach, builderach albo wielu wtyczkach często ładują kod, którego użytkownik nie potrzebuje od razu. Każdy parser, inicjalizacja i event listener zabiera czas głównemu wątkowi.

Naprawa:

• usuń skrypty nieużywane na danej podstronie,
• dziel kod na mniejsze paczki,
• ładuj elementy interaktywne dopiero tam, gdzie są potrzebne,
• opóźnij skrypty marketingowe, które nie są krytyczne.

Ciężkie widgety zewnętrzne

Czat, mapa, system opinii, piksel reklamowy i rozbudowana analityka potrafią działać poprawnie osobno, ale razem tworzą korek na głównym wątku. Użytkownik klika, a przeglądarka kończy pracę dla skryptu zewnętrznego.

Naprawa:

• ładuj widget po zgodzie albo po interakcji,
• zastąp mapę statycznym linkiem lub obrazem do czasu kliknięcia,
• usuń duplikaty tagów,
• sprawdź GTM i wyłącz stare reguły.

Formularze z ciężką walidacją

Formularz kontaktowy powinien reagować natychmiast. Jeśli walidacja, maskowanie pól, antyspam i tracking odpalają się naraz, kliknięcie w "wyślij" może stać się najwolniejszą interakcją na stronie.

Naprawa:

• używaj natywnych typów pól i prostych atrybutów HTML,
• waliduj kosztowne rzeczy po stronie serwera,
• pokaż natychmiastowy stan przycisku po kliknięciu,
• nie blokuj interfejsu na czas wysyłki.

Animacje i layout

Animacje oparte na zmianie wymiarów, cieni, filtrów i pozycji wielu elementów potrafią wymusić kosztowne przeliczenia stylów. To szczególnie bolesne na mobile.

Naprawa:

• animuj transform i opacity,
• unikaj animowania wysokości długich list,
• ogranicz efekty blur i duże cienie,
• rezerwuj miejsce dla elementów, które pojawiają się po kliknięciu.

Priorytet napraw: co robić najpierw?

Nie zaczynaj od losowego "optymalizowania wszystkiego". Kolejność ma znaczenie:

1. Znajdź adresy z problemem w Google Search Console.
2. Potwierdź, czy problem dotyczy mobile.
3. Odtwórz najważniejsze interakcje w Chrome DevTools.
4. Usuń lub opóźnij największe blokujące skrypty.
5. Popraw konkretny handler lub komponent.
6. Wdróż zmianę i obserwuj dane przez kolejne 28 dni.

INP z danych CrUX nie poprawi się natychmiast po deployu, bo Google agreguje dane w czasie. Dlatego po wdrożeniu warto mieć też własny prosty monitoring realnych użytkowników, który pokaże trend szybciej.

Checklista INP przed wdrożeniem

• Menu mobilne reaguje natychmiast na słabszym telefonie.
• Formularz pokazuje stan po kliknięciu bez czekania na odpowiedź sieci.
• Skrypty marketingowe nie ładują się synchronicznie w krytycznym momencie.
• Widgety zewnętrzne są opóźnione albo ładowane po interakcji.
• Największe event handlery są krótkie i nie wykonują pracy, którą można przenieść później.
• Animacje używają właściwości tanich dla przeglądarki.
• PageSpeed Insights nie jest jedynym źródłem decyzji.

Kiedy potrzebny jest głębszy audyt?

Jeśli INP jest słaby na wielu podstronach, zwykle nie wystarczy jedna drobna poprawka. To znak, że problem jest systemowy: framework ładuje za dużo kodu, motyw ma zbyt ciężkie komponenty, a skrypty firm trzecich rosną bez kontroli.

W takim przypadku najlepszy efekt daje audyt techniczny: analiza Core Web Vitals, profilowanie interakcji, przegląd skryptów i plan poprawek według wpływu na użytkownika. Celem nie jest zielony wynik dla samego wyniku. Celem jest strona, która reaguje od razu wtedy, gdy klient chce zadzwonić, wysłać formularz albo przejść do oferty.