Co ta metryka właściwie mierzy

Punktem wyjścia jest moment, w którym użytkownik czegoś od strony chce: klika przycisk, dotyka pozycji w menu, wpisuje znak w polu wyszukiwania. Punktem końcowym — moment, w którym przeglądarka narysowała klatkę pokazującą, że coś się stało.

Uwaga na kluczowy szczegół: metryka nie sprawdza, czy operacja się zakończyła. Jeśli po kliknięciu w „dodaj do koszyka” natychmiast pojawi się wskaźnik ładowania, pomiar jest zamknięty w tym momencie, mimo że żądanie do serwera dopiero leci. Odwrotnie — jeśli przycisk zmieni wygląd dopiero po powrocie odpowiedzi, całe oczekiwanie wchodzi do wyniku.

To rozróżnienie ma bezpośrednie konsekwencje dla projektowania interfejsu. Strona, która potwierdza przyjęcie kliknięcia od razu, będzie oceniona lepiej niż strona wykonująca dokładnie tę samą pracę, ale milcząca do końca operacji. Nie jest to obchodzenie pomiaru — dokładnie tak działa ludzkie postrzeganie responsywności.

Warto też podkreślić, że mówimy o mierze czasu oczekiwania, nie o mierze obciążenia. Strona z ciężkim kodem może mieć dobry wynik, jeśli ten kod nie blokuje reakcji interfejsu, i odwrotnie: lekka strona z jedną nieszczęśliwie napisaną funkcją potrafi wypaść źle.

Trzy części każdego opóźnienia

Pojedynczy pomiar rozkłada się na trzy odcinki i to rozbicie jest najużyteczniejszą rzeczą w całej metryce, bo każdy odcinek naprawia się inaczej.

• Opóźnienie wejściowe — czas od dotknięcia ekranu do chwili, w której przeglądarka zaczęła obsługiwać zdarzenie. Jeśli wątek główny jest w tym momencie zajęty czymś innym, kliknięcie po prostu czeka w kolejce. To odcinek, za który najczęściej odpowiadają skrypty niezwiązane z samą interakcją.

• Czas przetwarzania — wykonanie kodu obsługującego zdarzenie: funkcji nasłuchujących, walidacji, przeliczeń, aktualizacji stanu aplikacji. Tu winowajcą jest kod strony i to najbardziej „własna” część wyniku.

• Opóźnienie prezentacji — czas od zakończenia kodu do wyrenderowania klatki. Zależy od tego, ile pracy przeglądarka musi wykonać nad układem i przemalowaniem: rozmiaru drzewa dokumentu, złożoności stylów, liczby elementów wymagających przeliczenia.

Kiedy dostaję samą liczbę bez rozbicia, wiem tylko, że jest problem. Kiedy dostaję rozbicie, wiem, do kogo iść: pierwszy odcinek to zwykle rozmowa o skryptach marketingowych, drugi o kodzie aplikacji, trzeci o strukturze szablonu i stylach.

Które interakcje są liczone

Metryka nie bierze pod uwagę wszystkiego, co robi użytkownik. Liczone są trzy rodzaje zdarzeń: kliknięcie myszą, dotknięcie ekranu i naciśnięcie klawisza.

Nie liczy się natomiast przewijanie strony ani samo najechanie kursorem. To zaskakuje wiele osób, bo szarpiące przewijanie jest jednym z najbardziej irytujących defektów strony — ale mierzy się je innymi narzędziami i nie wchodzi do tej metryki.

Jest jeszcze subtelność dotycząca klawiatury: pomiar dotyczy pojedynczego naciśnięcia klawisza jako całości, wraz z powiązanymi zdarzeniami. Dlatego pole wyszukiwania z podpowiedziami odpytywanymi przy każdym znaku to jeden z najczęstszych problemów w sklepach — każde uderzenie w klawisz uruchamia pracę, którą trzeba wykonać przed narysowaniem kolejnej klatki.

W praktyce oznacza to, że kandydatów na słaby wynik warto szukać wśród elementów interfejsu obsługujących te trzy typy zdarzeń: menu, filtry, karuzele, akordeony, pola formularzy, przyciski koszyka i wszystko, co otwiera warstwę modalną.

Skąd bierze się jedna liczba dla całej wizyty

Tu jest największa różnica względem FID, czyli metryki responsywności obowiązującej do marca: FID patrzy wyłącznie na pierwszą interakcję i tylko na jej opóźnienie wejściowe.

Przeglądarka mierzy wszystkie interakcje w czasie wizyty, a na koniec raportuje jedną wartość — praktycznie najgorszą z nich. Praktycznie, a nie dokładnie, bo dla wizyt z dużą liczbą interakcji odrzucany jest niewielki odsetek najbardziej odstających pomiarów. Dzięki temu jedno przypadkowe zacięcie, na przykład w momencie przełączenia sieci, nie decyduje o ocenie całej sesji.

Dwa wnioski płyną z tego dla codziennej pracy. Pierwszy: jeden wolny element potrafi zepsuć wynik strony, na której wszystko inne działa świetnie — wystarczy, że użytkownicy go używają. Drugi: im dłuższa wizyta i im więcej interakcji, tym większa szansa, że użytkownik trafi na ten wolny element, więc strony z rozbudowaną nawigacją mają trudniej niż prosty landing.

Osobna rzecz, o której warto pamiętać przy porównaniach: wartość jest przypisywana do wizyty, a nie do konkretnego kliknięcia, więc nie da się jej wprost zsumować ani wyciągnąć średniej z pojedynczych zdarzeń bez zniekształcenia obrazu.

Progi: 200 i 500 milisekund

Google opublikował progi razem z zapowiedzią zmiany, więc znamy je na długo przed marcem. Są trzy i są wspólne dla urządzeń mobilnych i komputerów.

• Do 200 milisekund — wynik dobry. Reakcja jest dla użytkownika natychmiastowa.

• Powyżej 200 do 500 milisekund — wymaga poprawy. Da się zauważyć, że coś trwa, choć strona nie wydaje się zepsuta.

• Powyżej 500 milisekund — wynik słaby. To poziom, przy którym użytkownicy klikają drugi raz, bo są przekonani, że pierwsze kliknięcie się nie zarejestrowało.

Kluczowy szczegół, który decyduje o interpretacji: liczy się 75. percentyl wizyt, raportowany osobno dla urządzeń mobilnych i komputerów — tak samo jak przy pozostałych wskaźnikach. Nie średnia i nie mediana. Żeby po marcu zaliczyć się do przedziału dobrego, trzy czwarte wizyt musi mieścić się poniżej 200 milisekund.

Ta konstrukcja ma praktyczne znaczenie. Konsekwentnie eliminuje wynik ładny „w większości przypadków” — jeśli co trzeci użytkownik czeka pół sekundy, wynik będzie słaby niezależnie od tego, jak szybko strona reaguje na dobrym sprzęcie. Z tego samego powodu nie da się poprawić oceny przez optymalizację wersji na komputery: telefony liczą się osobno i tam prawie zawsze leży problem.

Dlaczego dwa narzędzia dają różne liczby

Najczęstsze źródło nieporozumień. Odpowiedź brzmi: bo mierzą dwie różne rzeczy.

Dane z pola pochodzą od prawdziwych użytkowników Chrome i uwzględniają ich sprzęt, łącze, wtyczki przeglądarki i sposób korzystania ze strony. Są zbierane w oknie liczonym w tygodniach i to one, a nie test laboratoryjny, będą podstawą oceny po marcu. Dane z testu laboratoryjnego to jednorazowe uruchomienie strony w kontrolowanych warunkach — pokazuje, jak strona się ładuje, ale nikt w tym teście nie klika.

I tu jest sedno: w audycie laboratoryjnym tej metryki po prostu nie ma, bo nie da się zmierzyć reakcji na interakcję, której nikt nie wykonał. Zamiast niej narzędzia pokazują wskaźnik czasu blokowania wątku głównego. To dobry przybliżony wskaźnik — jeśli wątek jest zablokowany długo po wejściu na stronę, reakcje na kliknięcia będą wolne — ale to nie ta sama liczba i nie należy jej nią nazywać.

Praktyczny wniosek: do oceny stanu bierz dane z pola, a do szukania przyczyn używaj narzędzi laboratoryjnych i ręcznego nagrywania scenariuszy w przeglądarce. Odwrotna kolejność kończy się optymalizowaniem czegoś, czego użytkownicy nie odczuwają.

Jak czytać wynik, żeby się nie pomylić

Zbiór pomyłek, które zdarzają się najczęściej — także mnie na początku.

Pierwsza: porównywanie wartości dla adresu z wartością dla całej domeny. Przy mniejszym ruchu dane dla pojedynczego adresu mogą być niedostępne i narzędzie podaje wynik dla całej witryny. Łatwo wtedy uznać, że poprawka na jednej podstronie nic nie dała.

Druga: ocenianie efektu poprawki po jednym dniu. Okno pomiaru w danych publicznych ma kilka tygodni, więc zmiana wchodzi w statystyki stopniowo i przez pierwsze dni w ogóle nie jest widoczna.

Trzecia: mieszanie tej metryki z szybkością wczytywania. Strona może pokazywać treść błyskawicznie i reagować fatalnie — to niezależne wymiary i naprawia się je innymi środkami.

Czwarta: testowanie na własnym komputerze i wyciąganie wniosków. Na sprzęcie deweloperskim praktycznie każda strona reaguje dobrze. Bez spowolnienia procesora w narzędziach programisty albo testu na przeciętnym telefonie diagnoza będzie fałszywie optymistyczna.

I ostatnia rzecz, którą warto ustalić z klientem od początku: metryka pochodzi od użytkowników Chrome. Jeśli spory udział ruchu przychodzi z innych przeglądarek, dane opisują tylko część odbiorców — co nie zmienia faktu, że to właśnie ta część zasila narzędzia Google.

Na koniec przypomnienie, od którego zacząłem, bo łatwo się pomylić w rozmowie z klientem. W Search Console INP jest dziś dostępny w osobnym raporcie, wystawionym po to, żeby dało się przygotować do zmiany. Raport podstawowych wskaźników internetowych, ten, który wystawia ocenę adresów, opiera się na razie na FID i przełączy się w marcu. Dlatego pytanie „ile mam adresów wymagających poprawy” ma w styczniu i w kwietniu dwie różne odpowiedzi, a różnica nie musi mieć nic wspólnego ze stanem strony.