Total Blocking Time i długie zadania: co blokuje główny wątek przeglądarki

Czym są główny wątek i długie zadania

Główny wątek to miejsce, w którym przeglądarka wykonuje większość swojej pracy przy stronie, a długie zadanie to każda porcja tej pracy trwająca ponad 50 ms. Tak definiuje to dokumentacja Google w opracowaniu Optimize long tasks. Zadaniem jest tam każda odrębna jednostka pracy przeglądarki: analiza kodu HTML i CSS, rysowanie strony, a przede wszystkim uruchamianie JavaScriptu, który bywa największym źródłem zadań.

Kluczowe jest to, że główny wątek obsługuje tylko jedno zadanie naraz. Jeżeli w danej chwili przeglądarka wykonuje skrypt, to kliknięcie w menu, wpisanie litery w formularzu albo dotknięcie przycisku musi poczekać w kolejce na jego zakończenie. Użytkownik widzi wtedy stronę, która wygląda na gotową, ale nie odpowiada. Wyjątkiem są tak zwane web workery, czyli mechanizm pozwalający przenieść część obliczeń poza główny wątek.

Próg 50 ms nie oznacza, że krótsze zadania są niewidoczne dla przeglądarki. Oznacza, że dopiero od tej granicy zadanie uznaje się za na tyle długie, by mogło zauważalnie opóźnić reakcję na działanie użytkownika. Zadanie trwające 70 ms ma zatem 20 ms okresu blokowania, a zadanie trwające 40 ms nie ma go wcale.

Skąd biorą się długie zadania na zwykłej stronie firmowej

Dokumentacja Lighthouse wskazuje dwa typowe źródła długich zadań: niepotrzebne ładowanie, analizowanie i wykonywanie JavaScriptu oraz nieefektywnie napisane instrukcje. Pierwsze jest zwykle znacznie większym polem do poprawy. W praktyce oznacza to kod, który przeglądarka musi pobrać i uruchomić, choć na danej podstronie nie jest potrzebny albo nie jest potrzebny od razu.

Dla zobrazowania przyjmijmy hipotetyczny sklep internetowy z Poznania. Na karcie produktu działa galeria zdjęć, moduł opinii, okno czatu, kilka kodów pomiarowych platform reklamowych i baner zgody na pliki cookie. Każdy z tych elementów z osobna wydaje się niewielki, ale wszystkie uruchamiają się w pierwszych sekundach po otwarciu strony i ustawiają w jednej kolejce do tego samego wątku. Klient, który w tym czasie próbuje wybrać rozmiar, czeka na reakcję, chociaż strona jest już widoczna. O tym, jak poszczególne dodatki obciążają witrynę, piszemy szerzej we wpisie o skryptach zewnętrznych takich jak czaty, piksele i mapy.

Jak powstaje wskaźnik TBT w Lighthouse

TBT powstaje przez zsumowanie okresów blokowania wszystkich długich zadań, które wystąpiły po pierwszym wyrenderowaniu treści. Zgodnie z opisem wskaźnika w serwisie web.dev pomiar zaczyna się w chwili określanej jako First Contentful Paint (FCP, pierwsze wyrenderowanie treści), a Lighthouse domyślnie kończy go w punkcie Time to Interactive (TTI, czas do pełnej interaktywności). TTI przyjmuje, że strona jest stabilnie interaktywna, gdy główny wątek pozostaje bez długich zadań przez co najmniej pięć sekund.

Do sumy nie trafia cały czas trwania zadań, tylko ich nadwyżki ponad 50 ms. Dokumentacja pokazuje to na przykładzie pięciu zadań, który przytaczamy w tabeli.

Z tego sposobu liczenia wynika ważna właściwość wskaźnika. Dokumentacja podaje porównanie: trzy zadania po 51 ms dają TBT równy 3 ms, natomiast jedno zadanie trwające dziesięć sekund daje TBT równy 9950 ms. Liczy się zatem nie tylko to, ile pracy przeglądarka wykonała, lecz przede wszystkim to, czy wykonała ją w krótkich porcjach, pomiędzy którymi mogła obsłużyć użytkownika. Na tym spostrzeżeniu opiera się większość rozwiązań opisanych dalej.

