Interaction to Next Paint – czym jest INP i jak go poprawić?

Interaction to next paint (INP) – co to jest?

Interaction to Next Paint (INP) to najnowszy wskaźnik z rodziny Google Core Web Vitals, który pomaga ocenić szybkość reakcji strony na interakcje użytkownika. Jego nazwę na język polski tłumaczy się jako: Interakcja do Kolejnego Wyrenderowania. 

Co mierzy INP?

INP mierzy czas od momentu działania użytkownika (np. kliknięcia, tapnięcia lub naciśnięcia klawisza) do chwili, gdy strona wyświetli kolejną ramkę z wizualną odpowiedzią na tę interakcję [2]. Wskaźnik ten pozwala ocenić wydajność interakcji użytkownika z witryną i jej ogólną responsywność w trakcie całej wizyty, nie tylko przy pierwszym działaniu, jak to było w przypadku FID [3]. 

Istotną cechą INP jest to, że uwzględnia on wszystkie interakcje podczas wizyty użytkownika na danej podstronie, a wynik końcowy INP to czas najwolniejszej zarejestrowanej interakcji (pomijając ewentualne skrajne wyjątki) [2]. 

Google Core Web Vitals: INP

INP, jako wskaźnik CWV, wprowadzony został jako zamiennik First Input Delay (FID) w marcu 2024 roku [1]. Od tej pory stał się jednym z najważniejszych sygnałów jakości strony, branych pod uwagę m.in. w raporcie Page Experience oraz (pośrednio) w algorytmach rankingu wyszukiwarki – to ma ogromny wpływ na SEO. Google Search Console od 2024 roku pokazuje INP w raporcie Core Web Vitals (zamiast FID) i pozwala monitorować, czy strony mieszczą się w zalecanych wartościach [1]. 

Jakie wartości powinien przyjmować poprawny wskaźnik INP?

Według zaleceń Google, aby zapewnić dobrą wydajność interakcji użytkownika, należy dążyć do tego, by INP nie przekraczał 200 ms (mierzony na 75. percentyli ładowań strony, osobno dla urządzeń mobilnych i desktop) [2]. 

Przy wartościach INP od 200 do 500 ms strona „wymaga poprawy”, natomiast powyżej 500 ms uznawana jest za wolno reagującą (ocena „poor”) [2]. Innymi słowy, INP poniżej 200 ms oznacza dobrą responsywność, a powyżej 500 ms – poważne problemy, które wymagają działania!

Czynniki wpływające na INP

Wysoka wartość INP oznacza mniej więcej tyle, że użytkownik musi zbyt długo czekać na reakcję strony po wykonaniu akcji. Co sprawia, że strona tak długo się ładuje?

Długie zadania JavaScript (Long Tasks)

Przeglądarka wykonuje większość prac (renderowanie, parsowanie HTML, obsługa skryptów itp.) w głównym wątku. Niestety wątek główny może wykonywać jedynie jedno zadanie naraz. Jeśli pojedyncze zadanie trwa zbyt długo (przyjęto, że ponad 50 ms kwalifikuje się już jako long task), blokuje ono wątek główny [4].  W efekcie przeglądarka nie może równocześnie obsłużyć zdarzenia interakcji – kliknięcie czy wpisanie tekstu, musi czekać, aż skończy się trwające zadanie. Długie, blokujące skrypty (np. ciężkie biblioteki, duże fragmenty kodu wykonywane synchronicznie) są zatem jedną z głównych przyczyn podnoszenia wartości INP.

Zbyt duży i złożony DOM

Objętość DOM (liczba elementów HTML na stronie) wpływa na to, jak szybko przeglądarka jest w stanie przeparsować i wyrenderować stronę oraz reagować na zmiany. Nadmiernie rozbudowany DOM spowalnia zarówno początkowe ładowanie strony, jak i późniejsze modyfikacje w interfejsie podczas interakcji [4].

Zaleca się utrzymywać DOM w rozsądnych rozmiarach (Google Lighthouse wskazuje przekroczenie ok. 1400 węzłów jako za duży DOM).

Ciężkie renderowanie po stronie klienta (SPA)

Strony typu SPA (Single Page Application), które w dużej mierze generują zawartość i interfejs poprzez JavaScript w przeglądarce, mogą negatywnie wpływać na INP [4]. Tradycyjnie serwer dostarcza HTML w porcjach (chunks) – dzięki temu strona może być renderowana stopniowo. W przypadku SPA przeglądarka musi przetworzyć dużą ilość kodu JS, by wygenerować interfejs – to oznacza długie nieprzerwane zadania na wątku głównym. Innymi słowy, intensywne renderowanie po stronie klienta (bez wsparcia serwera) sprzyja długim zadaniom i słabszym wynikom INP.

Obciążające zasoby i blokujące procesy

Oprócz samego kodu strony, wpływ na INP mogą mieć także zasoby zewnętrzne i wszelkie procesy blokujące interfejs. Na przykład ciężkie skrypty firm trzecich (np. trackery, rozbudowane widgety) mogą wykonywać się w tle, zużywając czas CPU i blokując reakcje na interakcje użytkownika [3]. 

Podobnie skomplikowane style CSS lub fonty mogą opóźniać renderowanie zmian wizualnych. Nawet działania użytkownika wykonywane w bardzo szybkim ciągu mogą się „kumulować” – jeśli ktoś szybko klika lub pisze, a strona nie nadąża z obsługą poprzednich zdarzeń, to kolejne interakcje będą opóźnione. 

Jak poprawić Interaction to Next Paint?

Przede wszystkim poprawa wskaźnika INP sprowadza się do usprawnienia czasu reakcji strony. Chodzi o to, aby tak napisać stronę, żeby każda interakcja użytkownika była obsłużona możliwie szybko i płynnie.

Jakie są metody optymalizacji czasu reakcji strony?

• Dziel i skracaj długie zadania – unikaj wykonywania bardzo dużych partii JavaScriptu w jednym bloku i w miarę możliwości dziel długotrwałe operacje na mniejsze fragmenty. Rozbicie jednego dużego zadania na kilka mniejszych daje wątkowi głównemu „oddech”. Dzięki temu przeglądarka będzie mogła renderować aktualizacje i reagować na zdarzenia użytkownika szybciej.  
• Optymalizuj skrypty i eliminuj zbędną pracę – przeanalizuj, gdzie Twój kod zużywa najwięcej czasu CPU i usprawnij te miejsca. Upewnij się, że obsługa zdarzeń jest możliwie lekka – każda funkcja wywoływana po kliknięciu czy wciśnięciu klawisza powinna wykonywać tylko konieczne operacje. Usuń zbędne fragmenty kodu z tych callbacków lub odłóż ich wykonanie na później, o ile nie są krytyczne dla natychmiastowej odpowiedzi.
• Minimalizuj nakładające się interakcje – gdy użytkownicy wykonują wiele akcji szybko po sobie (np. intensywne pisanie w polu tekstowym, wielokrotne kliknięcia), może dojść do sytuacji, że kolejna interakcja następuje, zanim poprzednia zdążyła wywołać efekt. To zjawisko interaction overlap pogarsza odczucie płynności. [4] Aby temu zapobiec, stosuj mechanizmy debounce. [4] 
• Odciążaj wątek główny – wszystko, co da się zrobić poza wątkiem głównym, pomoże w utrzymaniu niskiego INP. Jeśli masz ciężkie obliczenia lub długi skrypt do wykonania, rozważ użycie Web Workers do przeniesienia tych zadań do osobnych wątków. Web Worker pozwala przeglądarce przetwarzać skomplikowane obliczenia w tle, podczas gdy główny wątek nadal może obsługiwać interfejs i interakcje użytkownika. [3]
• Zapewnij szybką informację zwrotną w interfejsie – użytkownik lubi widzieć, że strona natychmiast po interakcji pokazuje, że „coś się dzieje”. Nawet jeśli pełne wykonanie akcji zajmie więcej czasu (np. zapis do bazy, generowanie wyników), powinno się jak najszybciej wyrenderować pierwszą reakcję – np. podświetlenie przycisku, wyświetlenie spinnera ładowania, otwarcie pustego kontenera na treść, itp. Dzięki temu użytkownik widzi od razu efekt (ramka z aktualizacją UI pojawia się szybko), a INP pozostaje niski, bo pierwszy następny paint nastąpił niezwłocznie. [2]
• Zoptymalizuj ładowanie i wielkość zasobów – ciężkie pliki i blokujące zasoby mogą wydłużać czas reakcji strony, zwłaszcza jeśli interakcja nastąpi w trakcie ich wczytywania. Dlatego odchudzaj i odraczaj ładowanie tego, co nie jest natychmiast potrzebne. Przeanalizuj m.in. third-party scripts, bo jeśli powodują duże opóźnienia, może trzeba je ograniczyć lub ładować tylko w razie konieczności. Chodzi o to, aby nie dochodziło do sytuacji, że „walczą” o wątek główny z interakcją użytkownika. 
• Uprość i przyspiesz renderowanie kolejnych klatek – zadbaj o to, żeby przeglądarka miała jak najmniej pracy przed wyświetleniem następnej ramki. Oprócz wspomnianego ograniczenia rozmiaru DOM zwróć uwagę na kod wykonujący się tuż przed renderowaniem (paint). Jeśli umieścisz tam ciężkie operacje (niezwiązane bezpośrednio z renderowaniem), to opóźnisz wyrenderowanie kolejnej klatki [4]. Staraj się również unikać wymuszania wielu layoutów w krótkim czasie (np. poprzez wielokrotne zmiany stylów prowadzące do ciągłego przeliczania układu strony). Jeśli zauważysz, że jakaś interakcja powoduje liczne przebudowy layoutu albo migotanie układu, spróbuj zoptymalizować tę część.

Narzędzia do pomiaru INP

Pomiar i śledzenie INP możesz wykonać za pomocą narzędzi dostarczanych przez Google. 

Narzędzie PageSpeed Insights korzysta z danych Chrome User Experience Report (CrUX) i obecnie udostępnia metrykę INP dla analizowanej strony (zarówno na poziomie URL, jak i całej domeny) [5]. Wystarczy wpisać adres strony w PSI – w sekcji „Field Data” pojawi się Interaction to Next Paint z wynikiem i kwalifikacją (Good / Needs Improvement / Poor). PSI prezentuje dane z ostatnich 28 dni rzeczywistych wizyt użytkowników, więc jest dobrym punktem wyjścia do oceny, jak wypada INP w warunkach rzeczywistych. Gdy strona ma zbyt mały ruch, by INP był raportowany, PSI może nie pokazać tej metryki – wtedy warto posiłkować się testami laboratoryjnymi.

Kolejnym narzędziem, które pokaże Ci jakość INP jest Google Search Console. Raport Core Web Vitals od 2024 roku uwzględnia tam INP jako metrykę responsywności. Możesz tu monitorować, jaki odsetek odsłon strony mieści się w kategoriach „Good” (poniżej 200ms) i „Poor” (powyżej 500ms) dla INP. SC grupuje wyniki na poziomie całej witryny (dla mobilnych i desktopów osobno) i pozwala zidentyfikować problemy z responsywnością w ujęciu globalnym. Jeśli Search Console wskazuje, że INP wymaga poprawy na części stron, warto skupić optymalizacje właśnie tam w pierwszej kolejności.

Najbardziej precyzyjny wgląd w INP można uzyskać, zbierając dane od prawdziwych użytkowników (Real User Monitoring). Google udostępnia bibliotekę web-vitals.js, która obsługuje pomiar INP – można ją zaimplementować w kodzie strony i wysyłać wyniki do własnej analityki [5].

Możesz także zainstalować rozszerzenie Web Vitals do przeglądarki Chrome – pozwala ono na bieżąco podglądać wartości INP dla otwieranej strony (zarówno lokalnie mierzone, jak i pobrane z CrUX, jeśli są dostępne). 

Zewnętrzni dostawcy RUM (np. SpeedCurve, New Relic, Akamai mPulse i inne) również wprowadzili wsparcie dla INP – jeśli korzystasz z takich narzędzi, sprawdź, czy raportują one tę metrykę. 

Warto też wiedzieć, że choć INP jest metryką opartą na danych polowych, istnieją sposoby, by przetestować ją w środowisku laboratoryjnym. Lighthouse (od wersji 10) w trybie „Timespan” lub za pomocą tzw. user flows potrafi zmierzyć INP. Polega to na tym, że uruchamiasz test, a następnie wykonuje się ręcznie (lub skryptem) określone interakcje na stronie, a Lighthouse raportuje czasy tych interakcji [5]. W ten sposób można w kontrolowanych warunkach prześledzić, jak strona reaguje na typowe scenariusze użytkownika. 

Chcesz sprawdzić, jak Twoja strona wypada w testach CWV? Przeprowadź szczegółowy audyt SEO.

Interaction to Next Paint – podsumowanie

Interaction to Next Paint pokazuje, jak szybko strona reaguje na działania użytkownika. Jeśli wynik jest zbyt wysoki, oznacza to, że trzeba usprawnić kod, skrócić długie zadania i ograniczyć ciężkie zasoby. Regularnie wykonuj testy CWV, aby Twoja strona była przyjazna dla użytkownika i dobrze pozycjonowała się w wynikach wyszukiwania. 

Źródła:

[1] developers.google.com

[2] web.dev

[3] www.publift.com

[4] nitropack.io

[5] developer.chrome.com