Przejdź do treści
Wydajność

Total Blocking Time (TBT)

Opublikowano:

Total Blocking Time (TBT) to laboratoryjna metryka wydajności, która sumuje, jak długo główny wątek przeglądarki był zablokowany między First Contentful Paint (FCP) a Time to Interactive (TTI). Do sumy wlicza się tylko ta część każdego długiego zadania, która przekracza 50 ms.

TBT nie jest Core Web Vital. W teście laboratoryjnym nie ma prawdziwych kliknięć, więc TBT służy jako przybliżenie INP, czyli responsywności mierzonej u realnych użytkowników. Dobry TBT nie gwarantuje dobrego INP w danych terenowych.

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.

Obliczenie TBT (scenariusz)
Przykład
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 ms

Progi 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ądzenieDobryDo poprawySłaby
Mobile0–200 ms200–600 mspowyżej 600 ms
Desktop0–150 ms150–350 mspowyż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.
Oddawanie wątku między porcjami pracy
JavaScript
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.

Źródła i dalsza lektura

Sprawdź, co blokuje Twoją stronę

Insight łączy wyniki laboratoryjne i dane terenowe, gdy są dostępne, i układa problemy z wydajnością według priorytetu.