Jakie wartości TBT uznaje się za dobre

Dla urządzeń mobilnych dobry wynik TBT to mniej niż 200 ms, mierzony na przeciętnym sprzęcie mobilnym. Taką wartość podaje opis wskaźnika w serwisie web.dev, a dokumentacja Lighthouse rozpisuje progi osobno dla telefonów i komputerów. Ocena wynika z porównania wyniku badanej strony z wartościami TBT milionów rzeczywistych witryn ładowanych na urządzeniach mobilnych.

TBT ma też duże znaczenie dla ogólnej oceny wydajności w raporcie. Zgodnie z opisem punktacji Lighthouse w wersji dziesiątej narzędzia wskaźnik ten odpowiada za 30 procent oceny, czyli więcej niż każdy z pozostałych składników. Largest Contentful Paint i Cumulative Layout Shift mają po 25 procent, a First Contentful Paint i Speed Index po 10 procent. Strona z szybkim serwerem i lekkimi obrazami może więc otrzymać słabą ocenę wyłącznie z powodu ciężkich skryptów.

Przy odczytywaniu wyniku należy zachować ostrożność z dwóch powodów. Po pierwsze, wynik zmienia się między pomiarami. Dokumentacja wymienia wśród przyczyn testy A/B i zmieniające się reklamy, różnice w trasie ruchu sieciowego, moc urządzenia, na którym uruchomiono test, rozszerzenia przeglądarki oraz programy antywirusowe. Po drugie, ocena w raporcie jest oceną laboratoryjną, a nie opisem tego, co przeżywają odwiedzający. Tę różnicę wyjaśniamy we wpisie o tym, dlaczego wynik testu różni się od danych od użytkowników.

Jak TBT wiąże się z INP

TBT jest laboratoryjnym przybliżeniem INP, ale nie jego zamiennikiem. Interaction to Next Paint (INP, czas od interakcji do kolejnego wyrenderowania) opisuje responsywność strony na podstawie kliknięć, dotknięć i naciśnięć klawiszy podczas całej wizyty. Według dokumentacji tego wskaźnika dobry wynik to 200 ms lub mniej, wynik powyżej 500 ms uznaje się za słaby, a oceny dokonuje się na 75. percentylu wizyt, osobno dla telefonów i komputerów.

Oba wskaźniki mają wspólną przyczynę, czyli zajęty główny wątek. Każda interakcja składa się z trzech części: opóźnienia wejścia, czyli czasu, zanim przeglądarka w ogóle zacznie obsługiwać zdarzenie, czasu przetwarzania oraz opóźnienia prezentacji, po którym na ekranie pojawia się kolejna klatka. Długie zadanie trwające w chwili kliknięcia wydłuża pierwszą z tych części, bo zdarzenie musi poczekać na swoją kolej.

Różnice są jednak istotne. Opis TBT w web.dev zaznacza, że wskaźnik ten może sygnalizować problemy, których użytkownicy nigdy nie odczują, jeżeli w danym momencie nie wykonują żadnej czynności. Może też przeoczyć kłopoty wywołane dopiero przez interakcję, bo standardowy test laboratoryjny tylko ładuje stronę i niczego na niej nie klika. Dokumentacja stwierdza wprost, że niski TBT często współwystępuje z niskim INP, oraz zaleca, by ogólnie optymalizować stronę pod INP, a nie pod sam TBT.

Wniosek dla właściciela witryny jest prosty. TBT służy do pracy warsztatowej: pozwala szybko, bez czekania na dane z ruchu, ocenić wpływ zmiany w kodzie. INP jest miarą docelową, zbieraną u odwiedzających. Jak ją czytać i poprawiać, opisujemy we wpisie o tym, dlaczego strona reaguje z opóźnieniem na kliknięcie.

