Czym INP różni się od FID

Warto zrozumieć, co dokładnie zmieniło się w pomiarze, bo od tego zależy, gdzie szukać problemu.

FID mierzył wyłącznie opóźnienie wejściowe pierwszej interakcji — czas od momentu, w którym użytkownik kliknął, do momentu, w którym przeglądarka mogła zacząć obsługiwać to zdarzenie. Nie interesowało go, ile trwało samo wykonanie kodu ani kiedy użytkownik zobaczył rezultat. Dlatego strona mogła mieć znakomity FID i jednocześnie reagować z wyraźnym opóźnieniem.

Nowy wskaźnik obejmuje całą drogę: opóźnienie wejściowe, czas przetwarzania procedur obsługi zdarzeń oraz czas do wyrenderowania kolejnej klatki. Do tego nie ogranicza się do pierwszej interakcji — bierze pod uwagę praktycznie najgorszą interakcję w całej wizycie.

Progi są następujące: do dwustu milisekund wynik jest dobry, między dwustu a pięciuset wymaga poprawy, powyżej pięciuset jest zły. Ocena, jak zawsze w tych wskaźnikach, dotyczy siedemdziesiątego piątego percentyla ruchu z pola, a nie średniej.

Z czego składa się opóźnienie interakcji

Rozbicie wskaźnika na trzy części jest praktyczne, bo każda ma inną przyczynę i inne lekarstwo.

• Opóźnienie wejściowe — przeglądarka jest zajęta czymś innym w momencie kliknięcia. Zwykle winne są długie zadania w głównym wątku: parsowanie i wykonywanie skryptów, inicjalizacja wtyczek, skrypty firm zewnętrznych startujące po wczytaniu strony.

• Czas przetwarzania — kod obsługujący kliknięcie wykonuje się długo. Tu winowajcą są nadmiernie rozbudowane procedury obsługi zdarzeń, wielokrotnie podpięci nasłuchiwacze i operacje na strukturze dokumentu wykonywane w pętli.

• Czas do następnej klatki — efekt jest już policzony, ale przeglądarka nie może go pokazać, bo musi przeliczyć układ strony. Duże, złożone drzewo dokumentu i ciężkie style potrafią samodzielnie wygenerować dwieście milisekund.

Jak zmierzyć wskaźnik na własnym serwisie

Zaczynam zawsze od danych z pola, nie z testu laboratoryjnego. Laboratorium nie potrafi zmierzyć tego wskaźnika, bo nie ma interakcji użytkownika — pokaże tylko szacunki i wskaźniki zastępcze.

Kolejność, którą stosuję. Najpierw Search Console i raport podstawowych wskaźników internetowych, który pokazuje grupy adresów o podobnych problemach. Potem PageSpeed Insights dla konkretnego adresu, w części dotyczącej danych z ruchu rzeczywistego. Dopiero na końcu narzędzia deweloperskie w przeglądarce, gdzie w panelu wydajności odtwarzam interakcję i widzę długie zadania blokujące wątek.

Skąd w WordPressie bierze się nadmiar JavaScriptu

Mechanizm jest zawsze ten sam: wtyczki i motywy rejestrują swoje pliki globalnie, bo nie wiedzą, na której podstronie będą używane.

Kreatory stron ładują komplet skryptów dla wszystkich modułów, także tych, których na danej podstronie nie ma. Wtyczka formularza kontaktowego dokłada swoje pliki do każdego adresu w serwisie, choć formularz jest tylko na stronie kontaktu. Wtyczka sklepowa w witrynie, która ma trzy produkty, ładuje pełny zestaw skryptów koszyka na wpisach blogowych. Suwaki, galerie, mapy, liczniki, wtyczki animacji przy przewijaniu, czat, banery zgód, skrypty statystyk i narzędzi reklamowych — każde z osobna niewinne.

Zanim cokolwiek wyłączę, robię inwentaryzację. Otwieram kartę sieci w narzędziach deweloperskich, filtruję po skryptach i wypisuję pliki wraz z katalogiem wtyczki, z której pochodzą, dla czterech typowych adresów: strony głównej, wpisu, kategorii i strony kontaktu. Ta lista jest podstawą wszystkich dalszych decyzji i zwykle sama z siebie wywołuje u klienta refleksję.

Wyłączanie skryptów tam, gdzie nie są potrzebne

Tu jest największy zysk przy najmniejszym ryzyku, o ile robi się to warunkowo, a nie globalnie.

Mechanizm w WordPressie jest prosty: skrypty i style rejestrowane przez wtyczki można usunąć z kolejki funkcjami do zdejmowania zasobów, wywołanymi w akcji odpowiedzialnej za wczytywanie plików, z priorytetem wyższym niż rejestracja. Warunek osadzam na sprawdzeniu typu strony — czy to wpis, czy dana strona, czy widok archiwum.

W praktyce najczęściej wyłączam: skrypty formularza poza stroną kontaktu, pliki sklepu poza sekcją sklepową, suwaki poza stroną główną, mapy poza stroną z lokalizacją, biblioteki animacji tam, gdzie żadnych animacji nie ma, oraz emotikony i osadzenia z innych serwisów, jeśli nie są używane w treści.

Jeśli klient nie chce ingerencji w kod, ten sam efekt daje wtyczka do warunkowego zarządzania zasobami — takich narzędzi jest kilka i pozwalają wyłączać pojedyncze pliki na wybranych adresach z panelu. Wolę je od rozwiązań, które po prostu odkładają cały JavaScript do momentu pierwszej interakcji: to poprawia wskaźniki dotyczące wczytywania, ale opóźnienie interakcji potrafi wręcz pogorszyć, bo cały koszt przenosi się na pierwsze kliknięcie użytkownika.

Interakcje, które warto rozbić na mniejsze zadania

Kiedy skrypty są posprzątane, a wynik nadal zły, problem siedzi w kodzie obsługującym konkretną interakcję.

Podejście, które działa, opiera się na jednej myśli: użytkownik musi zobaczyć reakcję natychmiast, ale nie cała praca musi być wykonana natychmiast. Dzielę więc obsługę zdarzenia na dwie części. Pierwsza, minimalna, zmienia to, co widoczne — zaznacza przycisk, pokazuje wskaźnik ładowania, zamyka menu. Druga, cięższa, zostaje odłożona do kolejnego cyklu przeglądarki, tak żeby wątek główny mógł w międzyczasie wyrenderować klatkę.

Czego nie robić przy tej optymalizacji

Kilka rzeczy, które regularnie widzę i które kończą się cofaniem zmian.

Nie wyłączam bibliotek globalnie bez sprawdzenia zależności. Zdjęcie jednego pliku, od którego zależy pięć innych, potrafi wyłączyć menu mobilne albo koszyk, a błąd zauważa się dwa tygodnie później po spadku sprzedaży.

Nie zaczynam od odkładania wszystkiego do pierwszej interakcji. To najpopularniejsza opcja we wtyczkach optymalizacyjnych i najgorszy pomysł dla tego konkretnego wskaźnika.

I na koniec rzecz, o której trzeba mówić uczciwie: to wskaźnik doświadczenia użytkownika, a nie główna dźwignia pozycji w wyszukiwarce. Poprawa z sześciuset do stu pięćdziesięciu milisekund jest zauważalna dla ludzi korzystających ze strony i to jest jej najlepsze uzasadnienie. Obietnice skokowego wzrostu ruchu z samej optymalizacji tego wskaźnika traktowałbym z rezerwą.