Dlaczego dotychczasowa metryka wprowadzała w błąd

Stara metryka responsywności mierzyła pierwszą interakcję i tylko jej opóźnienie wejściowe — czyli czas od kliknięcia do momentu, w którym przeglądarka zaczęła obsługiwać zdarzenie. Nie mierzyła tego, jak długo trwało samo wykonanie kodu ani kiedy użytkownik zobaczył efekt.

Skutek był taki, że strona mogła mieć wynik podręcznikowy i jednocześnie sprawiać wrażenie zawieszonej. Klasyczny przykład: pierwsze kliknięcie w banerze zgody trafia w moment, w którym wątek jest jeszcze wolny, więc metryka notuje kilka milisekund. Trzy kliknięcia później, gdy działa już kod filtrów, dodawania do koszyka i trzy narzędzia analityczne, reakcja przychodzi po pół sekundy — ale tego stara metryka nie widziała.

Nowa metryka mierzy wszystkie interakcje na stronie i całą ich długość: od kliknięcia, przez wykonanie kodu, do wyrenderowania kolejnej klatki. Innymi słowy — mierzy to, co użytkownik faktycznie odczuwa.

Dlatego traktuję tę zmianę nie jako nowy wymóg do odhaczenia, a jako pierwszy moment, w którym raport Google zaczyna zgadzać się z tym, co widać na telefonie. Wcześniej można było mieć zieloną kartę i wściekłego użytkownika.

Krok pierwszy: zmierz stan wyjściowy na danych z pola

Zanim cokolwiek zmienisz, potrzebujesz punktu odniesienia — i musi on pochodzić od prawdziwych użytkowników, nie z testu na Twoim laptopie.

Najprostsze źródło to raport publiczny zbierany przez Chrome i wystawiony w narzędziach do badania szybkości stron. Nowa metryka jest tam raportowana od miesięcy, obok starej, więc możesz sprawdzić swoją wartość dzisiaj, bez czekania na marzec. To robię zawsze na pierwszym spotkaniu na ten temat — zajmuje dwie minuty i od razu porządkuje rozmowę.

Trzy rzeczy, na które zwracam uwagę przy odczycie. Po pierwsze, rozdzielenie na urządzenia mobilne i komputery — różnica bywa dramatyczna i prawie zawsze problem jest na telefonach. Po drugie, poziom danych: dla mniejszych witryn dane zbiorcze mogą być dostępne tylko dla całej domeny, nie dla pojedynczych adresów. Po trzecie, okno pomiaru — raport pokazuje dane z ostatnich kilku tygodni, więc efekt poprawek zobaczysz z opóźnieniem i nie ma sensu odświeżać go codziennie.

Do tego zaglądam do raportu podstawowych wskaźników internetowych w Search Console. W tej chwili opiera się on jeszcze na starej metryce, a Google zapowiedział przełączenie razem ze zmianą — więc nie zdziw się skokiem liczby adresów wymagających poprawy w marcu. Lepiej mieć wcześniej własny pomiar, żeby wiedzieć, czy skok oznacza pogorszenie strony, czy tylko zmianę linijki.

Krok drugi: znajdź konkretne wolne interakcje

Wartość zbiorcza mówi, że jest problem. Nie mówi, gdzie. Do tego potrzebne są dwa narzędzia.

Pierwsze to biblioteka pomiarowa Google dostępna w wersji z dodatkową atrybucją. Wpięta w stronę potrafi zaraportować nie tylko liczbę, ale też element, w który kliknięto, oraz rozbicie czasu na części składowe. Wyniki wysyłam do GA4 jako zdarzenie z parametrami i po tygodniu mam listę elementów interfejsu posortowaną po tym, jak długo każe użytkownikowi czekać. To najbardziej wartościowe dane w całym procesie, bo zamieniają dyskusję o „wolnej stronie” na listę konkretnych przycisków.

Drugie to narzędzia programisty w przeglądarce. W panelu wydajności, po włączeniu spowolnienia procesora do poziomu odpowiadającego przeciętnemu telefonowi, nagrywam scenariusze: otwarcie menu, kliknięcie w filtr, dodanie produktu do koszyka, wysłanie formularza. Szukam długich zadań blokujących wątek główny i sprawdzam, co je wywołuje.

Ważne zastrzeżenie metodyczne: testuję na sprzęcie i łączu podobnym do tego, którym dysponują użytkownicy. Na komputerze z szybkim procesorem prawie każda strona reaguje natychmiast, a to najczęstsza przyczyna wniosku „u nas wszystko działa dobrze”.

Krok trzeci: uporządkuj skrypty zewnętrzne

Statystycznie największe zyski przy najmniejszym nakładzie leżą tutaj, więc zaczynam od tego, mimo że to najmniej ambitna część pracy.

• Kontener tagów — sprawdzam, ile tagów faktycznie jest aktywnych i czy któreś nie dublują się z kodem wpisanym na sztywno w motyw. Na kontach przejmowanych po latach znajduję piksele narzędzi, z których klient nie korzysta od dawna.