Gdzie sprawdzić TBT swojej strony

TBT najprościej odczytać w raporcie Lighthouse, który jest dostępny bez opłat w dwóch miejscach: w serwisie PageSpeed Insights oraz w narzędziach deweloperskich przeglądarki Chrome. Dokumentacja wskaźnika zaleca właśnie audyt wydajności Lighthouse jako najlepszy sposób pomiaru w warunkach laboratoryjnych.

W PageSpeed Insights wystarczy wpisać adres badanej podstrony w pole na górze ekranu i uruchomić analizę przyciskiem obok. Po zakończeniu testu w części poświęconej wydajności znajduje się zestaw wskaźników, a wśród nich Total Blocking Time podany w milisekundach, z kolorowym oznaczeniem zgodnym z progami z tabeli powyżej. W polskiej wersji dokumentacji wskaźnik nosi nazwę Całkowity czas blokowania i jest pokazywany w sekcji Wydajność, w części Dane. Sposób czytania całego raportu omawiamy we wpisie o PageSpeed Insights.

Ten sam audyt można uruchomić lokalnie w Chrome, w narzędziach deweloperskich, co bywa wygodniejsze przy stronach w budowie lub dostępnych tylko po zalogowaniu. Opis znajduje się we wpisie o tym, jak uruchomić audyt Lighthouse w Chrome. W obu przypadkach warto testować kilka typów podstron, a nie tylko stronę główną: w sklepie kartę produktu, listę kategorii i koszyk, w serwisie usługowym stronę oferty i stronę kontaktu. Każdy z tych szablonów ładuje inny zestaw skryptów.

Które pozycje raportu wiążą się z TBT

Poniżej wskaźników raport pokazuje część diagnostyczną. Z TBT najściślej wiążą się dwie pozycje wymienione w dokumentacji: Minimize main thread work, czyli ograniczenie pracy głównego wątku, oraz Reduce JavaScript execution time, czyli skrócenie czasu wykonywania JavaScriptu. Obie rozwijają się do listy, która pokazuje, na co przeglądarka zużyła czas i które pliki kosztowały najwięcej. To dobry punkt wyjścia do rozmowy z programistą, choć jeszcze nie wskazanie konkretnej funkcji w kodzie. Do tego służy panel Wydajność.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jak w panelu Wydajność wskazać skrypt odpowiedzialny za blokadę

Skrypt odpowiedzialny za blokadę wskazuje nagranie ładowania strony w panelu Wydajność narzędzi deweloperskich Chrome, gdzie każde długie zadanie jest oznaczone czerwonym trójkątem. Narzędzia otwiera się skrótem Control, Shift i I w systemach Windows i Linux albo Command, Option i I na komputerach Mac. Polska dokumentacja panelu radzi pracować w oknie incognito, aby rozszerzenia przeglądarki nie zakłócały pomiaru.

1. Ustawienie warunków pomiaru

   W panelu Wydajność należy otworzyć Ustawienia rejestrowania i w polu CPU wybrać spowolnienie procesora, na przykład 4-krotne. Spowolnienie jest liczone względem mocy własnego komputera, więc przybliża zachowanie słabszego telefonu, ale go nie odwzorowuje.

2. Nagranie ładowania strony

   Przycisk nagrywania z ponownym wczytaniem (w angielskiej wersji Record and reload) rejestruje całe ładowanie od pustej karty i sam zatrzymuje się kilka sekund po jego zakończeniu. Zwykły przycisk Nagrywaj służy do rejestrowania działań na już otwartej stronie i kończy się przyciskiem Zatrzymaj.

3. Odszukanie długich zadań

   W ścieżce Główna widoczne są bloki opisane jako Zadanie. Długie zadania mają czerwony trójkąt w prawym górnym rogu, a część bloku przekraczająca 50 ms jest zacieniowana na czerwono. Im dłuższy zacieniowany fragment, tym większy wkład zadania w TBT.

