Użytkownik klika menu i przez chwilę nic. Naciska przycisk wysłania formularza, ale nie wie, czy formularz w ogóle zareagował. W sklepie dodaje produkt do koszyka, po czym patrzy na ekran jak na zepsuty automat. Strona niby działa, ale zachowuje się tak, jakby potrzebowała kawy i krótkiej drzemki.
To nie zawsze problem z samym ładowaniem strony. Czasem pierwszy ekran pojawia się całkiem sprawnie, a kłopot zaczyna się dopiero po interakcji. Właśnie tutaj pojawia się INP na stronie internetowej. Ta metryka pomaga sprawdzić, jak szybko witryna pokazuje widoczną reakcję po kliknięciu, tapnięciu albo naciśnięciu klawisza. Poniżej zobaczysz, co naprawdę mierzy INP, jak znaleźć wolne elementy i co można poprawić bez stawiania całej strony od zera.
Strona nie musi być wolna, żeby wkurzać użytkownika
Strona może wyświetlić pierwszy ekran bez większego dramatu, a mimo to irytować użytkownika przy najważniejszych działaniach. Menu nie otwiera się od razu. Filtr produktów reaguje z opóźnieniem. Formularz długo nie pokazuje, czy wiadomość została wysłana. Przycisk CTA wygląda, jakby nie przyjmował do wiadomości, że ktoś właśnie w niego kliknął.
Dla właściciela firmy to nie jest drobiazg techniczny. Użytkownik nie widzi kodu, głównego wątku ani renderowania. Widzi przycisk, klika i czeka. Jeśli nie dostaje szybkiego sygnału, może kliknąć ponownie, zamknąć stronę albo uznać, że sklep nie działa. Szczególnie ważne są ścieżki, które prowadzą do kontaktu lub zakupu: menu, wyszukiwarka, formularz, filtry, koszyk i przyciski CTA.
Ładowanie strony a reakcja po kliknięciu
Ładowanie strony i responsywność strony to nie to samo. Pierwsze dotyczy tego, kiedy użytkownik zobaczy treść i może zacząć korzystać z witryny. Drugie dotyczy tego, co dzieje się chwilę później, gdy wykona działanie. Dobry pierwszy ekran nie gwarantuje więc, że otwieranie menu albo dodawanie produktu do koszyka będzie sprawne.
Jeżeli po kliknięciu nie pojawia się żadna zmiana, użytkownik nie wie, czy działanie zostało przyjęte. To prosty przepis na nerwowe klikanie kilka razy. A potem trudno rozstrzygnąć, czy problemem była strona, urządzenie, skrypt czy zwykły brak informacji zwrotnej.
INP po ludzku: co ta metryka naprawdę mierzy
INP, czyli Interaction to Next Paint, jest stabilną metryką Core Web Vitals oceniającą responsywność strony podczas całej wizyty użytkownika. Nie patrzy wyłącznie na pierwszą interakcję. Bierze pod uwagę interakcje wykonywane przez cały cykl życia wizyty, więc lepiej pokazuje, czy witryna zachowuje się dobrze także po kilku kliknięciach.
INP obejmuje kliknięcia myszą, tapnięcia na ekranie dotykowym oraz naciśnięcia klawiszy. Nie obejmuje samego przewijania, najechania kursorem ani powiększania strony. Chodzi o czas od rozpoczęcia kwalifikowanej interakcji do momentu, gdy przeglądarka wyrenderuje kolejną klatkę z widoczną reakcją. Innymi słowy: nie tylko „czy kliknięcie zostało zarejestrowane”, ale też „kiedy użytkownik zobaczył efekt”.
Orientacyjne progi wyglądają tak:
- 200 ms lub mniej oznacza dobrą responsywność.
- Powyżej 200 ms do 500 ms wskazuje, że responsywność wymaga poprawy.
- Powyżej 500 ms oznacza słabą responsywność.
Wynik warto analizować na 75. percentylu, osobno dla urządzeń mobilnych i komputerów. Pojedynczy test nie opisuje doświadczenia wszystkich użytkowników. Wynik INP nie jest też obietnicą sprzedaży, wyższej konwersji ani automatycznego sukcesu strony. To informacja o tym, jak witryna reaguje na działania odwiedzających.
Trzy miejsca, w których może powstać opóźnienie
Opóźnienie interakcji składa się z trzech części. Input delay to czas oczekiwania przed rozpoczęciem obsługi zdarzenia. Jeśli główny wątek jest zajęty inną pracą, kliknięcie może poczekać w kolejce.
Processing duration obejmuje wykonywanie callbacków, czyli kodu uruchamianego w reakcji na działanie użytkownika. Ciężka operacja po kliknięciu może zająć przeglądarce sporo czasu. Presentation delay to oczekiwanie na wyrenderowanie kolejnej klatki z widoczną zmianą. Kod mógł już wykonać część pracy, ale użytkownik nadal nie widzi efektu.
Dlatego wrażenie zawieszenia nie musi oznaczać, że kliknięcie przepadło. Mogło zostać przyjęte, lecz przeglądarka była zajęta skryptem, aktualizacją interfejsu albo renderowaniem. Dla użytkownika różnica jest jednak czysto teoretyczna, jeśli przez kilka chwil nie widzi żadnej reakcji.
Jak sprawdzić, czy problem dotyczy właśnie Twojej strony
Najlepiej zacząć od PageSpeed Insights. Narzędzie może pokazać dane rzeczywistych użytkowników z raportu Chrome User Experience Report, czyli CrUX, oraz dane laboratoryjne generowane przez Lighthouse. Dane terenowe mówią, jak strona zachowuje się u użytkowników, a test laboratoryjny pomaga odtworzyć problem w kontrolowanych warunkach.
Najpierw sprawdź, czy dla konkretnego adresu są dostępne dane terenowe. Jeżeli ich nie ma, wynik laboratoryjny nadal może być przydatną wskazówką, ale nie jest pełnym obrazem doświadczenia wszystkich odwiedzających. PageSpeed Insights może potwierdzić problem z INP, lecz nie zawsze pokaże, który dokładnie przycisk lub skrypt jest winny.
Od testu ogólnego do konkretnego kliknięcia
Nie zatrzymuj się na samym wyniku. Przejdź przez najważniejsze ścieżki użytkownika i zanotuj, gdzie pojawia się opóźnienie. Sprawdź między innymi:
- otwieranie menu;
- wyszukiwanie produktu lub informacji;
- wysyłanie formularza;
- użycie filtrów;
- dodanie produktu do koszyka;
- przejście do checkoutu i działania na stronie płatności.
Następnie spróbuj odtworzyć problem w narzędziach laboratoryjnych i sprawdzić, czy opóźnienie pojawia się przed rozpoczęciem obsługi, podczas wykonywania kodu czy przy prezentacji efektu. Dokładniejsze przypisanie problemu do konkretnej interakcji może wymagać danych RUM albo nagrania wydajności w DevTools.
Warto porównywać urządzenia i podstrony. Sklep może reagować dobrze na stronie głównej, ale wolniej na widoku z filtrami. Formularz może działać sprawnie na komputerze, a opornie na telefonie. Jeden ogólny wynik nie odpowie na wszystkie te pytania.
Gdzie najczęściej ucieka responsywność
Jednym z częstych obciążeń jest JavaScript. Przeglądarka musi skrypt pobrać, sparsować, skompilować i wykonać. Długi kod może tworzyć długie zadania na głównym wątku, a wtedy obsługa interakcji czeka. Problem może dotyczyć skryptu ładowanego przy starcie strony albo kodu uruchamianego dopiero po kliknięciu.
Znaczenie mają też ciężkie callbacki. Jeśli po naciśnięciu przycisku strona wykonuje wiele operacji, aktualizuje dużą część interfejsu i dopiero potem pokazuje zmianę, użytkownik odczuwa całe to opóźnienie. Duży DOM, czyli rozbudowana struktura elementów strony, może zwiększać koszt renderowania zarówno przy pierwszym wyświetleniu, jak i po interakcji.
W grę wchodzą również kosztowne aktualizacje HTML, ciężkie komponenty i problemy z układem strony, w tym layout thrashing. Nie oznacza to jednak, że każda rozbudowana strona automatycznie ma problem. Liczy się konkretna sytuacja i sposób, w jaki elementy współpracują.
Wtyczka nie jest winna tylko dlatego, że istnieje
Wtyczki, integracje i skrypty zewnętrzne mogą pogarszać responsywność, ale sam fakt ich obecności niczego jeszcze nie rozstrzyga. Wpływ zależy od kodu, konfiguracji, miejsca ładowania oraz współpracy z pozostałymi elementami strony. Dotyczy to także analityki, czatu, płatności czy zabezpieczeń.
Dlatego masowe wyłączanie dodatków na chybił-trafił to kiepski plan. Można w ten sposób poprawić jeden wynik, a przy okazji zepsuć formularz, logowanie, koszyk albo płatności. Najpierw trzeba ustalić, który skrypt lub komponent spowalnia konkretną interakcję. Dopiero później ma sens ograniczenie jego zakresu, opóźnienie niekrytycznej pracy albo zastąpienie zbędnego elementu.
Nie warto też zrzucać wszystkiego na hosting. Wysoki INP może wynikać z JavaScriptu, obsługi zdarzeń, renderowania, dużego DOM-u, iframe’u, skryptów zewnętrznych albo połączenia kilku czynników.
Co da się poprawić bez stawiania strony od zera
W wielu przypadkach nie trzeba od razu planować pełnej przebudowy. Rozsądniej zacząć od jednej ważnej interakcji: formularza, menu, filtra, koszyka albo przycisku prowadzącego do kontaktu. Najpierw trzeba ustalić przyczynę, potem wdrożyć punktową zmianę i sprawdzić, czy podstawowa funkcja nadal działa.
Możliwe kierunki pracy obejmują ograniczenie zbędnych skryptów i funkcji obciążających konkretną ścieżkę, opóźnienie pracy, która nie musi blokować pierwszej reakcji, oraz odchudzenie ciężkich komponentów i widoków z dużą liczbą elementów. W kodzie można też ograniczyć pracę wykonywaną bezpośrednio po kliknięciu i szybciej pokazać podstawową zmianę interfejsu.
To nie są magiczne przełączniki. Zakres zmian zależy od rzeczywistej przyczyny. Czasem wystarczy punktowa optymalizacja, a czasem problem jest związany z większą częścią strony i wymaga szerszej analizy.
Najpierw jedna ścieżka, potem reszta
Najpraktyczniejszy porządek wygląda tak:
- Wybierz jedną ważną interakcję, na przykład dodanie produktu do koszyka.
- Sprawdź, czy opóźnienie występuje na telefonie, komputerze czy na obu urządzeniach.
- Ustal, czy problem dotyczy oczekiwania, pracy kodu czy pokazania efektu.
- Wprowadź ograniczoną zmianę i wykonaj test funkcjonalny.
- Sprawdź ponownie także inne ważne elementy strony.
Przed zmianami w kodzie, motywie, wtyczkach albo konfiguracji cache wykonaj kopię zapasową. Po zmianach sprawdź menu, formularze, logowanie, koszyk, płatności i wersję mobilną. Wydajność ma pomagać stronie, a nie urządzać jej mały remont bez zgody właściciela.
Kiedy problem wymaga głębszego audytu
Głębsza analiza jest potrzebna wtedy, gdy ogólny wynik nie pokazuje winowajcy, problem pojawia się tylko na konkretnej podstronie albo różni się mocno między urządzeniami. Nie ma sensu zgadywać na podstawie jednego testu. Bez adresu strony, danych rzeczywistych użytkowników i testów konkretnej instalacji nie da się uczciwie wskazać elementu odpowiedzialnego za opóźnienie ani obiecać konkretnej poprawy.
Jeżeli problem występuje wyłącznie przy ładowaniu filtrów, wysyłaniu formularza lub przejściu do koszyka, analizuj właśnie tę sytuację. Ogólny wynik może być dobrym sygnałem ostrzegawczym, ale nie zastąpi sprawdzenia ścieżki, na której użytkownik naprawdę chce coś zrobić.
Checklista przed zleceniem optymalizacji
Przed przekazaniem tematu wykonawcy przygotuj kilka konkretnych informacji:
- adres podstrony, na której występuje problem;
- opis opóźnionej interakcji, na przykład „klikam filtr i długo nie widzę zmiany”;
- urządzenie i przeglądarkę, na których problem się pojawia;
- wynik PageSpeed Insights z informacją, czy pochodzi z danych terenowych, czy laboratoryjnych;
- listę ostatnio dodanych wtyczek, integracji i skryptów.
Taki opis jest znacznie bardziej użyteczny niż hasło „strona jest wolna”. Pozwala zacząć od konkretu i sprawdzić, co dzieje się podczas realnej interakcji. Nie wyłączaj jednak masowo dodatków ani skryptów bez kopii zapasowej i testu funkcjonalnego. Najpierw diagnoza, potem zmiana.
Wysoki INP nie oznacza automatycznie, że trzeba budować nową stronę. Nie oznacza też, że winny jest hosting albo jedna przypadkowa wtyczka. Najpierw ustal, która interakcja reaguje zbyt wolno i na którym etapie powstaje opóźnienie. Potem testuj punktowe zmiany na najważniejszych ścieżkach użytkownika, sprawdzając przy okazji, czy formularze, koszyk, płatności i wersja mobilna nadal działają. Dane rzeczywistych użytkowników oraz testy konkretnej strony są warte więcej niż zgadywanie na podstawie jednego wyniku. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.
