Gospodarka „The Economic Times” chce naprawić wartość INP

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.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

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.

Dobre wartości INP trwają maksymalnie 200 milisekund, słabe wartości dłuższe niż 500 milisekund, a niektóre z nich wymagają poprawy.

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:

Złożony obraz długich zadań podczas uruchamiania widoczny w panelu wydajności Narzędzi deweloperskich w Chrome oraz raport z danymi stron. Wątek główny jest blokowany podczas wczytywania strony przez 3260 milisekund.
Wątek główny podczas uruchamiania przed zoptymalizowaniem do potwierdzenia. Czas do ustalenia wynosi 3260 milisekund.
.
.
Złożony obraz długich zadań podczas uruchamiania widoczny w panelu wydajności Narzędzi deweloperskich w Chrome oraz raport z danymi stron. Wątek główny jest blokowany podczas wczytywania strony przez 120 milisekund.
Wątek główny podczas uruchamiania po zoptymalizowaniu do ustalenia. Czas do ustalenia wynosi 120 milisekund.

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.

Zrzut ekranu przedstawiający narzędzie pokrycia dostępnego w Narzędziach deweloperskich w Chrome. Tutaj narzędzie wyświetla nieużywane fragmenty plików JavaScript i CSS podczas wczytywania strony.

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.

Zrzut ekranu pokazujący kontrolę rozmiaru DOM w Lighthouse. Liczba zgłoszonych elementów DOM wynosi 2706.

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%:

Zrzut ekranu pokazujący kontrolę INP w CrUX. INP tej strony wynosi 539 milisekund, co przekracza wynik „Słaba” i konkretnego progu.

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.

Zrzut ekranu pokazujący kontrolę INP w CrUX. Wartość INP tej strony wynosi 257 milisekund, co mieści się w zakresie „wymaga ulepszenia”. progów.

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.

Zrzut ekranu przedstawiający rozkłady INP przedstawione w raporcie CrUX na przestrzeni 4 miesięcy, począwszy od lipca 2022 r. do października 2022 r. Wartości w obrębie argumentu „słabe” i „wymaga poprawy” progi nieco się obniżyły, podczas gdy wartości w ramach „dobrej” wartość progowa wzrosła.

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.

Zrzut ekranu wykresu w Akamai mPulse, na którym widać spadek ilości TBT w ciągu około miesiąca.

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%.

Zrzut ekranu pokazujący porównanie liczby odsłon i współczynnika odrzuceń w Google Analytics. Optymalizacja INP na stronie The Economic Times pozwoliła uzyskać 50-procentowy spadek współczynnika odrzuceń i 43-procentowy wzrost liczby odsłon.

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.