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

30-krotne ograniczenie TBT i przejście na Next.js pomogło The Ecomonic Times zredukować wartość INP niemal 4-krotnie, co doprowadziło do 50-procentowego spadku współczynnika odrzuceń i 43% wzrostu liczby odsłon.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

Interakcja z kolejnym wyrenderowaniem (INP) to dane, które pozwalają ocenić responsywność witryny w odniesieniu do danych wejściowych użytkownika. Dobra responsywność oznacza, że strona szybko reaguje na interakcje użytkowników. Im niższy wartość INP strony, tym lepiej potrafi ona reagować na interakcje użytkowników.

Dobre wartości INP to 200 milisekund lub mniej, niskie – więcej niż 500 milisekund, a wszystkie pozostałe wymagają poprawy.

Niewyraźny początek

Gdy firma Google po raz pierwszy wprowadziła INP jako eksperymentalne dane, które mogą ewoluować w jeden z podstawowych wskaźników internetowych, zespół Economic Times postanowił rozwiązać ten problem, zanim przejdzie na jego standardową wersję, ponieważ zapewnienie użytkownikom na całym świecie komfortu obsługi jest kluczowym elementem naszych podstawowych wartości biznesowych.

INP jest jak dotąd jednym z najtrudniejszych wskaźników do rozwiązania. Na początku nie miałem pewności, jak skutecznie mierzyć wartość INP. Utrudniał w ten sposób brak wsparcia społeczności, w tym większość dostawców usługi Real User Monitoring (RUM), którzy jeszcze jej nie obsługują. Mieliśmy jednak narzędzia Google RUM, takie jak Raport na temat użytkowania Chrome (CrUX), biblioteka JavaScript web-vitals i inne, które dały nam wgląd w to, na jakiej drodze stoimy podczas analizowania ścieżki. Gdy zaczynaliśmy,wartość INP na poziomie początkowym była bliska 1000 milisekund.

Podczas poprawiania wartości INP w polu pojawiła się pewna informacja, że jednym z wskaźników modułu, na które warto kierować reklamy, jest Całkowity czas blokowania (TBT). Program TBT został już dobrze udokumentowany i wspierany przez społeczność. Mimo że osiągnęliśmy już progi dotyczące podstawowych wskaźników internetowych, nie radziliśmy sobie tak dobrze w przypadku TBT, ponieważ zaczynaliśmy dopiero po ponad 3 sekundach.

Czym jest TBT i jakie kroki podjęliśmy, aby go ulepszyć?

TBT to wskaźnik laboratoryjny, który mierzy responsywność strony internetowej w odniesieniu do danych wejściowych użytkownika podczas jej wczytywania. Każde zadanie, które trwa dłużej niż 50 milisekund, jest uznawane za długie, a czas po przekroczeniu progu 50 milisekund to czas blokowania.

Do obliczenia jest brana pod uwagę suma czasu blokowania wszystkich długich zadań podczas wczytywania strony. Jeśli na przykład podczas wczytywania wykonywane są 2 długie zadania, czas blokowania jest określany w ten sposób:

  • Zadanie A zajmuje 80 milisekund (30 milisekund niż 50 milisekund).
  • Zadanie B zajmuje 100 milisekund (50 milisekund niż 50 milisekund).

Wartość TBT strony będzie wynosić: 80 milisekund (30 + 50). Im niższa wartość TBT, tym lepiej. Te dane są dobrze powiązane z INP.

Oto krótkie porównanie wersji TBT przed i po podjęciu działań w celu jego poprawy.

Obraz złożony przedstawiający długie zadania podczas uruchamiania widoczny w panelu wydajności Narzędzi deweloperskich w Chrome oraz raport ze statystykami strony. Wątek główny jest blokowany podczas wczytywania strony na 3260 milisekund.
Wątek główny podczas uruchamiania przed optymalizacją TBT. Wartość TBT wynosi 3260 milisekund.
Obraz złożony przedstawiający długie zadania podczas uruchamiania widoczny w panelu wydajności Narzędzi deweloperskich w Chrome oraz raport ze statystykami strony. Wątek główny jest blokowany podczas wczytywania strony na 120 milisekund.
Wątek główny podczas uruchamiania po optymalizacji TBT. Wartość TBT wynosi 120 milisekund.

Zminimalizuj aktywność głównego wątku

Główny wątek przeglądarki obsługuje wszystkie zadania – od analizy kodu HTML przez tworzenie modelu DOM, przez analizowanie CSS i stosowanie stylów, a także ocenianie i wykonywanie JavaScriptu. Wątek główny obsługuje też interakcje użytkowników, tj. kliknięcie, dotknięcie i naciśnięcia klawiszy. Jeśli wątek główny zajmuje się innymi zadaniami, może on nie reagować prawidłowo na dane wejściowe użytkownika, co może utrudniać jego obsługę.

Było to dla nas najtrudniejsze zadanie, ponieważ mamy własne algorytmy do wykrywania tożsamości użytkowników na potrzeby wyświetlania reklam na podstawie stanu subskrypcji oraz zewnętrzne skrypty do testów A/B, analityki i innych elementów.

Na początku wprowadziliśmy niewielkie zmiany, na przykład zmniejszyliśmy priorytet wczytywania mniej ważnych komponentów biznesowych. Po drugie, użyliśmy requestIdleCallback do mniej ważnych zadań, co pozwoliło zredukować 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 korzystania z metody requestIdleCallback zalecane jest określenie czasu oczekiwania, bo dzięki niemu, jeśli dany czas upłynął, a wywołanie zwrotne nie zostało jeszcze wywołane, wywołanie zwrotne zostanie wykonane natychmiast po upływie limitu czasu.

