Interaction to Next Paint (INP)

Interaction to Next Paint (INP) to metryka wydajności stron internetowych, która mierzy, jak szybko strona wizualnie reaguje na działania użytkownika, licząc czas od rozpoczęcia interakcji (np. kliknięcia, dotknięcia ekranu, naciśnięcia klawisza) do momentu, w którym przeglądarka wykona następne odmalowanie (paint) widoczne dla użytkownika. Jest to miara „odczuwanej responsywności” interfejsu w trakcie realnego korzystania ze strony.

INP opisuje opóźnienia, które użytkownik zauważa jako „strona nie reaguje”, „przycisk nie działa”, „formularz się zacina” lub „lista przewija się z opóźnieniem”. W przeciwieństwie do metryk skupionych na samym ładowaniu (np. czas wyświetlenia pierwszych elementów), INP dotyczy interakcji po załadowaniu oraz w trakcie dynamicznego działania aplikacji: otwierania menu, filtrowania wyników, dodawania do koszyka, walidacji pól, rozwijania akordeonów czy przełączania zakładek.

Technicznie INP obejmuje czas potrzebny na obsłużenie zdarzenia wejściowego i doprowadzenie do widocznej zmiany na ekranie. W praktyce na wynik wpływają m.in. obciążenie głównego wątku JavaScript, długo wykonywanych zadań (tzw. long tasks), koszt obliczeń i renderowania, a także to, czy interakcja faktycznie powoduje zmianę wizualną. Przykład: kliknięcie „Pokaż więcej” może uruchomić logikę JS, pobrać dane, zaktualizować DOM i dopiero potem doprowadzić do odmalowania listy — INP będzie odzwierciedlać opóźnienie do tego pierwszego widocznego efektu.

INP jest szczególnie istotne dla stron i aplikacji o dużej interaktywności (e-commerce, serwisy z filtrami, panele użytkownika, aplikacje SPA), gdzie użytkownik wykonuje wiele działań w jednej sesji. Dla właścicieli stron i redaktorów treści oznacza to, że „ciężkie” elementy (rozbudowane widżety, skrypty śledzące, edytory, osadzenia) mogą pogarszać responsywność nawet wtedy, gdy strona ładuje się szybko. Dla inżynierów INP jest sygnałem, że należy szukać blokad w głównym wątku, ograniczać kosztowne operacje w reakcji na input i projektować UI tak, aby szybko dostarczać użytkownikowi informację zwrotną (np. natychmiastowe podświetlenie przycisku, stan „ładowanie”, optymalizacja renderowania list).

• Kluczowe właściwości
• INP mierzy opóźnienie od interakcji do następnego odmalowania (widocznej aktualizacji), a więc jest metryką „odczuwalnej” responsywności, a nie samego czasu wykonania kodu.
• Dotyczy interakcji użytkownika takich jak kliknięcia, dotknięcia i naciśnięcia klawiszy; nie opisuje automatycznych animacji czy zdarzeń niezainicjowanych przez użytkownika.
• Jest wrażliwe na blokowanie głównego wątku: długie zadania JS, złożone obliczenia, kosztowne aktualizacje DOM, style i layout mogą opóźniać paint.
• Wartość INP dla strony jest wyznaczana na podstawie najbardziej problematycznych interakcji w trakcie wizyty (metryka ma charakter „worst-ish case” w obrębie sesji), dlatego pojedyncze zacięcia mogą istotnie podnieść wynik.

• Typowe konteksty użycia
• Ocena jakości UX w miejscach, gdzie użytkownik oczekuje natychmiastowej reakcji: przyciski „Dodaj do koszyka”, „Zastosuj filtr”, „Wyślij”, przełączniki, rozwijane menu.
• Diagnostyka problemów w aplikacjach z intensywnym JS (SPA, rozbudowane komponenty UI), gdzie ładowanie początkowe bywa dobre, ale interakcje są „ciężkie”.
• Porównywanie wariantów implementacji: np. filtrowanie po stronie klienta vs. serwera, wirtualizacja listy vs. renderowanie całej tabeli, debounce/throttle zdarzeń.
• Monitorowanie wpływu elementów zewnętrznych (tagi analityczne, reklamy, osadzenia) na responsywność interfejsu podczas przewijania i klikania.

• Częste nieporozumienia
• „INP to to samo co szybkość ładowania strony.” Nie: INP dotyczy reakcji na interakcje, także długo po zakończeniu ładowania.
• „Jeśli handler kliknięcia wykona się szybko, INP będzie dobre.” Niekoniecznie: liczy się czas do widocznego paint, a opóźnienie może wynikać z layoutu, stylów, renderowania lub innych zadań w kolejce.
• „INP mierzy każdą animację i przewijanie.” INP dotyczy interakcji wejściowych; przewijanie może pośrednio wpływać na odczucia, ale sama metryka jest zdefiniowana wokół zdarzeń input i następnego odmalowania.
• „Wystarczy zoptymalizować jeden element.” Ponieważ wynik może zależeć od najgorszych interakcji, trzeba identyfikować konkretne scenariusze powodujące zacięcia (np. otwarcie ciężkiego modala, walidacja formularza, render dużej listy) i usuwać wąskie gardła.