requestIdleCallback nie znaczy „później”. Kosztowało mnie 200 ms TBT

👁 116 przeczytań

Przeniosłem kilka niekrytycznych zapytań w tle do requestIdleCallback z parametrem timeout: 3000. TBT sklepu wzrosło z 64 do 265 ms, a start zapytań przesunął się z przedziału 183-1329 ms na 383-2411 ms. Zmianę wycofałem tego samego dnia.

Co dokładnie odroczyłem

Sklep na WordPressie, strona kategorii. Na starcie odpalało się kilka zapytań pobocznych - takich, których wynik nie jest potrzebny do pierwszego renderu ani do pierwszej interakcji. Klasyczny kandydat do przeniesienia na później.

Zamiast zostawić je tam, gdzie były, owinąłem każde w requestIdleCallback z limitem 3000 ms. Logika wydawała się szczelna: przeglądarka wykona je, gdy będzie miała chwilę, a jeśli przez trzy sekundy nie znajdzie okna bezczynności, i tak je odpali - więc nic się nie zgubi.

Problem polega na tym, że drugi warunek okazał się tym decydującym. Przeglądarka nie znalazła sensownego okna bezczynności w trakcie ładowania strony sklepu (co przy takiej liczbie skryptów firm trzecich nie jest zaskoczeniem), więc każdy callback czekał na swój deadline. A deadline’y były podobne, bo rejestracja nastąpiła w krótkim odstępie.

Liczby przed i po - optymalizacja JavaScript, która pogorszyła wynik

Najciekawszy wiersz to rozrzut. Przed zmianą zapytania startowały naturalnie, rozłożone na przestrzeni ponad sekundy - każde w swoim momencie, w luce między innymi zadaniami. Po zmianie przesunęły się dalej w czasie, ale przestały być rozproszone: odpaliły jedną serią pod koniec okna, w którym Lighthouse sumuje blokowanie wątku głównego.

Czterokrotny wzrost TBT nie wziął się z tego, że kod zaczął robić więcej pracy. Pracy było tyle samo. Zmieniło się tylko jej rozłożenie - z rozrzuconej na skupioną. TBT karze właśnie skupienie, bo liczy nadwyżkę ponad 50 ms w obrębie jednego długiego zadania. Pięć zadań po 40 ms to zero wkładu do TBT. To samo pięć zadań zlepione w jedno 200-milisekundowe to 150 ms kary.

Dlaczego timeout zbiera pracę w kupę

Mechanika jest prosta, gdy się ją raz zobaczy. requestIdleCallback ma dwa tryby wykonania:

• Tryb bezczynności - przeglądarka znalazła lukę w wątku głównym i woła callback z sensownym timeRemaining(). To ten tryb, o którym wszyscy myślą.
• Tryb wymuszony - minął timeout, callback jest wołany niezależnie od stanu wątku, a didTimeout jest ustawione na true. timeRemaining() zwraca wtedy zero.

Jeśli strona jest zajęta przez cały okres ładowania - a strona sklepu z wtyczkami i skryptami zewnętrznych dostawców zwykle jest - to tryb pierwszy nie zachodzi ani razu. Wszystko wykonuje się w trybie wymuszonym. I tu pojawia się efekt kumulacji: skoro każdy callback ma ten sam limit, a rejestrowane są w krótkim odstępie, to ich terminy wypadają niemal równocześnie. Przeglądarka odpala je jeden po drugim w tym samym tasku albo w serii tasków bez oddechu między nimi.

Innymi słowy: im bardziej zajęta strona, tym bardziej timeout działa jako synchronizator, a nie jako bufor bezpieczeństwa.

Kiedy requestIdleCallback ma sens, a kiedy nie

Poniżej moja ocena na podstawie tego jednego pomiaru - traktujcie to jako opinię, nie jako regułę potwierdzoną na wielu wdrożeniach.

Dla mnie najważniejsza lekcja brzmi tak: jeśli piszesz timeout, to znaczy, że zadanie musi się wykonać. A jeśli musi się wykonać, to requestIdleCallback jest złym narzędziem - lepszym jest zwykłe rozłożenie pracy w czasie z jawnym odstępem, tak żeby zadania nie sklejały się w jeden blok.

Co zrobiłem zamiast tego

Wycofałem zmianę i wróciłem do stanu wyjściowego z TBT 64 ms. Zapytania odpalają się w przedziale 183-1329 ms, rozłożone naturalnie, i to jest wynik lepszy niż cokolwiek, co osiągnąłem przez odraczanie ich hurtem.

To kontrintuicyjny wniosek dla kogoś, kto szuka poprawy TBT na WordPressie: nie każde przeniesienie kodu „na później” pomaga. Liczy się nie to, kiedy kod się wykonuje, ale czy jest rozproszony. Rozproszona praca na wczesnym etapie bije skupioną pracę na późniejszym.

Jak to sprawdzić u siebie

1. Otwórz DevTools, zakładka Performance, i nagraj ładowanie strony z opcją twardego odświeżenia oraz z dławieniem CPU - bez dławienia nie zobaczysz efektu kumulacji, bo szybka maszyna znajdzie okna bezczynności.
2. W nagraniu znajdź wszystkie wywołania swoich odroczonych callbacków i zanotuj czas startu każdego z nich. Interesuje cię rozrzut, nie średnia. U mnie przed zmianą było to 183-1329 ms, po zmianie 383-2411 ms.
3. W samym callbacku zaloguj wartość deadline.didTimeout. Jeśli w każdym wywołaniu widzisz true, to twoje zadania w ogóle nie korzystają z bezczynności - wykonują się wyłącznie przez limit czasu i sklejają się w serię.
4. Zmierz TBT przed i po zmianie na tej samej wersji strony, w tych samych warunkach sieciowych, minimum kilka przebiegów. Różnica między 64 a 265 ms jest tak duża, że wyjdzie od razu, ale mniejsze regresje giną w szumie.
5. Jeśli TBT wzrosło, usuń parametr timeout i zmierz ponownie. To najtańszy test hipotezy o kumulacji - jeśli bez limitu TBT wraca do normy, masz potwierdzenie.
6. Jeśli mimo to zadania muszą się wykonać w określonym czasie, porzuć requestIdleCallback i rozłóż je jawnie, dodając odstęp między kolejnymi - chodzi o to, żeby żadne pojedyncze zadanie nie przekroczyło 50 ms i żeby między nimi wątek główny dostał oddech.