Minimalizuj czas oceny skryptu

Leniwe ładowanie bibliotek zewnętrznych również odbywa się za pomocą wczytywanych komponentów. Usunęliśmy też nieużywany kod JavaScript i CSS przez profilowanie strony za pomocą narzędzia do wykrywania treści w Chrome DevTools. Pomogło nam to zidentyfikować obszary, w których potrzeba trzęsienia drzew, aby przesłać mniej kodu podczas wczytywania strony, i tym samym zmniejszyć początkowy pakiet aplikacji.

Zrzut ekranu przedstawiający narzędzie Pokrycie w Narzędziach deweloperskich w Chrome. Wyświetla ono nieużywane fragmenty plików JavaScript i CSS podczas wczytywania strony.

Zmniejsz rozmiar DOM

Duże rozmiary DOM zwiększają użycie pamięci według narzędzia Lighthouse, dłuższe przeliczenia stylów i kosztowne przeformatowanie układu.

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

Zmniejszyliśmy liczbę węzłów DOM na 2 sposoby:

  • Najpierw renderowaliśmy pozycje menu na prośbę użytkownika (po kliknięciu). Zmniejszono rozmiar DOM o około 1200 węzłów.
  • Po drugie, leniwie wczytywaliśmy mniej ważne widżety.

Dzięki tym wszystkim wysiłkom znacznie ograniczyliśmy wartość TBT i nasz wskaźnik INP został odpowiednio zmniejszony o prawie 50%:

Zrzut ekranu pokazujący audyt INP w CrUX Wartość INP strony wynosi 539 milisekund i przekracza próg „słabej jakości”.

Tym razem prawie nie udało nam się z łatwością obniżyć wartości TBT (i INP przez proxy), ale wiedzieliśmy, że mamy jeszcze sporo do poprawy. Zdecydowaliśmy się więc uaktualnić nasz niestandardowy schemat interfejsu do najnowszej wersji React i Next.js, aby lepiej wykorzystywać zarzuty i uniknąć niepotrzebnego ponownego renderowania komponentów.

Ze względu na częstsze aktualizacje i znacznie mniejszy ruch w porównaniu z innymi częściami witryny rozpoczęliśmy migrację stron tematycznych do Next.js. Wykorzystaliśmy też PartyTown, aby odciążyć pracowników sieciowych dodatkową pracę w wątkach głównych, a także techniki takie jak requestIdleCallBack do odroczania niekrytycznych zadań.

Jak poprawa wartości INP pomogła „The Economic Times”?

Bieżąca wartość TBT i INP w punkcie początkowym

W momencie publikacji tego posta wartość TBT naszego źródła wynosiła 120 milisekund, czyli 3260 milisekund w momencie rozpoczęcia działań optymalizacyjnych. Analogicznie wartość INP naszego źródła wyniosła 257 milisekund po przeprowadzeniu optymalizacji, czyli z ponad 1000 milisekund.

Zrzut ekranu pokazujący audyt INP w CrUX INP tej strony wynosi 257 milisekund i mieści się w granicach „potrzebnej poprawy”.

Trend INP CrUX

Ruch otrzymywany na stronach tematycznych stanowi znacznie mniejszy odsetek całego ruchu. Dlatego było to idealne miejsce do eksperymentowania. Wyniki raportu na temat użytkowania Chrome wraz z wynikami biznesowymi były bardzo zachęcające i skłoniły nas do objęcia wysiłkami w całej witrynie, co pozwoliło nam jeszcze bardziej zwiększyć korzyści.

Zrzut ekranu z rozkładami INP przedstawionymi w raporcie CrUX w okresie 4 miesięcy – od lipca do października 2022 r. Wartości w progach „niska” i „wymagana poprawa” nieco spadły, podczas gdy wartości w przedziale „dobra” uległy zwiększeniu.

Analiza Akamai mPulse TBT

Używamy Akamai mPulse jako rozwiązania RUM, które mierzy TBT w terenie. Zaobserwowaliśmy stały spadek wartości TBT, co wyraźnie odzwierciedla efekty naszych wysiłków zmierzających do ograniczenia wartości INP. Jak widać na zrzucie ekranu poniżej, wartości TBT w końcu spadły z 5 sekund do około 200 milisekund.

Zrzut ekranu z wykresem w Akamai mPulse, który przedstawia spadek wartości TBT w ciągu około miesiąca.

Wynik biznesowy

Nasze wysiłki związane z 30-krotnym zmniejszeniem wartości TBT oraz przejście na Next.js pomogły nam prawie 4-krotnie zmniejszyć wartość INP, co doprowadziło do 50% spadku współczynnika odrzuceń i 43% wzrostu liczby odsłon na stronach tematów.

Zrzut ekranu z Google Analytics porównującym liczbę odsłon i współczynnik odrzuceń. Dzięki optymalizacji INP w witrynie The Economic Times odnotowaliśmy spadek współczynnika odrzuceń o 50% i wzrost liczby odsłon o 43%.

Podsumowanie

Podsumowując, INP pomogło w znalezieniu problemów z wydajnością w czasie działania niektórych części strony Economic Times. Jest to jeden z najskuteczniejszych wskaźników pozytywnie wpływających na wyniki biznesowe. Ze względu na bardzo obiecujące wyniki, które zaobserwowaliśmy w wyniku tych działań, motywujemy się do zwiększenia skuteczności naszych działań optymalizacyjnych o inne obszary witryny i osiągnięcie dodatkowych korzyści.