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