Co ten wskaźnik naprawdę mierzy

INP bierze wszystkie interakcje użytkownika na stronie — kliknięcia, dotknięcia i wciśnięcia klawiszy — i raportuje praktycznie najgorszą z nich. Nie średnią. To fundamentalna różnica względem wskaźnika, na którego miejsce wszedł: tamten patrzył wyłącznie na pierwszą interakcję i tylko na to, ile czekała, zanim przeglądarka zaczęła się nią zajmować.

Tu liczy się cały czas od dotknięcia do momentu, w którym użytkownik widzi na ekranie efekt. Progi są proste: do 200 milisekund to wynik dobry, powyżej 500 milisekund słaby, między nimi strefa „wymaga poprawy”. Ocena dotyczy 75. percentyla realnego ruchu, więc jeden zepsuty element klikany przez co czwartego użytkownika potrafi zdecydować o statusie całej grupy adresów.

Warto od początku rozbić opóźnienie na trzy części, bo od tego zależy, gdzie szukać winy. Pierwsza to czas oczekiwania na wolny wątek — przeglądarka jest zajęta czymś innym i nie zaczęła jeszcze obsługiwać zdarzenia. Druga to wykonanie kodu przypisanego do tego zdarzenia. Trzecia to czas potrzebny na przeliczenie układu strony i narysowanie nowej klatki.

Z mojego doświadczenia w sklepach dominuje część pierwsza i trzecia, a nie druga — czyli nie sam kod obsługi kliknięcia jest problemem, ale to, co dzieje się wokół niego.

Dlaczego sklepy wypadają tu najgorzej

Strona firmowa albo blog mają kilka interakcji na sesję: rozwinięcie menu, przewinięcie, klik w link. Sklep ma ich dziesiątki i większość z nich uruchamia jednocześnie logikę interfejsu, przeliczenie ceny, zapytanie do serwera i kilka zdarzeń analitycznych.

Dochodzi do tego rozmiar dokumentu. Lista kategorii z sześćdziesięcioma produktami, rozbudowanym panelem filtrów i megamenu to bardzo często kilka tysięcy węzłów w drzewie strony. Przy takim dokumencie każda zmiana klasy CSS oznacza dla przeglądarki dużo więcej pracy przy przeliczaniu układu niż na prostej podstronie. Efekt widać właśnie w trzeciej części opóźnienia.

Trzecia rzecz to warstwa integracji. Sklepy noszą na sobie menedżer tagów, pikselki reklamowe, wyszukiwarkę zewnętrznego dostawcy, personalizację, testy A/B i zwykle jeszcze parę wtyczek dorzuconych po drodze. Każdy z tych skryptów walczy o ten sam wątek, na którym musi wykonać się reakcja na kliknięcie.

I ostatnie, o czym się rzadko mówi: urządzenia. Ruch mobilny w handlu to w dużej części telefony ze średniej i niskiej półki, kilkuletnie. Ten sam kod, który na moim laptopie odpowiada natychmiast, na takim sprzęcie liczy się wielokrotnie dłużej. Dlatego wynik z pola bywa dramatycznie gorszy niż wrażenie z własnych testów.

Zanim cokolwiek naprawisz — zmierz

Kolejność jest tu nienegocjowalna, bo bez danych z pola naprawia się rzeczy, które nikomu nie przeszkadzają.

• Raport Core Web Vitals w Search Console — pokazuje, które grupy adresów mają problem. To dobre miejsce na start, bo od razu widać, czy chodzi o listingi, karty produktu, czy o koszyk.

• Dane z pola w PageSpeed Insights — wynik z realnego ruchu dla adresu albo dla całej domeny. Ważne: sekcja z testem laboratoryjnym pod nimi nie pokazuje INP w ogóle, bo nikt tam w nic nie klika. To źródło nieporozumień, na które trafiam u klientów bardzo często.

• Biblioteka web-vitals na własnej stronie — w wersji z atrybucją przekazuje nie tylko liczbę, ale też selektor elementu, na którym doszło do opóźnienia, i podział na trzy części. To jedyny sposób, żeby dowiedzieć się, że winowajcą jest konkretny przycisk filtra, a nie „strona”.

• Panel Performance w przeglądarce z włączonym ograniczeniem procesora — do odtworzenia problemu, gdy już wiadomo, gdzie go szukać.

Wyniki z biblioteki warto wysyłać do własnego zbioru danych i patrzeć na nie w rozbiciu na typ urządzenia i szablon strony. Dopiero wtedy dyskusja z zespołem technicznym przestaje być wymianą opinii.

Trzy części opóźnienia, trzy różne naprawy

Jeśli dominuje czas oczekiwania na wolny wątek, problem leży poza obsługą kliknięcia. Ktoś zajmuje przeglądarkę długimi zadaniami — najczęściej inicjalizacją skryptów zewnętrznych, wczytywaniem danych do karuzeli albo jednorazową operacją na całej liście produktów. Naprawa polega na dzieleniu tych zadań na mniejsze fragmenty i oddawaniu kontroli przeglądarce między nimi, a także na przesunięciu wszystkiego, co nie jest potrzebne od razu, na później.