4. Zejście w głąb zadania

   Pod blokiem zadania układają się kolejne warstwy wykresu. Oś pozioma oznacza czas, oś pionowa stos wywołań: zdarzenia położone wyżej wywołują te pod spodem. Kliknięcie dowolnej warstwy pokazuje na karcie Podsumowanie czas trwania, odnośnik do pliku źródłowego i adres, z którego skrypt pochodzi.

5. Ustalenie, czyj to kod

   Pole wyboru Dim 3rd parties wyszarza zdarzenia pochodzące z obcych domen, dzięki czemu od razu widać, czy blokadę powoduje kod witryny, czy dodatek zewnętrzny. Po zaznaczeniu zakresu nagrania karta Podsumowanie pokazuje też tabelę 1st / 3rd party z czasem głównego wątku zużytym przez każdego dostawcę.

Nazwy części elementów podajemy po angielsku, ponieważ tak występują w opisie funkcji panelu. W polskiej wersji interfejsu mogą być przetłumaczone.

Karty z zestawieniami czasu

Pod wykresem znajdują się trzy karty porządkujące to samo nagranie na różne sposoby. Karta Bottom-up pokazuje czynności, które bezpośrednio zużyły najwięcej czasu, zsumowane ze wszystkich wystąpień. Karta Call tree przedstawia czynności główne wraz z tym, co wywołały. Karta Event log wymienia je w kolejności chronologicznej. W każdej są dwie kolumny, które łatwo pomylić: Self Time to czas spędzony bezpośrednio w danej czynności, a Total Time obejmuje także wszystko, co ta czynność uruchomiła.

Do wskazania winnego najbardziej przydaje się karta Bottom-up. W tabeli 1st / 3rd party przy każdym dostawcy znajduje się przycisk, który otwiera tę kartę z czynnościami zgrupowanymi według danego podmiotu.

Co najczęściej blokuje główny wątek

Główny wątek blokuje najczęściej JavaScript, który uruchamia się zaraz po otwarciu strony, a dużą jego część stanowi kod firm trzecich. Opracowanie Google o ładowaniu skryptów zewnętrznych wymienia wśród typowych kłopotów ciężki JavaScript, który długo zajmuje główny wątek, dużą liczbę żądań do wielu serwerów oraz to, że kilka osadzonych dodatków potrafi pobrać te same biblioteki po kilka razy.

W praktyce agencji długie zadania na stronach firmowych wywołują zwykle te same grupy elementów. Są to obserwacje z naszej pracy, a nie dane z dokumentacji:

• okna czatu i widgety kontaktowe uruchamiane na każdej podstronie od pierwszej sekundy,
• kody pomiarowe i reklamowe dodawane latami do menedżera tagów i nigdy nieusuwane,
• baner zgody na pliki cookie, który startuje jako jeden z pierwszych skryptów,
• suwaki, karuzele i animacje wczytujące duże biblioteki dla jednego efektu,
• wtyczki systemu zarządzania treścią ładowane na wszystkich podstronach, choć działają na jednej,
• osadzone mapy, filmy i formularze zewnętrznych usług.

Osobnego omówienia wymaga menedżer tagów. Dokumentacja Google zaleca korzystanie z niego z rozwagą, ponieważ nadmiar tagów i automatycznych nasłuchiwaczy zdarzeń zwiększa obciążenie strony, oraz radzi ograniczyć grono osób, które mogą dodawać skrypty. Jak zaprowadzić w nim porządek, opisujemy we wpisie o tym, jak Google Tag Manager wpływa na szybkość strony, a wpływ okna zgód omawia wpis o banerze zgody na pliki cookie.

Drugim źródłem są nieefektywne instrukcje we własnym kodzie witryny. Dokumentacja Lighthouse podaje przykład zapytania, które wybiera wszystkie odnośniki na stronie i zwraca dwa tysiące elementów, podczas gdy dokładniejszy selektor zwróciłby dziesięć.

Jakie rozwiązania stosują programiści