• Czat i narzędzia do nagrywania sesji — najcięższa kategoria. Warto sprawdzić, czy da się je uruchamiać po interakcji użytkownika albo po zakończeniu ładowania, zamiast razem ze stroną.

• Baner zgody — paradoksalnie często najgorszy element, bo z definicji musi wystartować pierwszy. Nie da się go opóźnić, ale da się wybrać lżejszą implementację i nie ładować przez niego dziesięciu dodatkowych bibliotek.

• Skrypty testów A/B i personalizacji — blokują wątek i często zostają na stronie długo po zakończeniu testu.

Każdy z tych elementów ma właściciela w firmie i to zwykle nie jest programista. Dlatego traktuję ten krok jako rozmowę o priorytetach: co naprawdę jest używane, a co zostało włączone „na próbę” dwa lata temu.

Krok czwarty: rozbij długie zadania we własnym kodzie

Jeśli po uporządkowaniu skryptów zewnętrznych wynik nadal jest słaby, problem leży w kodzie strony i wchodzi programista. Warto wtedy wiedzieć, o co prosić.

Podstawowa technika to rozbijanie długich zadań na krótsze i oddawanie kontroli przeglądarce pomiędzy nimi. Zamiast jednej funkcji przetwarzającej sto elementów listy w jednym przebiegu — kilka mniejszych porcji z przerwami, w których przeglądarka może narysować klatkę. Klasycznie robi się to przez oddanie sterowania w kolejce zadań; w Chrome trwają też prace nad dedykowanym mechanizmem oddawania kontroli, ale w styczniu 2024 traktuję go jako eksperyment, nie jako rozwiązanie do wdrożenia na produkcji.

Druga technika to rozdzielenie reakcji od obliczeń. Kliknięcie powinno natychmiast pokazać efekt wizualny — zmianę stanu przycisku, wskaźnik ładowania — a cięższą pracę wykonać po wyrenderowaniu klatki. Użytkownik ocenia responsywność po tym, czy interfejs zareagował, nie po tym, czy operacja się skończyła.

Trzecia to zwykła higiena: ograniczanie liczby nasłuchów zdarzeń, unikanie kodu odpalanego przy każdym przewinięciu, przenoszenie ciężkich obliczeń do wątku roboczego. W sklepach na popularnych platformach źródłem długich zadań są zwykle filtry katalogu i podliczanie koszyka.

Krok piąty: struktura strony i style

Ostatnia kategoria bywa pomijana, bo nie kojarzy się z szybkością reakcji, a potrafi decydować o połowie wyniku.

Rozmiar drzewa dokumentu ma bezpośredni wpływ na czas renderowania kolejnej klatki. Strona z kilkudziesięcioma tysiącami elementów będzie reagować leniwie nawet przy lekkim kodzie, bo sam układ i przemalowanie trwają długo. To typowa cecha katalogów wyświetlających kilkaset produktów naraz i stron budowanych kreatorem, w którym każda sekcja opakowana jest w kilka dodatkowych kontenerów.

Drugi element to kosztowne przeliczanie układu wywoływane przez animacje i style. Animowanie właściwości wpływających na układ zamiast tych obsługiwanych przez kompozytor to najczęstszy błąd. Pomaga też odcięcie renderowania fragmentów niewidocznych na ekranie.

Trzeci to obrazy i osadzone ramki — mapy, filmy, widgety opinii. Nie wpływają na czas reakcji bezpośrednio, ale konkurują o te same zasoby w krytycznym momencie, więc leniwe ładowanie tego, co jest poza ekranem, poprawia sytuację przy każdej interakcji w pierwszych sekundach wizyty.

Kolejność prac i czego nie oczekiwać

Plan, który proponuję klientom na najbliższe tygodnie, wygląda tak: tydzień na pomiar i wpięcie biblioteki z atrybucją, tydzień na przegląd skryptów zewnętrznych i decyzje właścicielskie, dwa–trzy tygodnie na poprawki w kodzie, reszta na weryfikację.

Trzy rzeczy, na które warto się przygotować mentalnie.

Po pierwsze, efekt w raportach zobaczysz z opóźnieniem, bo dane z pola mają swoje okno i wchodzą do statystyk stopniowo. Nie da się wdrożyć poprawki w piątek i sprawdzić wyniku w poniedziałek.

Po drugie, sama zmiana metryki nie przemebluje wyników wyszukiwania. Doświadczenie na stronie jest jednym z wielu czynników i słabsza responsywność nie skasuje dobrego dopasowania treści do zapytania. Argumentu „poprawimy INP i wskoczymy na pierwsze miejsce” nie używam i odradzam wierzenie w niego.

Po trzecie, to nie jest projekt jednorazowy. Każda nowa wtyczka i każdy nowy skrypt marketingowy dodaje pracy wątkowi głównemu, więc bez sprawdzania przy kolejnych wdrożeniach wynik po pół roku wróci do punktu wyjścia. U klientów, u których to działa, pomiar responsywności jest po prostu punktem na liście kontrolnej przed każdą publikacją zmian na stronie.