INP: co oznacza Interaction to Next Paint w sklepie

INP w sklepie: co dokładnie mierzy ta metryka

INP, czyli Interaction to Next Paint, jest metryką opisującą responsywność strony. W praktyce odpowiada na konkretne pytanie: jak długo użytkownik czeka od wykonania interakcji do momentu, w którym przeglądarka może wyświetlić jej efekt.

To odróżnia INP od metryk związanych przede wszystkim z ładowaniem strony. Sklep może szybko wyświetlić pierwszą zawartość, a jednocześnie reagować z opóźnieniem na kliknięcia. Przykładem jest karta produktu, która otwiera się szybko, ale po wyborze wariantu przez chwilę nie zmienia ceny, zdjęcia lub dostępności. Podobnie może zachowywać się filtr produktów, menu mobilne, wyszukiwarka, koszyk albo formularz.

INP obserwuje interakcje wykonywane podczas całego czasu korzystania ze strony. Nie ogranicza się więc do pierwszego działania użytkownika. Metryka bierze pod uwagę opóźnienia związane z interakcjami i na tej podstawie przedstawia wartość opisującą responsywność strony.

Jeżeli szukasz odpowiedzi na pytanie, co to jest INP, najprościej potraktować ją jako pomiar drogi od działania użytkownika do kolejnego możliwego wyświetlenia zmiany na ekranie. Im dłużej przeglądarka pozostaje zajęta, tym wyższa wartość INP.

Dla sklepu ma to znaczenie przede wszystkim tam, gdzie użytkownik wykonuje wiele działań bez przechodzenia na kolejną stronę. Nowoczesny sklep korzysta z JavaScriptu do filtrowania produktów, obsługi wariantów, aktualizacji koszyka, autouzupełniania wyszukiwarki czy otwierania elementów interfejsu. Każdy taki mechanizm może powodować pracę głównego wątku przeglądarki.

Jeżeli chcesz uporządkować wszystkie podstawowe metryki, zacznij od Core Web Vitals w sklepie internetowym, a następnie przejdź do szczegółowej analizy INP.

Jak działa INP podczas interakcji użytkownika

Aby zrozumieć INP, trzeba rozdzielić samo kliknięcie od tego, co dzieje się później. Kliknięcie nie oznacza jeszcze, że przeglądarka natychmiast pokaże efekt. Pomiędzy działaniem użytkownika a kolejnym renderowaniem może wystąpić kilka etapów pracy przeglądarki.

Wyobraź sobie kliknięcie przycisku „Dodaj do koszyka”. Użytkownik wykonuje działanie, przeglądarka rejestruje zdarzenie, JavaScript uruchamia odpowiednią logikę, kod może wykonać obliczenia i zmienić DOM, następnie przeglądarka musi przygotować zmianę do wyświetlenia. Dopiero wtedy użytkownik widzi efekt, na przykład zmienioną liczbę produktów w koszyku albo komunikat potwierdzający dodanie produktu.

INP opisuje czas związany z tą reakcją. Według dokumentacji web.dev interakcja może obejmować grupę zdarzeń wynikających z jednego działania użytkownika. Na urządzeniu dotykowym pojedyncze stuknięcie może wygenerować kilka powiązanych zdarzeń. Metryka analizuje ich przebieg jako część jednej interakcji.

W praktyce można wyróżnić trzy części, które pomagają znaleźć źródło problemu:

1. Input delay, czyli opóźnienie wejściowe. Użytkownik wykonał działanie, ale przeglądarka nie może jeszcze rozpocząć jego obsługi, ponieważ główny wątek wykonuje inną pracę.
2. Processing duration, czyli czas przetwarzania. Uruchomione procedury obsługi zdarzenia potrzebują czasu na wykonanie kodu JavaScript i związanych z nim operacji.
3. Presentation delay, czyli opóźnienie prezentacji. Kod zakończył swoją pracę, ale przeglądarka potrzebuje jeszcze czasu, aby przygotować i wyświetlić efekt interakcji.

Taki podział jest szczególnie przydatny podczas diagnostyki. Wysoki INP nie mówi sam w sobie, że problem znajduje się w jednym konkretnym skrypcie. Trzeba sprawdzić, która część interakcji zajmuje najwięcej czasu.

