30-krotny spadek TBT i przejście na Next.js pomogło The Ecomonic Times prawie czterokrotnie obniżyć INP, co przełożyło się na 50-procentowy spadek współczynnika odrzuceń i 43-procentowy wzrost liczby odsłon.
Interakcja z następnym wyrenderowaniem (INP) to wartość oceniająca responsywność witryny na dane wejściowe użytkownika. Dobra responsywność oznacza, że strona szybko reaguje na interakcje użytkowników. Im niższy jest wartość INP strony, tym lepiej może ona reagować na interakcje użytkowników.
Niewyraźny początek
Gdy firma Google wprowadziła INP jako rodzaj eksperymentalnego wskaźnika, który może przekształcić się w jeden z podstawowych wskaźników internetowych, zespół Ekonomii podjął wyzwanie, aby rozwiązać ten problem, zanim spadł do jednego z nich. Światowej reputacji dla użytkowników jest kluczowe dla naszych podstawowych wartości biznesowych.
Wskaźnik INP należy do najtrudniejszych do rozwiązania jak dotąd. Na początku nie mieliśmy pewności, jak skutecznie mierzyć wartość INP. Utrudniał to brak wsparcia ze strony społeczności – w przypadku większości dostawców usług monitorowania użytkowników realnych (RUM), którzy jeszcze go nie obsługiwali. Mieliśmy jednak do dyspozycji narzędzia Google RUM, takie jak Raport na temat użytkowania Chrome (CrUX), biblioteka JavaScript web-vitals i inne pomocnicze narzędzia, dzięki którym mogliśmy się zorientować, gdzie się znajdujemy podczas analizy przyszłej ścieżki. Na początku wartość INP wynosiła prawie 1000 milisekund na poziomie źródła.
Podczas poprawiania wartości INP w polu okazało się, że jednym z danych laboratoryjnych, na które należy kierować reklamy, jest Total Block Time (TBT). Narzędzie TBT było już dobrze udokumentowane i wspierane przez społeczność. Pomimo osiągnięcia progów w przypadku podstawowych wskaźników internetowych nie radziliśmy sobie zbyt dobrze w przypadku TBT, ponieważ od samego początku minęło ponad 3 sekundy.
Co to jest TBT i co zrobiliśmy, żeby je ulepszyć?
TBT to wskaźnik laboratoryjny, który mierzy responsywność strony internetowej w odniesieniu do działań użytkownika podczas jej wczytywania. Każde zadanie, którego wykonanie trwa dłużej niż 50 milisekund, jest uznawane za długie, a czas po przekroczeniu tego progu jest nazywany czasem blokowania.
Do ustalenia czasu pracy obliczono sumę czasu blokowania wszystkich długich zadań podczas wczytywania strony. Jeśli na przykład podczas wczytywania zostaną uruchomione 2 długie zadania, czas zablokowania będzie określany w ten sposób:
- Zadanie A trwa 80 milisekund (30 milisekund, czyli więcej niż 50 milisekund).
- Zadanie B trwa 100 milisekund (50 milisekund, czyli więcej niż 50 milisekund).
Czas do ustalenia strony będzie wynosić: 80 milisekund (30 + 50). Im niższa wartość TBT, tym lepiej. Pamiętaj, że te informacje są też dobrze skorelowane z INP.
Oto krótkie porównanie w laboratorium przed wprowadzeniem zmian w ramach poprawy wyników i po ich wprowadzeniu:
Zminimalizuj aktywność wątku głównego
Główny wątek przeglądarki zajmuje się wszystkim – od analizowania kodu HTML przez tworzenie modelu DOM, analizowanie CSS i stosowanie stylów, a także ocenianie i wykonywanie kodu JavaScript. Wątek główny obsługuje też interakcje użytkowników, czyli kliknięcia i naciśnięcia klawiszy. Jeśli wątek główny jest zajęty czymś innym, może nie reagować skutecznie na dane wejściowe użytkownika, co może utrudniać korzystanie z aplikacji.
Było to dla nas najtrudniejsze, ponieważ mamy własne algorytmy, które wykrywają tożsamość użytkownika na potrzeby wyświetlania reklam na podstawie stanu subskrypcji, a zewnętrzne skrypty do testowania A/B, analiz i innych celów.
Na początku podjęliśmy drobne kroki, na przykład obniżyliśmy priorytet wczytywania mniej istotnych zasobów biznesowych. Po drugie: zajęliśmy requestIdleCallback do zadań niekrytycznych, co pozwoliło ograniczyć ilość TBT.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
W przypadku używania funkcji requestIdleCallback zalecamy określenie limitu czasu, ponieważ zapewnia ono, że w przypadku gdy upłynie określony czas, a wywołanie zwrotne nie zostanie jeszcze wykonane, wywołanie zwrotne zostanie wykonane natychmiast po upływie limitu czasu.
Skrócenie czasu oceny skryptu
Biblioteki zewnętrzne wczytywały się też leniwie za pomocą komponentów możliwych do wczytania. Usunęliśmy też nieużywany kod JavaScript i arkusze CSS, profilując stronę za pomocą narzędzia pokrycia w Narzędziach deweloperskich w Chrome. Pomogło nam to zidentyfikować obszary, w których konieczne było potrząsanie drzewem, aby przesyłać mniej kodu podczas wczytywania strony, a tym samym zmniejszyć początkowy rozmiar pakietu aplikacji.
Zmniejsz rozmiar DOM
Zgodnie z Lighthouse duże rozmiary DOM zwiększają wykorzystanie pamięci, powodują dłuższe przeliczenia stylów i tworzą kosztowne przeformatowania układu.
Liczbę węzłów DOM zmniejszyliśmy na 2 sposoby:
- Po pierwsze wyrenderowaliśmy nasze menu na prośbę użytkownika (po kliknięciu). Zmniejszył on rozmiar DOM o około 1200 węzłów.
- Po drugie leniwie ładowaliśmy mniej ważne widżety.
W wyniku tych wszystkich działań znacząco zmniejszyliśmy TBT, a INP został odpowiednio zmniejszony o prawie 50%:
W tym momencie prawie zabrakło nam łatwych wygranych, które pozwoliły nam jeszcze bardziej ograniczyć TBT (i INP z serwera proxy), ale wiedzieliśmy, że mamy dużo możliwości poprawy. Właśnie dlatego postanowiliśmy uaktualnić nasz niestandardowy schemat UI do najnowszej wersji oraz dodać kod Next.js, aby lepiej wykorzystać haki i uniknąć niepotrzebnego ponownego renderowania komponentów.
Ze względu na częstsze aktualizacje i mniejszy ruch w porównaniu z innymi częściami witryny rozpoczęliśmy przenoszenie stron tematycznych do Next.js. Wykorzystaliśmy też PartyTown w celu przekazania robotom internetowym dodatkowej pracy z wątkami głównymi oraz techniki takie jak requestIdleCallBack do odroczenia niekrytycznych zadań.
W jaki sposób poprawa wskaźnika INP pomogła The Economic Times?
Obecne TBT i INP w miejscu początkowym
W chwili opublikowania tego posta czas oczekiwania na uruchomienie dla strony początkowej wynosił 120 milisekund, czyli z 3260 milisekund w momencie rozpoczęcia prac optymalizacyjnych. Podobnie wartość INP dla naszego punktu początkowego wyniosła 257 milisekund po zakończeniu działań optymalizacyjnych, czyli z ponad 1000 milisekund.
Trend INP CrUX
Ruch uzyskany na stronach tematycznych stanowi znacznie mniejszą część ogólnego ruchu. Było to więc idealne miejsce do eksperymentowania. Wyniki raportu CrUX i wyniki biznesowe były bardzo zachęcające i skłoniły nas do zwiększenia zakresu działań w całej witrynie w celu uzyskania dalszych korzyści.
Analiza TBT Akamai mPulse
Korzystamy z Akamai mPulse jako rozwiązania RUM, które mierzy TBT w terenie. Zaobserwowaliśmy stały spadek ilości TBT, co wyraźnie odzwierciedla wyniki naszych działań na rzecz ograniczenia INP. Jak widać na zrzucie ekranu poniżej, wartości w polu TBT spadły z około 5 sekund do około 200 milisekund.
Wynik biznesowy
Ogólnie nasze wysiłki, aby 30-krotnie zmniejszyć wartość TBT, wraz z przejściem na Next.js pomogły nam prawie czterokrotnie zmniejszyć wartość INP, co w końcu doprowadziło do spadku współczynnika odrzuceń o 50% i wzrostu liczby odsłon stron tematycznych o 43%.
Podsumowanie
Podsumowując, organizacja INP bardzo pomogła w znalezieniu problemów z wydajnością w czasie działania w niektórych częściach witryny The Times. Jest to jeden z najskuteczniejszych wskaźników poprawiających wyniki biznesowe. Wyniki, które zaobserwowaliśmy w efekcie tych działań, sprawiły nam motywację do tego, by rozszerzyć działania optymalizacyjne na inne obszary witryny i osiągnąć jeszcze większe korzyści.