Programiści obniżają TBT na trzy sposoby: dzielą długie zadania na krótsze, opóźniają kod, który nie jest potrzebny na starcie, oraz usuwają kod zbędny. Dokumentacja Lighthouse wymienia w tym kontekście dzielenie kodu na części ładowane wtedy, gdy są potrzebne, usuwanie nieużywanego kodu i wydajne ładowanie JavaScriptu firm trzecich.

Dzielenie długich zadań

Samo rozłożenie kodu na mniejsze funkcje nie wystarcza. Opracowanie o optymalizacji długich zadań wyjaśnia, że funkcje wywołane z jednej funkcji nadrzędnej nadal wykonują się jako jedno zadanie, bo JavaScript doprowadza rozpoczętą pracę do końca. Potrzebne jest oddanie sterowania głównemu wątkowi, czyli celowa przerwa, w której przeglądarka może obsłużyć kliknięcie i narysować zmianę na ekranie, zanim wróci do reszty pracy.

Starszym sposobem jest funkcja setTimeout, która przenosi fragment kodu do osobnego zadania. Ma jednak wady: odłożona praca trafia na koniec kolejki, a po pięciu zagnieżdżonych wywołaniach przeglądarka dolicza do każdego kolejnego co najmniej 5 ms opóźnienia. Nowszym rozwiązaniem jest scheduler.yield, czyli funkcja, po której dalsza część przerwanej pracy ma pierwszeństwo przed innymi podobnymi zadaniami. Dokumentacja podaje, że działa ona w Chrome i Edge od wersji 129 oraz w Firefoksie od wersji 142, a Safari jej nie obsługuje, dlatego stosuje się wariant zapasowy.

async function saveSettings () {
  // Praca widoczna dla użytkownika, wykonywana od razu:
  validateForm();
  showSpinner();
  updateUI();

  // Przerwa: przeglądarka może obsłużyć kliknięcia i odrysować ekran
  await scheduler.yield();

  // Praca niewidoczna, dokończona w osobnym zadaniu:
  saveToDatabase();
  sendAnalytics();
}

Zasada jest więc taka: najpierw to, co użytkownik ma zobaczyć, potem przerwa, a na końcu praca w tle, na przykład zapis danych i wysłanie statystyk. Dokumentacja odradza przy tym robienie przerwy po każdej funkcji i wspomina o grupowaniu pracy w porcje z limitem czasu, zwykle około 50 ms.

Opóźnianie i usuwanie kodu

Drugą grupą działań jest przesunięcie pracy w czasie. Skrypty firm trzecich, które nie są niezbędne do wyświetlenia strony, powinny mieć atrybut async albo defer. Różnice między nimi wyjaśnia wpis o JavaScripcie blokującym renderowanie. Reklamy, filmy i inne osadzone elementy można ładować dopiero wtedy, gdy użytkownik do nich dotrze. Dokumentacja ostrzega zarazem, by ostrożnie opóźniać kody analityczne, bo można utracić dane z początku wizyty.

Trzecia grupa jest najprostsza i zwykle najskuteczniejsza. Jeżeli skrypt nie wnosi wyraźnej wartości, dokumentacja zaleca go usunąć. Dotyczy to nieużywanych tagów, wtyczek dublowanych przez motyw oraz bibliotek pozostawionych po dawnych funkcjach strony.

Czego wymagać od dostawców skryptów i wykonawcy strony

Od dostawców należy wymagać przede wszystkim tego, by ich kod dało się załadować późno, warunkowo i bez długich zadań na starcie, a od wykonawcy strony - pomiaru przed wdrożeniem i po nim. Właściciel firmy nie musi czytać kodu, ale może zadać pytania, na które rzetelny dostawca odpowie konkretnie.

Wyobraźmy sobie kancelarię z Krakowa, która wybiera narzędzie do rezerwacji terminów, albo hydraulika z Łodzi, któremu zaproponowano okno czatu na stronie. Decyzja zapada zwykle na podstawie funkcji i ceny, a pytanie o wpływ na szybkość reakcji strony nie pada wcale. Tymczasem ten jeden dodatek może przesądzić o wyniku TBT na wszystkich podstronach. Poniższa lista porządkuje oczekiwania, które warto przedstawić przed podpisaniem umowy lub przed instalacją dodatku.

