Czym jest Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) to pojęcie, które przenosi rozumienie reaktywności strony z pojedynczego kliknięcia na całą sesję użytkownika. Wbrew pozorom nie chodzi w nim tylko o szybkość wykonania funkcji czy rozmiar pakietu JavaScript, ale o czas, po jakim przeglądarka realnie pokazuje pierwszą widoczną odpowiedź na interakcję. Dzięki temu INP pozwala na ocenę, czy witryna sprawia wrażenie natychmiast reagującej, czy też zmusza odbiorcę do czekania na następny kadr, w którym pojawi się zmiana w interfejsie. Metryka została włączona do zestawu Core Web Vitals, zastępując FID, i stała się jednym z głównych standardów oceny jakości doświadczenia na stronach internetowych.

Definicja i sens praktyczny Interaction to Next Paint

Interaction to Next Paint (INP) to czas od początku interakcji użytkownika (np. kliknięcia, stuknięcia lub naciśnięcia klawisza) do momentu, gdy przeglądarka wyświetli pierwszy następny kadr z widoczną odpowiedzią interfejsu na tę interakcję. W ramach jednej wizyty na stronie system grupuje wszystkie interakcje, a wynik INP jest zwykle określany jako wysokie percentyle (np. 98. percentyl) najdłuższych z nich. Taki sposób ujęcia wzmacnia wiarygodność metryki: pojedynczy, losowy „pik” nie zdominuje oceny, ale również nie zostanie pominięty powtarzalny problem dokuczający wielu osobom.

Kluczowa różnica względem poprzedników polega na tym, że INP ocenia nie tylko początkowe opóźnienie, lecz także przetwarzanie w kodzie oraz przedstawienie efektu na ekranie. Obiektem pomiaru jest zatem pełny łańcuch reakcji przeglądarki: zarejestrowanie wejścia, obsługa logiki, przebudowa stylów i układu, a następnie narysowanie nowej klatki na ekranie. Jeśli którykolwiek z tych elementów działa zbyt wolno, INP ulegnie pogorszeniu.

Dla zespołów projektujących interfejsy INP stanowi praktyczny wskaźnik „odczuwalnej” szybkości aplikacji. Użytkownicy nie mierzą czasu zegarkiem — oni czują płynność. Gdy klikają przycisk i natychmiast widzą zmianę stanu, zaufanie do interfejsu rośnie. Kiedy przeciwnie — kliknięcie zdaje się znikać w próżni, pojawia się niepewność: czy witryna działa, czy trzeba kliknąć ponownie, czy nastąpił błąd? INP przekłada tę niepewność na liczby, umożliwiając systematyczne usprawnienia.

Co dokładnie mierzy INP i jak jest liczone

INP obejmuje trzy składowe czasu od interakcji do następnego kadru. Pierwsza składowa to początek interakcji: moment, gdy przeglądarka rejestruje wejście (click, pointerdown/pointerup, keydown/keyup). Druga to obsługa zdarzenia w kodzie: wykonanie wywołań zwrotnych, aktualizacja stanu, praca bibliotek i frameworków, obliczenia, możliwe żądania sieciowe o charakterze blokującym render. Trzecia to etap prezentacji: obliczenia stylów, układu, malowanie i kompozycja, które kończą się „następnym malowaniem” — czyli klatką zawierającą pierwszą wizualną odpowiedź na gest użytkownika.

Pomiar na poziomie przeglądarki bazuje na grupowaniu zdarzeń w interakcje. W praktyce pojawienie się jednego kliknięcia zwykle wiąże się z sekwencją eventów (pointerdown, click) oraz następującym po nich przetwarzaniem. Metryka przypisuje tym zdarzeniom wspólny identyfikator interakcji i mierzy czas od jej początku do pierwszej klatki z widoczną zmianą. Jeżeli w trakcie wizyty użytkownik wykona wiele interakcji, raportowany INP to miara ekstremum rozkładu — najczęściej 98. percentyl — co odfiltrowuje przypadki sporadyczne, zarazem akcentując te, które się powtarzają lub dotykają większej grupy odbiorców.

Warto zauważyć, że INP nie mierzy wyłącznie logiki aplikacji. Jeżeli w reakcji na kliknięcie UI inicjuje kosztowną re-kalkulację stylów i układu, sięga po ciężkie efekty wizualne lub generuje długi łańcuch reflow, to również wpływa na wynik. Podobnie blokady w pętli zdarzeń, długotrwałe mikro- i makrozadania JavaScript oraz interakcje z główną nitką przeglądarki przekładają się na opóźnienie następnej klatki.

W kontekście historii metryk warto zestawić INP z FID. Pierwszy Input Delay mierzył tylko opóźnienie rozpoczęcia obsługi pierwszej interakcji (zwykle pierwszego kliknięcia), ignorował czas przetwarzania i malowania oraz nie brał pod uwagę kolejnych działań użytkownika. INP eliminuje te ograniczenia: składa wynik z sumarycznego czasu odpowiedzi i obejmuje wiele interakcji, lepiej oddając realny odbiór płynności.

Mechanika przeglądarki: skąd biorą się opóźnienia

Aby zrozumieć, co zaniża INP, trzeba prześledzić wewnętrzną mechanikę przeglądarki. Większość logiki witryny działa na tzw. wątek główny (main thread), gdzie realizowane są: obsługa zdarzeń, przetwarzanie DOM, kalkulacja CSS, layout, malowanie i kompozycja. Jeśli główny wątek jest przeciążony, interakcje czekają w kolejce, a użytkownik nie widzi efektu swojego działania przez dłuższą chwilę.

Najczęstszym źródłem problemu jest długa operacja (long task), czyli zadanie JavaScript trwające ponad ~50 ms, które monopolizuje pętlę zdarzeń. Długie zadania mogą wynikać z rozpakowywania dużych bibliotek, kosztownych obliczeń (np. sortowanie ogromnych list), nieoptymalnego przetwarzania zdarzeń przewijania, zbyt ciężkiego re-renderingu w frameworku czy niekontrolowanych efektów ubocznych. Dopóki takie zadanie się nie zakończy, przeglądarka nie może wstawić nowej klatki ani rozpocząć obsługi kolejnego wejścia.

Drugim źródłem są intensywne przebudowy stylu i układu. Zmiana jednego elementu może doprowadzić do kaskadowej aktualizacji layoutu (reflow), szczególnie gdy kod często odczytuje właściwości wymuszające synchronizację (offsetHeight, getBoundingClientRect) między zapisami do DOM. Taki „ping-pong” powoduje kosztowne bariery i wydłuża czas do następnego malowania, wpływając na renderowanie po interakcji.

Trzecia kategoria to synchronizacja z innymi zasobami: czcionkami, arkuszami CSS lub skryptami, które muszą zostać pobrane i przetworzone przed aktualnym krokiem. Choć sieć nie wchodzi w skład samej definicji INP, to jeśli interfejs blokuje zmianę stanu do momentu otrzymania odpowiedzi (np. oczekuje na wynik zapytania) i nie pokazuje żadnego wizualnego feedbacku, użytkownik nie zobaczy kolejnej klatki — a więc metryka się pogorszy.

Na koniec warto wspomnieć o harmonogramowaniu zadań. Pętla zdarzeń obsługuje mikro- i makrokolejki; nieprzemyślane uruchamianie wielu microtasks (np. łańcuchów Promises) może paradoksalnie opóźnić kadrowanie, bo przeglądarka, zgodnie z zasadami, dokończy mikrozdania przed renderem. Odpowiedzialne rozdzielanie działań (yieldowanie) i priorytetyzacja krytycznych ścieżek są kluczowe dla dobrego INP.

Progi jakości i interpretacja wyniku

Progi interpretacji INP w Core Web Vitals są obecnie następujące:

Dobry wynik: ≤ 200 ms
Wymaga poprawy: > 200 ms i ≤ 500 ms
Słaby wynik: > 500 ms

To wartości odnoszące się do doświadczenia większości użytkowników w polu (field data), a więc do rzeczywistych wizyt. W praktyce zespół powinien dążyć, by 75. percentyl ruchu (desktop i mobile mierzony osobno) mieścił się w przedziale „dobry”.

Istotne jest rozumienie różnicy między danymi laboratoryjnymi a rzeczywistymi. Testy syntetyczne są powtarzalne i pozwalają wykryć regresje, ale to dane z prawdziwego ruchu ujawniają wpływ urządzeń, sieci, różnorodności zachowań oraz zewnętrznych skryptów. INP jest szczególnie wrażliwy na zmienność: dylematy interfejsu dotykowego (tap vs. click), długość list, reakcje komponentów po przescrollowaniu, a nawet wzorce nawigacji w aplikacjach SPA — wszystko to odbije się w rozkładzie czasu do następnego malowania.

Jeżeli Twój INP waha się w okolicach 300–450 ms, zacznij od poszukiwania największych „kolców” w dzienniku interakcji i od mapowania długich zadań na głównym wątku. W sytuacji, gdy INP przekracza 500 ms, z reguły problem jest systemowy: zbyt ciężkie operacje w reakcji na gest, nieodpowiednie priorytety lub brak jakiegokolwiek natychmiastowego feedbacku wizualnego. Z kolei wartości bardzo niskie (np. 60–120 ms) nie zwalniają z ostrożności — upewnij się, że metryka obejmuje interakcje kluczowe dla Twojego scenariusza (np. dodanie do koszyka, rozwinięcie filtra, wysłanie formularza), a nie tylko mniej obciążające działania.

Relacja z innymi wskaźnikami pozostaje komplementarna. LCP ocenia szybkość pojawienia się największego elementu treści, CLS stabilność układu, natomiast INP wiąże się z poczuciem kontroli podczas korzystania z interfejsu. Jeśli LCP i CLS są dobre, a INP słaby, witryna wygląda szybko tylko na pierwszy rzut oka — jednak reaguje ospale. I odwrotnie: świetny INP przy słabym LCP oznacza, że początek kontaktu jest niezadowalający, choć późniejsza praca jest płynna.

Jak mierzyć INP w praktyce: narzędzia i metody

Do dyspozycji są zarówno narzędzia laboratoryjne, jak i rozwiązania RUM (Real User Monitoring). Zestaw pomocny w codziennej pracy obejmuje:

PageSpeed Insights — łączy dane terenowe (Chrome UX Report) i laboratoryjne, pokazując INP jako jedną z kluczowych metryk.
Chrome DevTools (Performance Panel) — nagrywanie profilu pozwala zobaczyć oś zdarzeń, long tasks, okresy reflow i repaint. Przy interakcji szukaj czasu od eventu do następnego „frame”.
Lighthouse — raport syntetyczny z sugestiami; choć warunki są laboratoryjne, łatwo wykryć problematyczne wzorce.
Biblioteka web-vitals — proste API do gromadzenia INP w aplikacji i wysyłania do własnego systemu analityki.
Własny RUM — integracja poprzez PerformanceObserver i strumień „event” z przypisywaniem interactionId pozwala na finezyjną diagnostykę.

Dane terenowe są niezastąpione, bo oddają rozmaite urządzenia i realne nawyki. Laboratorium przydaje się do reprodukcji i redukcji problemów w kontrolowanym środowisku.

Przykład skorzystania z biblioteki web-vitals w aplikacji:

import {onINP} from 'web-vitals’;
onINP(({value, entries, id}) => {
// value to czas w ms (np. 185.2)
// entries zawiera najgorszą interakcję i jej eventy składowe
// Możesz wysłać dane do RUM lub zalogować
sendToAnalytics(’INP’, value, {id, entryCount: entries.length});
});

Jeśli potrzebujesz głębszej inspekcji, PerformanceObserver dla wpisów „event” umożliwia przechwytywanie zdarzeń i ich grupowanie:

const po = new PerformanceObserver((list) => {
for (const e of list.getEntries()) {
// e.duration, e.startTime, e.name (np. „click”), e.interactionId
// Można grupować po interactionId i śledzić czas do kolejnego frame
}
});
po.observe({type: 'event’, buffered: true, durationThreshold: 16});

Własny RUM powinien zapisywać typ interakcji, kontekst komponentu, obecność długich zadań w okolicy oraz ewentualne blokady stylu/układu. Dodatkowo warto przechowywać informacje o urządzeniu, przeglądarce i budowie strony (np. liczba aktywnych modułów), aby szybko wychwycić segmenty użytkowników cierpiących na gorsze wyniki.

Strategie poprawy INP: od mikrooptymalizacji do architektury

Optymalizacja INP musi koncentrować się na tym, co dzieje się „od gestu do piksela”. Poniżej sprawdzone techniki:

Zapewnij natychmiastowy feedback wizualny. Zmiana stanu przycisku, skeleton, spinner lub placeholder, nawet jeśli logika trwa dłużej, pozwalają wyświetlić klatkę szybko. Nie blokuj interfejsu na wynik sieci, jeśli nie jest to absolutnie konieczne.
Minimalizuj kod w obsłudze zdarzeń. Logikę ciężką deleguj poza hot-path, a w handlerze zostaw jedynie zmianę stanu UI i ewentualne zaplanowanie dalszych kroków.
Dziel długie zadania. Zamiast jednego 120-ms bloku użyj strategii „slice-and-yield” — podziel pracę na porcje po 4–10 ms i dawaj przeglądarce czas na render (requestAnimationFrame, setTimeout, scheduler.postTask z priorytetami).
Unikaj wymuszania synchronizacji layoutu. Grupuj odczyty i zapisy do DOM, korzystaj z transform zamiast top/left, ogranicz selektory powodujące szeroką invalidację stylów.
Wykorzystuj wątki poboczne. Web Workers mogą przejąć kosztowne obliczenia; wynik odsyłaj do głównego wątku dopiero, gdy jest potrzebny do odmalowania.
Weryfikuj biblioteki i skrypty zewnętrzne. Zbyt duża objętość lub koszt inicjalizacji potrafią zamulić cały interfejs. Ładuj je warunkowo i leniwie.
Virtualizuj listy i siatki. Renderuj tylko to, co widać i co jest niezbędne dla bieżącej interakcji.
Ustal priorytety. Zadbaj, by reakcje dotykowe i kliknięcia miały najwyższy priorytet, a wtórne działania (telemetria, reklamy, logi) były odroczone.
Prekomputacja i cache. Oblicz z wyprzedzeniem to, co prawdopodobnie będzie potrzebne po interakcji, zamiast generować wszystko w gorącej ścieżce.
Uprość animacje i przejścia. Preferuj transform i opacity, korzystaj z compositor-only animacji, unikaj właściwości powodujących layout czy repaint całych obszarów.

Te kroki przynoszą efekty w różnej skali, ale łączy je jedno: skrócenie czasu do pierwszej widocznej odpowiedzi po geście użytkownika.

W architekturze aplikacji SPA zwróć uwagę na nawigację wewnętrzną. Złożona orkiestracja efektów, subskrypcji i renderów komponentów daje się odchudzić przez lazy-loading tras i komponentów, memoizację oraz dzielenie stanów na lokalne i globalne z myślą o minimalnym drzewie do ponownego przerysowania.

Wreszcie — nie bój się „optymistycznego UI”. Jeśli nadejście odpowiedzi z sieci nie jest krytyczne dla bezpieczeństwa lub spójności, pokaż od razu wynik przewidywany, a ewentualną korektę wprowadź, gdy przyjdą dane. Takie podejście drastycznie poprawia czas do następnej klatki po kliku.

Przykłady, wzorce i antywzorce wpływające na INP

Przykład 1: wielka lista produktów z filtrami. Kliknięcie checkboxa powoduje pełny re-render listy i ponowne obliczenie układu dla setek kart. Rezultat to widoczna zwłoka. Poprawka: wprowadzić warstwę pośrednią z indeksem wyników, zaktualizować jedynie zmienione węzły, a ciężkie sortowanie przenieść do Web Workera. W interfejsie — natychmiast zmienić stan filtra i pokazać mikrofeedback (np. subtelne „zablokowanie” przycisku na 100–150 ms).

Przykład 2: menu rozwijane po kliknięciu w mobilnej nawigacji. W handlerze kliknięcia wykonywane są dodatkowe obliczenia layoutu, a następnie wstrzykiwany jest dynamicznie arkusz CSS. Efekt: opóźnienie w pojawieniu się panelu. Poprawka: załadować styl wcześniej (przy starcie lub leniwie, ale przed spodziewaną interakcją), w obsłudze gestu jedynie dodać klasę inicjującą transition opartą o transform, bez wymuszania reflow.

Przykład 3: formularz z walidacją synchronizowaną. Naciśnięcie „Wyślij” uruchamia weryfikację w całym drzewie pól oraz wysyła żądanie do API, po czym dopiero pokazuje błąd. Wizualna odpowiedź nadchodzi po kilkuset milisekundach. Poprawka: rozdziel walidację na etapy, w pierwszym kadrze pokaż stany błędu dla dostępnych pól, wszystko inne dogrywaj w tle. Przycisk może od razu przejść w stan „processing”, dzięki czemu INP drastycznie się skróci.

Antywzorce:

Blokady w obsłudze zdarzeń: synchroniczne pętle, intensywne parsowanie JSON, kompresja lub konwersje obrazów w głównym wątku.
Wymuszone odczyty layoutu po zapisach: naprzemienne getBoundingClientRect i modyfikacje stylów w tej samej klatce.
Ciężkie animacje właściwości layoutu (width/height/top/left) zamiast transform/opactiy.
Brak feedbacku. Handler wykonuje pracę, ale UI nie zmienia wyglądu do czasu zakończenia operacji — przeglądarka nie maluje nowej klatki.
Używanie globalnych event listenerów wyzwalających kosztowne operacje przy każdym kliknięciu, niezależnie od celu.

Dobrą praktyką jest w każdym z tych miejsc zastosować zasadę „odchudź hot-path” i daj przeglądarce szansę na szybki kadr.

Wzorce:

Natywne zachowania, gdy to możliwe (np. elementy interaktywne HTML), które przeglądarki optymalizują od lat.
Delegacja zdarzeń w ograniczonych, logicznych kontenerach (nie globalnie na dokument), aby uniknąć niepotrzebnego kodu w ścieżce kliku.
Wstępne wyrenderowanie stanu „po interakcji”, a następnie szybka zamiana klasami lub atrybutami, bez kosztownych konstrukcji DOM w gorącej ścieżce.
Planowanie pracy: requestAnimationFrame do aktualizacji wizualnych, setTimeout/IdleCallback do niekrytycznych obliczeń, a Worker do ciężkich operacji.

Te wzorce kumulują się: kilka drobnych optymalizacji potrafi skrócić odczuwane opóźnienie o setki milisekund.

Składniki definicji w ujęciu słownikowym i terminologicznym

Chcąc zapisać pojęcie w słowniku tworzenia stron WWW, należy wyłożyć jego istotę językiem precyzyjnym i sprawdzalnym empirycznie. INP jest metryką oceny reakcji interfejsu, której jednostką jest milisekunda i która obejmuje zarówno kod, jak i procesy renderujące. Na potrzeby dokumentacji warto utrwalić podstawowe elementy definicji:

Punkt startowy: pierwsza rejestracja interakcji przez przeglądarkę (np. moment click lub keydown).
Zakres pomiaru: czas do pierwszego następnego kadru zawierającego jakąkolwiek widoczną odpowiedź na gest użytkownika.
Agregacja: zamiast pojedynczego pomiaru brany jest wysoki percentyl najdłuższych interakcji w trakcie wizyty (typowo P98).
Obszar oddziaływania: logika aplikacji, operacje DOM/CSS oraz cykl malowania i kompozycji.
Interpretacja: ≤ 200 ms — dobry, 200–500 ms — wymaga uwagi, > 500 ms — zły.

Przedmiot metryki jest zatem jednoznaczny: suma wszystkich kroków od bodźca wejściowego do wizualnej odpowiedzi. To podejście wykracza poza wąskie rozumienie „opóźnienia handlera” i odwzorowuje percepcję użytkownika.

Pod względem zastosowań praktycznych INP staje się miarą do postawienia wymogów niefunkcjonalnych w projektach. W kryteriach jakości aplikacji można zapisać: „kluczowe interakcje muszą osiągać INP ≤ 200 ms w 75. percentylu ruchu na urządzeniach mobilnych”. Tak sformułowane wymaganie jest weryfikowalne i prowadzi do konkretnych decyzji architektonicznych, takich jak redukcja objętości skryptów w ścieżce krytycznej, wprowadzenie workerów, czy reorganizacja logiki komponentów.

Na poziomie pojęć warto rozróżnić źródła spowolnień. „Input delay” to część, w której interakcja czeka na rozpoczęcie obsługi, „processing time” obejmuje czas pracy kodu, a „presentation delay” dotyczy etapów kompozycji i malowania. INP scala je w jednej liczbie, co ułatwia nadanie priorytetów: jeśli input delay jest niski, a całość wysoka, trzeba badać warstwę prezentacji; jeśli input delay jest wysoki, główny wątek bywa zajęty przez inne zadania.

FAQ

Co to jest INP w jednym zdaniu? INP to czas od początku interakcji do momentu, gdy użytkownik zobaczy pierwszą widoczną odpowiedź interfejsu w następnym kadrze.
Czym INP różni się od FID? FID mierzył wyłącznie wstępne opóźnienie pierwszej interakcji; INP obejmuje opóźnienie, przetwarzanie i malowanie dla wielu interakcji, lepiej oddając interaktywność.
Jaki wynik jest dobry? Za dobry uznaje się ≤ 200 ms; 200–500 ms wymaga poprawy; powyżej 500 ms jest słaby.
Czy słabe łącze internetowe psuje INP? Pośrednio. Sama sieć nie wchodzi do definicji, ale jeśli UI czeka na odpowiedź, nie pokazując żadnego feedbacku, opóźni się „następny kadr”.
Czy hover lub scroll liczą się do INP? Metryka koncentruje się na podstawowych interakcjach wejściowych (kliknięcia, stuknięcia, klawisze). Scroll może wpływać pośrednio, jeśli wyzwala kosztowne efekty.
Jak mierzyć INP w produkcji? Najprościej włączyć RUM poprzez bibliotekę web-vitals lub PerformanceObserver i wysyłać pomiary do analityki.
Dlaczego INP jest wyższy na mobile? Urządzenia mobilne mają słabsze CPU i często gorsze warunki sieciowe; dodatkowo interfejs dotykowy częściej wyzwala złożone sekwencje zdarzeń.
Jakie pierwsze kroki poprawiają INP? Zapewnij natychmiastowy feedback wizualny po geście, odchudź handlery, podziel długie zadania i usuń wymuszone przebudowy layoutu.
Czy debouncing pomaga? Tak, ale rozważnie. Debounce może redukować lawinę eventów, jednak zbyt agresywny opóźni reakcję. Stosuj go poza krytycznym pierwszym kadrem.
Jak powiązać wynik z przyczyną? Analizuj ślad w DevTools (Performance) — szukaj momentu interakcji, długich zadań, kosztów stylu/układu i czasu do pierwszej kolejnej klatki.
Czy animacje psują INP? Animacje nie muszą szkodzić, jeśli są oparte o transform i opacity i nie blokują kadru po interakcji. Ciężkie animacje layoutu będą pogarszać wynik.
Na jakim procencie ruchu ocenia się INP? Dobrym standardem jest 75. percentyl w danych terenowych, raportowany osobno dla desktopu i urządzeń mobilnych.
Czy można „oszukać” INP? Nie ma sensu. Metryka wyłapuje odczuwalną szybkość. Zamiast maskować, pokaż realny feedback szybko, a kosztowne kroki wykonaj po klatce.
Jak INP ma się do innych Core Web Vitals? Uzupełnia je: LCP dotyczy szybkości pierwszej treści, CLS stabilności układu, a INP — szybkości reakcji UI na gesty.
Jakie narzędzia polecacie? Lighthouse do testów syntetycznych, RUM do danych polowych, PageSpeed Insights do przeglądu, DevTools do profilowania, biblioteka Web Vitals do prostego zbierania wyników.
Czy rozmiar JS jest kluczowy? Duży rozmiar sprzyja długim zadaniom i przeciążeniu głównego wątku, ale liczy się przede wszystkim czas wykonywania i to, co dzieje się w gorącej ścieżce po kliknięciu.
Co z dostępnością? Natychmiastowy feedback (np. wizualny i ARIA-live) poprawia odczucie szybkości dla wszystkich, a metryka będzie to odzwierciedlać.
Jak długo trwa „okno” pomiaru? INP mierzy cały czas trwania wizyty, grupując interakcje i raportując wysoki percentyl najdłuższych.
Czy framework ma znaczenie? Każdy może osiągnąć dobry INP, jeśli dba o budżet czasu w handlerach, dzieli zadania i minimalizuje koszty renderu po interakcji.
Jakie słowa-klucze warto zapamiętać? INP, opóźnienie, zdarzenie, renderowanie — to rdzeń definicji i optymalizacji.