Jak liczy się TBT
Długie zadanie to każda praca na głównym wątku, która trwa ponad 50 ms. W tym czasie przeglądarka nie obsłuży kliknięcia ani wpisania znaku. Za blokujący uznaje się tylko nadmiar ponad 50 ms: zadanie trwające 120 ms dodaje do TBT 70 ms, a zadanie 45 ms nie dodaje nic.
W przykładzie poniżej zadania trwają łącznie 525 ms, ale TBT wynosi 330 ms. Jedno zadanie o długości 300 ms waży najwięcej, bo przez cały ten czas wątek nie może zareagować na użytkownika.
Zadanie A: 120 ms → 120 − 50 = 70 ms
Zadanie B: 45 ms → poniżej progu = 0 ms
Zadanie C: 300 ms → 300 − 50 = 250 ms
Zadanie D: 60 ms → 60 − 50 = 10 ms
──────────────────────────────────────
TBT: 330 msProgi TBT w Lighthouse
Od Lighthouse 10 TBT ma 30% wagi w wyniku Performance, najwięcej ze wszystkich metryk. LCP i CLS mają po 25%, a FCP i Speed Index po 10%. Dlatego praca JavaScriptu na głównym wątku mocno wpływa na ten wynik.
web.dev zaleca TBT poniżej 200 ms w teście na przeciętnym sprzęcie mobilnym.
| Urządzenie | Dobry | Do poprawy | Słaby |
|---|---|---|---|
| Mobile | 0–200 ms | 200–600 ms | powyżej 600 ms |
| Desktop | 0–150 ms | 150–350 ms | powyżej 350 ms |
TBT, INP i Core Web Vitals
Core Web Vitals to LCP, INP i CLS. TBT do nich nie należy, ale pomaga w laboratorium przewidzieć problemy z INP: długie zadania, które zawyżają TBT, opóźniają też reakcję na kliknięcia.
Obie metryki mierzą co innego. TBT obejmuje ładowanie strony do momentu TTI w jednym, kontrolowanym teście. INP obejmuje interakcje przez całą wizytę, na urządzeniach prawdziwych użytkowników. web.dev nie zaleca mierzenia TBT w terenie, bo interakcje użytkowników zaburzają wynik. Do oceny responsywności w terenie używaj INP z CrUX albo z własnego RUM.
Jak skrócić TBT
- Dziel długie zadania. Oddawaj główny wątek przeglądarce między porcjami pracy, np. przez scheduler.yield() z fallbackiem do setTimeout().
- Wysyłaj mniej JavaScriptu. Usuń nieużywany kod i dziel paczki (code splitting), żeby na starcie wykonywało się tylko to, co potrzebne.
- Ogranicz i opóźnij skrypty zewnętrzne. Tagi reklamowe, czaty i widżety często dokładają własne długie zadania.
- Upraszczaj kosztowny kod, np. zawężaj selektory, żeby skrypt nie przeglądał tysięcy węzłów DOM.
- Nie licz na samą minifikację. Zmniejsza liczbę przesyłanych bajtów, ale nie usuwa pracy skryptu. TBT spada, gdy na głównym wątku wykonuje się mniej kodu albo w krótszych porcjach.
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}
async function processItems(items) {
for (const item of items) {
processItem(item);
// Przeglądarka może teraz obsłużyć kliknięcie
await yieldToMain();
}
}Jak mierzyć TBT
Uruchom Lighthouse w Chrome DevTools albo PageSpeed Insights i odczytaj TBT w sekcji metryk. Porównuj kilka przebiegów na tym samym profilu urządzenia, bo wynik pojedynczego testu się waha. Panel Performance w DevTools pokazuje konkretne długie zadania, więc łatwo znaleźć skrypt, który blokuje wątek.
Total Blocking Time (TBT) to laboratoryjna metryka, która sumuje czas blokowania głównego wątku między FCP a TTI. Liczy się tylko nadmiar ponad 50 ms w każdym długim zadaniu. Im wyższy TBT, tym dłużej strona w teście nie mogła reagować na użytkownika.
Według progów Lighthouse dobry TBT to 0–200 ms na mobile i 0–150 ms na desktopie. Wynik powyżej 600 ms na mobile albo 350 ms na desktopie Lighthouse uznaje za słaby.
Nie. Core Web Vitals to LCP, INP i CLS. TBT jest metryką laboratoryjną, którą Lighthouse wlicza do wyniku Performance z wagą 30%. W laboratorium służy jako przybliżenie INP.
TBT mierzy blokowanie głównego wątku podczas ładowania w kontrolowanym teście, bez prawdziwych interakcji. INP mierzy opóźnienie reakcji na kliknięcia, dotknięcia i klawisze przez całą wizytę realnych użytkowników. TBT pomaga szukać przyczyn, INP pokazuje efekt w terenie.
Test laboratoryjny kończy pomiar TBT po załadowaniu strony, a INP obejmuje też interakcje później, np. otwieranie filtrów czy koszyka. Użytkownicy mają też słabsze urządzenia niż profil testu. Sprawdź, które interakcje są wolne, w danych RUM albo w panelu Performance.
Podziel długie zadania, oddając wątek przeglądarce, usuń nieużywany JavaScript i dziel paczki, ogranicz skrypty zewnętrzne i uprość kosztowny kod. Po każdej zmianie porównaj kilka przebiegów Lighthouse na tym samym profilu urządzenia.
Źródła i dalsza lektura
- web.dev: Total Blocking Time (TBT) dokumentacja
- Chrome for Developers: Lighthouse: Total Blocking Time dokumentacja
- Chrome for Developers: Lighthouse performance scoring dokumentacja
- web.dev: Optimize long tasks dokumentacja