• Możliwość ładowania skryptu z atrybutem async lub defer, bez wymogu umieszczania go na samym początku kodu strony.
• Możliwość uruchomienia dodatku dopiero po działaniu użytkownika, na przykład po kliknięciu ikony czatu, zamiast przy każdym otwarciu strony.
• Możliwość włączenia dodatku tylko na wybranych podstronach, a nie w całym serwisie.
• Informacja, ile czasu głównego wątku zajmuje skrypt podczas ładowania, potwierdzona nagraniem z panelu Wydajność przy spowolnionym procesorze.
• Informacja, jakie dodatkowe biblioteki i skrypty innych firm dodatek pobiera samodzielnie.
• Jasna procedura usunięcia kodu po zakończeniu współpracy lub kampanii.

Wobec wykonawcy strony lub sklepu oczekiwania są podobne, tylko dotyczą całości. W umowie lub specyfikacji warto zapisać, na jakich szablonach podstron i w jakich warunkach będzie mierzony TBT, oraz że każda nowa wtyczka i każdy nowy tag są dodawane po pomiarze porównawczym. Dokumentacja Google radzi mierzyć co najmniej trzykrotnie, ponieważ skrypty firm trzecich mogą przy każdym ładowaniu pobierać inne zasoby.

Typowe pomyłki i sytuacje, w których potrzebna jest pomoc

Najczęstszą pomyłką jest traktowanie TBT jako celu samego w sobie, podczas gdy jest to narzędzie diagnostyczne służące poprawie realnej responsywności. Dokumentacja wskaźnika wprost zaleca optymalizację pod INP. Pogoń za zielonym kolorem w raporcie prowadzi czasem do zabiegów, które poprawiają liczbę w teście, a nie doświadczenie odwiedzających.

Druga pomyłka to wyciąganie wniosków z jednego pomiaru. Wynik zależy od urządzenia, sieci, rozszerzeń i tego, jaką reklamę lub wariant testu wyświetlono danym razem, dlatego porównywać należy serie pomiarów wykonane w tych samych warunkach. Trzecia polega na badaniu wyłącznie strony głównej, choć podstrony ofert, kategorii i produktów ładują inne zestawy skryptów.

Czwarta pomyłka dotyczy sposobu naprawy. Przesunięcie wszystkich skryptów na później bez sprawdzenia skutków potrafi zepsuć pomiar ruchu, zbieranie zgód albo działanie koszyka. Piąta wynika z mylenia pojęć: skrypt, który nie blokuje renderowania, nadal może blokować główny wątek. Atrybut defer zmienia moment uruchomienia kodu, ale nie skraca jego wykonywania.

Kiedy warto zwrócić się po wsparcie

Pomoc specjalisty przydaje się, gdy TBT pozostaje w czerwonym przedziale mimo usunięcia oczywistych dodatków, gdy długie zadania pochodzą z kodu motywu lub platformy sklepowej, a nie z obcych skryptów, albo gdy dane od użytkowników pokazują słaby INP przy poprawnym wyniku laboratoryjnym. Podobnie jest wtedy, gdy za stronę odpowiada kilku wykonawców i każdy wskazuje na pozostałych. Nagranie z panelu Wydajność rozstrzyga taki spór, ale trzeba je umieć odczytać i przełożyć na listę zadań dla programistów.

W ramach SEO technicznego analizujemy nagrania ładowania najważniejszych szablonów, wskazujemy skrypty odpowiedzialne za blokady i przygotowujemy zalecenia w kolejności od największego wpływu. Jeżeli wydajność jest jednym z wielu wątków do uporządkowania, lepszym punktem wyjścia bywa audyt SEO. Szerszy obraz wskaźników jakości strony daje wpis o tym, jak poprawić Core Web Vitals.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl