Czym jest wskaźnik Interaction to Next Paint
INP, czyli Interaction to Next Paint (po polsku interakcja do kolejnego wyrenderowania), to wskaźnik z zestawu Core Web Vitals, który mierzy czas od działania odwiedzającego do chwili, gdy przeglądarka pokaże następną klatkę z reakcją. Liczą się 3 rodzaje gestów: kliknięcie myszą, dotknięcie ekranu i naciśnięcie klawisza, a przewijanie i najeżdżanie kursorem nie wchodzą do pomiaru. Wskaźnik ten ocenia całkowitą responsywność strony przez cały czas wizyty, zamiast pojedynczej akcji. Według danych Chrome przytaczanych przez web.dev 90% czasu na stronie przypada na okres po jej załadowaniu, więc reakcje w trakcie korzystania ważą bardzo dużo.
W przeciwieństwie do wcześniejszego First Input Delay (FID), który analizował wyłącznie pierwsze kliknięcie, INP uwzględnia wszystkie interakcje użytkownika z daną podstroną. Ten nowy miernik wszedł do podstawowego zestawu 12 marca 2024 roku i zastąpił FID. Do wyniku trafia najdłuższa zaobserwowana reakcja, przy czym na każde 50 zdarzeń pomijana jest jedna najwyższa wartość, więc na rozbudowanych stronach pojedynczy przypadkowy skok nie przesądza o ocenie, a powtarzalne opóźnienia nadal ją obniżają.
Wpływ INP na doświadczenie użytkownika i SEO
Wskaźnik Interaction to Next Paint bezpośrednio przekłada się na odczucia osoby, która korzysta ze strony. Opóźniona reakcja na przycisk czy rozwinięcie menu sprawia, że gość traci pewność, czy jego ruch został zarejestrowany. Web.dev pokazuje to na przykładzie akordeonu: gdy długie zadania blokują jego otwarcie, człowiek klika wiele razy, a po odblokowaniu panel otwiera się i zamyka w nieoczekiwany sposób. Taka sytuacja może zakończyć się opuszczeniem strony bez realizacji zamierzonego celu.
Optymalizacja INP przynosi wymierne korzyści:
- skrócenie czasu potrzebnego na wykonanie zamierzonej akcji (zakup, wypełnienie formularza, nawigacja),
- płynniejszy proces zakupowy, w którym dodanie produktu do koszyka od razu daje widoczne potwierdzenie, najlepiej w progu dobrego wyniku do 200 ms,
- mniej frustracji i wielokrotnych kliknięć tego samego elementu,
- lepszy wynik w ocenie, którą Google uwzględnia w wyszukiwarce: dokumentacja Search Central podaje, że dobre podstawowe wskaźniki internetowe wraz z innymi aspektami jakości strony starają się nagradzać najważniejsze systemy rankingowe Google,
- przewaga w branżach, gdzie liczy się natychmiastowa odpowiedź interfejsu (e-commerce, portale informacyjne).
Narzędzia do pomiaru Interaction to Next Paint
INP warto mierzyć na podstawie wizyt prawdziwych osób, bo web.dev nazywa taki pomiar najlepszym sposobem oceny tego wskaźnika. Google PageSpeed Insights prezentuje dane z terenu (z raportu CrUX) oraz wyniki testów laboratoryjnych. Chrome User Experience Report podaje zagregowane wrażenia odwiedzających korzystających z Chrome jako średnią kroczącą z ostatnich 28 dni, więc efekt poprawki widać w nim z opóźnieniem.
Narzędzie Lighthouse w Chrome DevTools to test laboratoryjny, a takie testy często obserwują samo wczytywanie strony bez klikania, dlatego w zwykłym teście zamiast INP widzisz całkowity czas blokowania (TBT), który według web.dev bywa rozsądną wartością zastępczą, choć INP w pełni nie zastąpi. Podgląd na żywo daje widok danych na żywo w panelu Wydajność, a pojedynczy wolny gest prześledzisz, nagrywając ślad w tym samym miejscu. Raport "Podstawowe wskaźniki internetowe" (Core Web Vitals) w Search Console dzieli podobne adresy URL na 3 stany, od "Dobrej jakości" do najsłabszego, i pokazuje grupy do naprawy.
Do ciągłego monitorowania warto wdrożyć bibliotekę web-vitals, która przesyła dane o rzeczywistych kliknięciach do systemu analitycznego i zawiera przykładową implementację obliczania INP. Wyniki takiego pomiaru (RUM) wskazują, który konkretny element odpowiada za wynik, czy zdarzenie wystąpiło w trakcie ładowania, czy później, i jakiego było typu, co ułatwia wykrycie problemów na telefonach, w określonych przeglądarkach czy przy wolniejszych połączeniach.
Metody poprawy wskaźnika INP
Lepszy INP osiągniesz, skracając 3 fazy każdej interakcji opisane przez web.dev:
- opóźnienie wejścia: czas, zanim ruszy obsługa zdarzenia,
- czas przetwarzania: wykonanie wywołań zwrotnych,
- opóźnienie prezentacji: okres do wyświetlenia klatki.
Poniżej metody dla poszczególnych etapów.
Redukcja i optymalizacja skryptów JavaScript
Nadmiar kodu JavaScript blokującego główny wątek przeglądarki to częsta przyczyna słabego wyniku INP. Obsługuje on tylko 1 operację naraz, a każdą trwającą ponad 50 ms web.dev nazywa długim zadaniem, więc im dłużej JavaScript zajmuje procesor, tym później użytkownik widzi reakcję.
Podział dużych bloków pracy na mniejsze fragmenty pozwala obsłużyć kliknięcie między następnymi częściami kodu. Funkcja setTimeout() przenosi callback do osobnego taska, ale trafia ono na koniec kolejki, a po 5 zagnieżdżonych wywołaniach Chrome i inne silniki narzucają minimalne opóźnienie 5 ms. Interfejs scheduler.yield() zaprojektowano specjalnie do oddawania sterowania: przerwana praca rusza przed innymi operacjami oczekującymi, a tam, gdzie ta metoda nie działa, web.dev proponuje rozwiązanie zastępcze. Code splitting, czyli dzielenie kodu i wczytanie wyłącznie części niezbędnej dla danej podstrony, zmniejsza ilość JavaScriptu do przeanalizowania i wykonania.
Usunięcie nieużywanych bibliotek i zależności, minimalizacja bundli, leniwe ładowanie komponentów, które nie są widoczne przy pierwszym wyświetleniu: wszystkie te techniki skracają czas blokowania, także podczas startu strony, gdy web.dev wskazuje ocenę skryptów jako jedno ze źródeł długich zadań.
Przyspieszenie odpowiedzi serwera
INP nie mierzy wprost czasu odpowiedzi serwera: web.dev zaznacza, że celem wskaźnika nie jest pomiar wszystkich ostatecznych efektów interakcji, takich jak pobieranie z sieci, tylko okresu blokowania kolejnego wyrenderowania. Wolne zapytania API opóźniają jednak moment, w którym klient widzi wynik, więc przy dłuższych operacjach ekran powinien od razu pokazać wstępną informację wizualną (np. stan ładowania przycisku), a dopiero potem treść. Optymalizacja kwerend do bazy przez dodanie indeksów, denormalizację często odczytywanych tabel i cache na poziomie aplikacji skraca czas przetwarzania żądań.
Content Delivery Network (CDN) redukuje opóźnienia sieciowe dla osób oddalonych geograficznie od hostingu. Kompresja (gzip, Brotli) zmniejsza ilość przesyłanych bajtów. HTTP/2 i HTTP/3 umożliwiają równoległy transfer wielu zasobów przez jedno połączenie.
Usprawnienie procesu renderowania
Po obsłużeniu zdarzenia przeglądarka musi zaktualizować wyświetlany widok i ten etap web.dev nazywa opóźnieniem prezentacji. Thrashing (wymuszony synchroniczny layout) powstaje, gdy kod zmienia style, a potem odczytuje je w tym samym zadaniu; rezygnacja z takich operacji zapobiega wielokrotnym przebudowom drzewa renderowania.
Ograniczenie rozmiaru DOM przez uproszczenie struktury HTML skraca przeliczanie stylów i geometrii elementów: według web.dev Lighthouse uznaje DOM za nadmierny powyżej 1400 węzłów, a ostrzega już od 800. Animacje oparte na właściwościach CSS transform i opacity zamiast top, left czy width nie wymuszają ponownego układania strony przy każdej klatce.
Web Workers pozwalają przenieść obliczenia do osobnego wątku, dzięki czemu ten główny zostaje wolny dla kliknięć. Właściwość content-visibility: auto pomija rysowanie elementów poza ekranem: w artykule demonstracyjnym web.dev przyspieszyła renderowanie przy początkowym wczytaniu 7 razy.
Optymalizacja bibliotek i frameworków
Frameworki JavaScript (React, Vue, Angular) dodają warstwę abstrakcji, która może wydłużać czas przetwarzania interakcji. Nadmierne ponowne rysowanie komponentów po każdej zmianie stanu, brak zapamiętywania wyników kosztownych obliczeń czy listy generowane bez kluczy to typowe źródła długich zadań po kliknięciu.
Narzędzia profilujące (React DevTools Profiler, Vue Devtools) oraz panel Wydajność w Chrome DevTools pozwalają znaleźć komponenty, których aktualizacja przekracza próg 50 ms. Przejście na nowszą wersję biblioteki planuj po pomiarze, porównując INP przed zmianą i po niej.
Progi wartości INP według Google
Google definiuje 3 przedziały wartości wskaźnika Interaction to Next Paint. Wynik do 200 ms włącznie oznacza, że strona dobrze reaguje. Zakres od ponad 200 do 500 ms wymaga poprawy, a pomiar powyżej 500 ms to słaba responsywność.
Ocena w Search Console i PageSpeed Insights bazuje na 75. percentylu wczytań strony, liczonym osobno dla telefonów i komputerów: co najmniej trzy czwarte wizyt musi mieścić się w progu "dobry", aby cały adres dostał taką kategorię. Przykład: jeśli 26% sesji przekracza 500 ms, wartość dla tego centyla również wypada wyżej, więc URL trafia do grupy "Słabej jakości", a nie do "Wymagana poprawa".
Typowe przyczyny wysokiego INP
Długie zadania JavaScript blokujące główny wątek przez ponad 50 ms to najczęstszy winowajca. Ocena skryptów przy wczytywaniu, przetwarzanie danych, inicjalizacja widgetów zewnętrznych: wszystko to konkuruje o czas procesora z obsługą działań odwiedzającego.
Opóźnienie wejścia rośnie, gdy w chwili kliknięcia przeglądarka jest zajęta: web.dev wymienia wczytywanie, analizowanie i kompilowanie skryptów, obsługę pobierania, funkcje czasowe i nakładające się zdarzenia. Ciężki kod podpięty pod ruch myszy czy scroll, uruchamiany bez debouncingu lub throttlingu, zajmuje procesor nawet wtedy, gdy samo przewijanie nie wchodzi do pomiaru INP. Złożone selektory CSS i głębokie zagnieżdżenie elementów wydłużają przeliczanie stylów po akcji.
Duże aktualizacje DOM po każdym kliknięciu wydłużają opóźnienie prezentacji, bo koszt rysowania rośnie razem z rozmiarem drzewa. Skrypty śledzące (analytics, reklamy, czat) często wykonują ciężkie operacje w odpowiedzi na ruch odwiedzającego, a gesty w ramkach iframe, np. start osadzonego filmu, także liczą się do INP strony.
Strategie testowania i monitorowania
Regularne sprawdzanie wydajności na prawdziwych telefonach ujawnia problemy niewidoczne na mocnych komputerach deweloperskich. Symulacja wolniejszego procesora i sieci w narzędziach laboratoryjnych pomaga odtworzyć warunki słabszych urządzeń, choć web.dev przypomina, że to tylko wycinek realnych sytuacji.
Wdrożenie Real User Monitoring (RUM) dostarcza informacji o faktycznych doświadczeniach gości z różnych lokalizacji, sprzętu i łączy. Segmentacja według typu urządzenia, przeglądarki, kraju czy połączenia pozwala znaleźć grupy najbardziej dotknięte problemami z responsywnością, a web.dev radzi zaczynać optymalizację od pomiarów z terenu (w CrUX z okna 28 dni) i dopiero potem odtwarzać wolne interakcje w laboratorium.
Testy A/B różnych implementacji funkcji mogą wykazać, które rozwiązanie daje lepszy INP bez szkody dla wygody korzystania. Lighthouse web.dev zaleca uruchamiać w środowiskach programistycznych i w ciągłej integracji, żeby wyłapać kłopoty z wydajnością, zanim trafią na produkcję.
Równowaga między funkcjonalnością a wydajnością
Optymalizacja INP nie może odbywać się kosztem użyteczności strony. Usunięcie wszystkich interaktywnych elementów poprawiłoby wskaźnik, ale zrujnowałoby doświadczenie odwiedzających. Decyduje hierarchia: akcje prowadzące do celu (dodanie produktu do koszyka, przesłanie formularza, nawigacja) usprawniasz w pierwszej kolejności, celując w 200 ms dla każdej z nich.
Progressive enhancement, czyli budowanie podstawowej funkcjonalności działającej nawet bez JavaScriptu i dodawanie udoskonaleń później, sprawia, że strona pozostaje użyteczna, gdy wykonanie skryptów się opóźnia. Web.dev podkreśla, że przy złożonych operacjach liczy się szybka wstępna informacja wizualna, która mówi klientowi, że coś się dzieje: stan ładowania, szkielet treści albo optymistyczna aktualizacja interfejsu poprawiają odczuwaną responsywność, także gdy właściwe przetwarzanie trwa dłużej.
