Total Blocking Tome (TBT) – czym jest, jak sprawdzić i dlaczego jest ważny

TBT, podobnie jak inny Web Vital – TTI (Time to Interactive) – pomaga w zdiagnozowaniu problemów z interaktywnością, co wpływa pozytywnie na jeden z Core Web Vital – FID.

Należy podkreślić, że TBT to laboratoryjny web vital – nie mierzy on więc doświadczeń użytkowników, którzy odwiedzają analizowaną stronę. Jest jednak ważny, ponieważ analizując go zdobędziesz informację o tym, jak szybko strona staje się w pełni interaktywna (a co za tym idzie im niższy wskaźnik TBT, tym lepiej).

Czym jest Total Blocking Time

Total Blocking Time (TBT) to różnica pomiędzy First Contentful Paint (FCP) a Time to Interactive (TTI) w którym główny wątek był zablokowany na tyle długo, aby zapobiec responsywności danych wejściowych.

Wątek uznaje się za zablokowany „na tyle długo”, gdy czas ten wynosi 50 mili sekund (ms). Mówimy, że główny wątek jest „zablokowany”, ponieważ przeglądarka nie może przerwać trwającego zadania. Jeśli więc użytkownik wejdzie w interakcję ze stroną w trakcie długiego zadania, przeglądarka musi poczekać na zakończenie zadania, zanim będzie mogła odpowiedzieć.

Jeżeli zadanie potrwa więc owe 50 ms, to prawdopodobnie użytkownik zauważy opóźnienie i uzna stronę za wolną, co zwiększy prawdopodobieństwo, że ją opuści.

Warto w tym miejscu podkreślić, że całkowity czas blokowania strony to suma czasu blokowania każdego długiego zadania występującego między FCP a TTI.

Jak oblicza się TBT

Popatrzy na hipotetyczny przykład wczytywania głównego wątku na stronie

Mamy tutaj 5 zadań, z których dwa są długie, ponieważ ich czas wykonania przekracza 50 ms.

Zobaczmy teraz, jak się będzie prezentować czas blokady dla każdego z tych zadań (czerwony kolor)

Całkowity czas wyniósł 560 ms, ale TBT to 345 ms, ponieważ:

• zadanie 1 – trwa 250 ms, więc czas blokady dla niego wynosi 200
• zadanie 2 – trwa 90ms, więc czas blokady dla niego wynosi 40
• zadanie 3 – trwa 35 ms, więc czas blokady dla niego wynosi 0
• zadanie 4 – trwa 30 ms, więc czas blokady dla niego wynosi 0
• zadanie 5 – trwa 155 ms, więc czas blokady dla niego wynosi 105

A zatem Total Blocking Time (TBT) dla analizowanego przykładu wynosi 345 ms.

Akceptowalny poziom TBT

Na chwilę pisania tego artykułu wynosi on 200 ms

Jak mierzyć TBT

Najlepszym sposobem pomiaru TBT jest uruchomienie raportu Lighthouse (Performance).

Czy można mierzyć TBT na użytkownikach

Tak, ale chociaż możliwe jest zmierzenie TBT w terenie, nie jest to zalecane, ponieważ interakcja użytkownika może wpłynąć na TBT Twojej strony w sposób prowadzący do wielu rozbieżności w raportach. Aby zrozumieć interaktywność strony w terenie, należy zmierzyć wartość FID oraz INP.

Jak poprawić TBT

Reduce the impact of third-party code (ogranicz wpływ kodu spoza witryny)

Sieci reklamowe, przyciski mediów społecznościowych czy testy A/B wymagają użycia kodu stron trzecich, co wpłynąć potrafi drastycznie na wyniki TBT.

Także i zasoby Google odgrywają tutaj dużą rolę 🙂

Reduce JavaScript execution time (skróć czas wykonywania JavaScript)

Kiedy wykonanie kodu JavaScript zajmuje dużo czasu, działanie strony spowalnia na kilka sposobów:

1. Koszt sieciowy Więcej bajtów oznacza dłuższy czas pobierania.
2. Koszt analizy i kompilacji JavaScript jest analizowany i kompilowany w głównym wątku. Gdy główny wątek jest zajęty, strona nie może odpowiadać na dane wprowadzane przez użytkownika.
3. Koszt wykonania JavaScript jest również wykonywany w głównym wątku. Jeśli na Twojej stronie uruchamia się dużo kodu, zanim będzie on naprawdę potrzebny, opóźnia to również czas przejścia do interakcji, który jest jednym z kluczowych wskaźników związanych z tym, jak użytkownicy postrzegają szybkość Twojej strony.
4. Koszt pamięci Jeśli JavaScript przechowuje wiele odniesień, może potencjalnie zużywać dużo pamięci. Strony wydają się nierówne lub powolne, gdy zużywają dużo pamięci. Wycieki pamięci mogą spowodować całkowite zawieszenie strony.

Minimize main thread work (zminimalizuj aktywność głównego wątku)

Proces renderowania, wykonywany przez przeglądarkę, zmienia kod w stronę internetową, z którą użytkownicy mogą wchodzić w interakcję.

Domyślnie główny wątek procesu renderowania zazwyczaj obsługuje większość kodu: analizuje HTML i buduje DOM, analizuje CSS i stosuje określone style, a także analizuje, ocenia i wykonuje JavaScript. Główny wątek przetwarza także zdarzenia użytkownika. Zatem za każdym razem, gdy główny wątek będzie zajęty czymś innym, Twoja strona internetowa może nie reagować na interakcje użytkowników, co może powodować złe doświadczenia użytkownika, gdy się na niej znajduje.

Powinieneś więc dążyć do uzyskania jak najniższej wartości dla aktywności głównego wątku.

Keep request counts low and transfer sizes small (wykorzystuj minimalną ilość requestów oraz wielkość transferowanych danych)

Aby strona została wyrenderowana, należy wczytać fonty, skrypty, grafiki, kod HTML itp.

Im mniej zasobów jest potrzebnych do wykonania tego zadania, tym lepiej dla Twojej strony, dlatego powinno się dążyć do ich eliminacji (oraz zmniejszenia wielkości wykorzystywanych (transferowanych) zasobów).

Zobacz, jak zoptymalizować ten proces.

TBT a TTI

Warto zwrócić uwagę na powiązanie między TBT a TTI (Time to Interactive).

TTI uważa stronę za „niezawodnie interaktywną”, jeśli główny wątek nie zawierał długich zadań przez co najmniej pięć sekund. Oznacza to, że trzy zadania trwające 51 ms rozłożone na 10 sekund mogą opóźnić TTI tak samo jak jedno zadanie trwające 10 sekund, ale te dwa scenariusze byłyby zupełnie inne dla użytkownika próbującego wejść w interakcję ze stroną.

W pierwszym przypadku trzy zadania trwające 51 ms miałyby TBT wynoszący 3 ms. Podczas gdy pojedyncze zadanie trwające 10 sekund miałoby TBT wynoszący 9950 ms. Większa wartość TBT w drugim przypadku określa ilościowo gorsze doświadczenie.