Jeśli dominuje wykonanie kodu, patrzę na to, co dzieje się w reakcji na zdarzenie. Klasyczny wzorzec do naprawy: w jednym miejscu wywoływane są naraz aktualizacja stanu, odczyt z pamięci lokalnej, przeliczenie koszyka i wysłanie zdarzenia do analityki. Wystarczy zostawić w obsłudze kliknięcia wyłącznie zmianę tego, co użytkownik ma zobaczyć, a resztę wykonać po narysowaniu klatki.

Jeśli dominuje czas na narysowanie klatki, sprawcą jest zwykle rozmiar i złożoność dokumentu. Tu pomaga skracanie list renderowanych naraz, ograniczanie zagnieżdżeń, unikanie animowania właściwości wymuszających przeliczenie układu i wskazanie przeglądarce, których fragmentów strony nie musi liczyć, dopóki nie są widoczne.

Rozróżnienie tych trzech przypadków oszczędza tygodnie pracy. Zespół, który bez pomiaru „optymalizuje JavaScript”, zwykle poprawia część, która i tak zajmowała najmniej.

Miejsca w sklepie, od których zaczynam

Filtry na listingu kategorii to numer jeden. Zaznaczenie jednego pola potrafi uruchomić przeliczenie liczników przy wszystkich pozostałych filtrach, przerysowanie całej listy i zmianę adresu. Rozwiązanie, które sprawdza mi się najlepiej: natychmiast pokazać zmianę stanu samego pola, a wynik listy podmienić chwilę później, bez blokowania interfejsu.

Drugie miejsce to wybór wariantu na karcie produktu. Rozmiar i kolor często przebudowują pół strony: galerię, cenę, dostępność, tabelę rozmiarów. Warto sprawdzić, czy naprawdę wszystko musi się przeliczyć od nowa.

Trzecie to wyszukiwarka z podpowiedziami. Każde wciśnięcie klawisza liczy się do INP, a podpowiedzi zwykle wiszą na zewnętrznej usłudze. Bez ograniczenia częstotliwości zapytań i przerywania nieaktualnych ten element sam potrafi zepsuć wynik całej witryny.

Czwarte to podglądowy koszyk. Dodanie produktu bywa najdroższą interakcją w sklepie, bo łączy zapytanie do serwera, aktualizację licznika, otwarcie panelu i kilka zdarzeń pomiarowych. Interfejs powinien pokazać reakcję od razu i dopiero potem uzgodnić stan z serwerem.

Czego nie naprawisz samym kodem

Część opóźnienia nie należy do Ciebie. Skrypty dostawców zewnętrznych wykonują się na tym samym wątku i nie masz wpływu na ich wnętrze — możesz jedynie zdecydować, czy i kiedy się wczytają. To osobny temat, któremu poświęcam oddzielny wpis, bo decyzja o wyłączeniu narzędzia rzadko jest wyłącznie techniczna.

Nie da się też sensownie „dogonić” wskaźnika na urządzeniach, które są po prostu wolne. Można natomiast przestać wysyłać do nich kod, którego nie potrzebują — na przykład dzielić paczki JavaScriptu tak, żeby karta produktu nie ładowała logiki kreatora zamówienia.

Trzecie ograniczenie jest organizacyjne. INP mierzy się na żywym ruchu z ostatnich dwudziestu ośmiu dni, więc po wdrożeniu poprawki wynik w raportach zmienia się z opóźnieniem. Trzeba to powiedzieć wprost przed startem prac, inaczej po dwóch tygodniach ktoś uzna, że zmiany nie zadziałały.

I rzecz, którą powtarzam przy każdym takim projekcie: dobry wskaźnik nie jest celem. Celem jest sklep, w którym da się wygodnie wybrać rozmiar na telefonie w tramwaju. Wskaźnik jest tylko sposobem sprawdzenia, czy to się udało.

Jak pilnować wyniku po wdrożeniu

Największym problemem nie jest doprowadzenie wskaźnika do zieleni, ale utrzymanie go tam. Sklepy żyją: dochodzą wtyczki, banery, nowe narzędzia marketingowe, kolejne testy. Każde takie wdrożenie potrafi cofnąć efekt kilku tygodni pracy.

Dlatego zostawiam po sobie dwie rzeczy. Pierwsza to stały pomiar w polu, z podziałem na szablony, przeglądany raz w miesiącu razem z resztą raportu. Druga to prosta zasada w procesie wdrożeń: każdy nowy skrypt na stronie ma przypisaną osobę, która potrafi odpowiedzieć na pytanie, po co on tam jest.

Brzmi banalnie, ale to właśnie brak tej drugiej rzeczy jest przyczyną, dla której u większości przejmowanych przeze mnie sklepów wydajność interfejsu z czasem systematycznie się pogarsza.