Przykładowo, jeżeli użytkownik klika filtr kategorii, a przeglądarka przez dłuższy czas wykonuje inne zadania JavaScript, problem może leżeć w input delay. Jeżeli kliknięcie uruchamia ciężką funkcję, przyczyną może być processing duration. Jeżeli kod kończy pracę, ale przeglądarka długo przygotowuje zmianę układu, trzeba sprawdzić presentation delay.

Co oznacza INP na stronie sklepu

Jeżeli zastanawiasz się, co oznacza INP na stronie, nie interpretuj go jako zwykłego czasu ładowania. INP dotyczy reakcji strony na działania użytkownika już podczas korzystania z niej.

To ważne w sklepie internetowym, ponieważ wiele elementów sprzedażowych działa interaktywnie. Użytkownik wybiera rozmiar, kolor, wariant produktu, rozwija informacje, zmienia liczbę sztuk, korzysta z filtrów, wpisuje zapytanie w wyszukiwarce i przechodzi przez koszyk. Każde z tych działań może uruchomić kod po stronie przeglądarki.

Problemu nie zawsze widać podczas zwykłego przeglądania strony. Na szybkim komputerze kliknięcie może wydawać się natychmiastowe, podczas gdy na słabszym urządzeniu ta sama operacja powoduje wyraźne oczekiwanie. Dlatego INP trzeba analizować jako metrykę doświadczenia użytkownika, a nie wyłącznie jako parametr serwera.

Przyczyną słabej responsywności może być między innymi duża ilość JavaScriptu, długie zadania wykonywane na głównym wątku, rozbudowane skrypty zewnętrzne, duży DOM, skomplikowane aktualizacje interfejsu lub operacje wymuszające ponowne obliczenie stylów i układu.

W sklepie WooCommerce problem może pojawić się po połączeniu wielu rozszerzeń odpowiadających za warianty, filtry, analitykę, rekomendacje, popupy, czaty czy marketing. W PrestaShop podobny efekt może powodować duża liczba modułów JavaScript uruchamianych na stronie produktu, kategorii lub koszyka.

Nie oznacza to, że każdy dodatkowy skrypt automatycznie pogarsza INP. Trzeba sprawdzić, co dokładnie wykonuje się w momencie konkretnej interakcji. Przy diagnozie nie wystarczy więc usunąć losowych elementów albo wyłączyć połowy funkcji sklepu.

Jeżeli sklep działa na WooCommerce, pomocne będzie również przejrzenie najczęstszych przyczyn spowalniania WooCommerce, ponieważ część problemów z responsywnością wynika z kodu ładowanego przez dodatki i motyw.

Elementy składające się na INP i ich znaczenie

Element	Co oznacza	Co sprawdzić w sklepie
Input delay	Czas od interakcji do rozpoczęcia jej obsługi	Inne zadania JavaScript blokujące główny wątek
Processing duration	Czas wykonywania obsługi interakcji	Event listenery, funkcje JavaScript, aktualizacje DOM
Presentation delay	Czas od zakończenia obsługi do kolejnego renderowania	Style, layout, rendering i zmiany widoczne na ekranie
INP	Wynik opisujący responsywność interakcji podczas wizyty	Najwolniejsze interakcje i ich rzeczywiste przyczyny

Tabela pomaga oddzielić problem od jego objawu. Wysokie INP jest sygnałem, że reakcja strony trwa zbyt długo, ale dopiero analiza poszczególnych etapów pokazuje, gdzie szukać przyczyny.

W dokumentacji Chrome narzędzie Performance może przedstawić rozbicie INP na te trzy fazy. To praktyczniejsze niż patrzenie wyłącznie na jedną liczbę, ponieważ pozwala powiązać opóźnienie z konkretnym fragmentem pracy przeglądarki.

Warto również zwrócić uwagę na DOM. Rozbudowana struktura HTML może zwiększać koszt obliczania stylów i układu po interakcji. Nie oznacza to, że sam rozmiar DOM jest bezpośrednią przyczyną każdego problemu z INP, ale przy analizie warto sprawdzić, czy kliknięcie nie powoduje dużej liczby zmian w interfejsie.

Jak sprawdzić INP sklepu

Jeżeli chcesz wiedzieć, jak sprawdzić INP sklepu, zacznij od danych rzeczywistych, a później przejdź do testów diagnostycznych.

Pierwszym miejscem jest PageSpeed Insights. Raport może pokazywać dane pochodzące z Chrome User Experience Report, czyli CrUX. Takie dane opisują doświadczenia rzeczywistych użytkowników, a nie pojedynczego komputera użytego do testu.

Drugim źródłem jest raport Core Web Vitals w Google Search Console. Pozwala on zobaczyć problemy dotyczące grup adresów i sprawdzić, czy określone typy stron sklepu mają podobny problem z responsywnością.

Dane laboratoryjne są przydatne do znalezienia przyczyny. W Chrome DevTools można nagrać działanie strony w panelu Performance i wykonać konkretne interakcje. Nie wystarczy jednak uruchomić strony i patrzeć na wykres. Trzeba świadomie odtworzyć działania, które wykonuje użytkownik.

Dla sklepu przygotuj osobny zestaw testów. Na stronie produktu kliknij zmianę wariantu, zmień liczbę produktów i dodaj produkt do koszyka. Na stronie kategorii otwórz filtr, zaznacz kilka parametrów i przełącz sortowanie. Wyszukiwarkę sprawdź podczas wpisywania zapytania. W koszyku zmień ilość produktu i usuń pozycję.

Następnie sprawdź, co dzieje się na głównym wątku. Szukaj długich zadań, dużych bloków JavaScriptu, operacji związanych z layoutem oraz kodu uruchamianego bezpośrednio po interakcji.

Nie traktuj pojedynczego wyniku laboratoryjnego jako pełnego obrazu sytuacji. Warunki urządzenia, przeglądarki, sieci i wykonania testu mogą być inne niż u klientów. Dane terenowe i testy laboratoryjne odpowiadają na różne pytania i dobrze jest korzystać z obu.

Jeżeli problem dotyczy konkretnej platformy, możesz też sprawdzić co spowalnia PrestaShop i Shoper, szczególnie gdy wysoki INP pojawia się na stronach z dużą liczbą modułów lub funkcji interaktywnych.

Jak interpretować wynik INP

Google wskazuje obecnie wartość poniżej 200 ms jako poziom dobry. Przedział od 200 ms do 500 ms oznacza potrzebę poprawy, natomiast wartości powyżej 500 ms są klasyfikowane jako słabe. Te progi pomagają ocenić wynik, ale nie zastępują analizy konkretnej interakcji.

W przypadku sklepu nie patrz wyłącznie na stronę główną. Sprawdź przede wszystkim adresy, na których użytkownik wykonuje działania potrzebne do zakupu. Strona produktu, lista produktów, wyszukiwarka, koszyk i checkout mogą mieć zupełnie inną charakterystykę interakcji.

INP jest też metryką, która zastąpiła First Input Delay w Core Web Vitals. FID skupiał się na opóźnieniu pierwszego wejścia użytkownika, natomiast INP szerzej ocenia responsywność interakcji w czasie korzystania ze strony. Dla sklepu jest to istotna różnica, ponieważ użytkownik może wykonać wiele działań po pierwszym kliknięciu.

Nie próbuj poprawiać wyniku poprzez przypadkowe wyłączanie funkcji. Najpierw ustal, która interakcja jest problematyczna, a następnie sprawdź jej input delay, processing duration i presentation delay. Dopiero wtedy wybierz sposób optymalizacji.

Jeżeli analiza pokazuje długie zadania JavaScript, sprawdź, które skrypty są ich źródłem. Jeżeli problem pojawia się podczas aktualizacji interfejsu, sprawdź zakres zmian DOM i koszt przeliczenia stylów oraz układu. Jeżeli opóźnienie powstaje przed rozpoczęciem obsługi kliknięcia, szukaj pracy wykonywanej wcześniej na głównym wątku.

Pomocne może być również porównanie wyników dla różnych urządzeń. Sklep, który działa sprawnie na komputerze dewelopera, może zachowywać się inaczej na słabszym smartfonie. Właśnie dlatego dane terenowe są tak istotne przy ocenie Core Web Vitals.

INP a pozostałe Core Web Vitals

INP jest jednym z Core Web Vitals, ale nie opisuje tego samego co LCP i CLS. LCP dotyczy szybkości wyświetlenia głównej zawartości strony, INP opisuje responsywność, a CLS mierzy stabilność wizualną.

W praktyce sklep może mieć dobry LCP i jednocześnie słaby INP. Strona może więc szybko pokazać główną fotografię produktu, ale reagować z opóźnieniem na wybór wariantu. Może też mieć dobry INP, ale problemy z CLS, jeżeli elementy strony przesuwają się podczas ładowania.

Dlatego podczas audytu nie należy sprowadzać szybkości sklepu do jednego wyniku z PageSpeed Insights. Poszczególne metryki opisują inne etapy korzystania ze strony.

Jeżeli chcesz spojrzeć szerzej na zachowanie sklepu, przydatne będzie także sprawdzenie szybkości ładowania sklepu i jej przyczyn. INP powinien być analizowany razem z pozostałymi elementami wydajności, ale bez mieszania ich znaczenia.

Co zrobić, gdy INP jest za wysokie

Zacznij od wskazania konkretnej interakcji. Nie optymalizuj całego sklepu w ciemno. Jeżeli problem pojawia się przy filtrze, analizuj filtr. Jeżeli występuje po kliknięciu „Dodaj do koszyka”, analizuj kod uruchamiany przez ten przycisk.

Następnie sprawdź trzy fazy INP. Przy wysokim input delay szukaj pracy blokującej główny wątek przed obsługą interakcji. Przy wysokim processing duration sprawdź kod event handlerów i funkcje wykonywane po kliknięciu. Przy wysokim presentation delay przeanalizuj zmiany DOM, style, layout i rendering.

Kolejny krok to identyfikacja źródła kodu. W sklepie może być to motyw, moduł, wtyczka, biblioteka JavaScript albo skrypt zewnętrzny. Nie zakładaj z góry, że problem powoduje platforma. Najpierw sprawdź ślad wykonania.

W praktyce często trzeba też ograniczyć pracę wykonywaną jednocześnie. Długie zadania można analizować pod kątem podziału pracy na mniejsze fragmenty, ograniczenia niepotrzebnych obliczeń albo przesunięcia części operacji poza moment krytycznej interakcji. Sposób naprawy zależy jednak od konkretnego kodu.

Przydatne są także testy po każdej zmianie. Jeżeli zmienisz jeden moduł, ponownie wykonaj tę samą interakcję i porównaj ślad w DevTools. Dzięki temu możesz ustalić, czy zmiana faktycznie wpłynęła na etap, który wcześniej powodował opóźnienie.

W sklepie produkcyjnym nie pomijaj testu rzeczywistych scenariuszy zakupowych. Czasem strona produktu działa poprawnie przy prostym kliknięciu, ale problem pojawia się dopiero po wybraniu wariantu, aktualizacji ceny i zmianie ilości produktu. To właśnie takie kombinacje działań mogą ujawnić problem, którego nie widać przy pobieżnym teście.

Jeżeli potrzebujesz przejścia przez cały proces diagnostyczny, audyt szybkości sklepu internetowego może objąć sprawdzenie rzeczywistych punktów opóźnień i wskazanie elementów wymagających dalszej analizy.

INP w praktyce właściciela sklepu

Dla właściciela sklepu INP nie powinien być kolejną liczbą do sprawdzania bez kontekstu. Traktuj go jako sygnał dotyczący tego, czy interfejs odpowiada na działania klienta w przewidywalny sposób.

Najprostszy sposób pracy to zacząć od raportu danych rzeczywistych, znaleźć problematyczne grupy stron, a później odtworzyć najważniejsze interakcje w narzędziach deweloperskich. Następnie rozbij opóźnienie na input delay, processing duration i presentation delay.

Dopiero taki wynik daje podstawę do decyzji technicznej. Jeżeli źródłem jest konkretny skrypt, analizujesz skrypt. Jeżeli problem powoduje sposób aktualizacji interfejsu, analizujesz DOM i rendering. Jeżeli główny wątek jest zajęty jeszcze przed kliknięciem, szukasz wcześniejszych zadań blokujących obsługę.

INP nie mówi, który moduł masz usunąć ani jaki plugin zainstalować. Pokazuje efekt końcowy z punktu widzenia responsywności. Rolą audytu technicznego jest połączenie tego efektu z konkretnym kodem i scenariuszem użytkownika.

Dla sklepu internetowego oznacza to prostą zasadę pracy: nie zgaduj, co spowalnia interakcję. Zmierz ją, odtwórz, sprawdź jej fazy i dopiero potem zmieniaj kod. Takie podejście pozwala oddzielić rzeczywisty problem z responsywnością od zwykłego wrażenia, że strona działa wolno.