Total Blocking Time (TBT)

Total Blocking Time (TBT) misst die Gesamtdauer, in der der Main Thread des Browsers zwischen First Contentful Paint (FCP) und Time to Interactive (TTI) blockiert ist. Waehrend dieser Blockierungszeit kann der Browser nicht auf Nutzereingaben wie Klicks, Taps oder Tastatureingaben reagieren — die Seite wirkt "eingefroren".

TBT ist eine Lab-Metrik, die in Lighthouse einen Gewichtungsanteil von 30 % am Performance-Score hat. Sie korreliert stark mit dem Core Web Vital INP (Interaction to Next Paint) und ist damit der wichtigste Lab-Indikator fuer die Interaktivitaet einer Website.

Wie TBT berechnet wird

Long Tasks

Der Browser fuehrt JavaScript auf einem einzigen Main Thread aus. Wenn eine Aufgabe (Task) laenger als 50 Millisekunden dauert, gilt sie als "Long Task". Der Anteil ueber 50ms ist die "blockierende Zeit" dieser Task.

Beispiel:

• Task A: 30ms — keine Blockierung (unter 50ms)
• Task B: 120ms — 70ms Blockierung (120ms - 50ms)
• Task C: 85ms — 35ms Blockierung (85ms - 50ms)
• TBT = 0 + 70 + 35 = 105ms

Messzeitraum

TBT wird zwischen zwei Zeitpunkten gemessen:

Dieser Zeitraum ist kritisch, weil der Nutzer bereits Inhalte sieht (FCP ist passiert) und mit der Seite interagieren moechte — aber die Seite noch nicht vollstaendig reagiert.

Bewertungsskala

Was TBT verursacht

JavaScript-Ausfuehrung

Die Hauptursache fuer hohe TBT-Werte ist JavaScript:

• Grosse Bundles: Monolithische JS-Dateien, die komplett geparst werden muessen
• Framework-Hydration: React- und Next.js-Hydration kann mehrere hundert Millisekunden dauern
• Third-Party Scripts: Analytics, Ads, Chat-Widgets und Social-Media-Embeds
• Polyfills: Unnoetige Polyfills fuer moderne Browser

Layout-Berechnungen

Erzwungene Layout-Neuberechnungen (Forced Reflows) koennen den Main Thread blockieren. Typische Ursachen:

• DOM-Abfragen gefolgt von DOM-Manipulationen in einer Schleife
• Groesse von Elementen lesen und gleichzeitig aendern
• Komplexe CSS-Selektoren auf grossen DOM-Baeumen

Optimierungsmassnahmen

JavaScript-Bundle reduzieren

Third-Party Scripts kontrollieren

Third-Party Scripts sind oft der groesste TBT-Verursacher:

• Scripts nach dem Seitenaufbau laden (defer oder Dynamic Import)
• Nicht-essentielle Scripts per Intersection Observer oder User-Interaktion laden
• Web Workers fuer rechenintensive Aufgaben nutzen
• Party-Town oder aehnliche Libraries fuer Third-Party-Isolierung evaluieren

JavaScript-Ausfuehrung optimieren

• Lange Tasks aufbrechen: requestIdleCallback oder scheduler.yield() nutzen
• Debouncing und Throttling: Scroll- und Resize-Handler begrenzen
• Memoisierung: Teure Berechnungen cachen
• Virtual Scrolling: Grosse Listen nicht komplett in den DOM rendern

Framework-spezifische Optimierungen

In Next.js:

• React Server Components: Reduzieren die Client-seitige JavaScript-Last
• Partial Hydration: Nur interaktive Teile der Seite hydrieren
• next/script mit strategy="lazyOnload": Nicht-kritische Scripts spaet laden
• next/dynamic: Komponenten dynamisch importieren

TBT messen

• Lighthouse (Chrome DevTools): Zeigt TBT direkt im Performance-Report
• PageSpeed Insights: Lab-Daten mit TBT
• WebPageTest: Detaillierte Long-Task-Analyse im Wasserfall
• Chrome DevTools Performance Tab: Main-Thread-Aktivitaet visuell analysieren

TBT vs. INP

TBT ist die beste Approximation fuer INP in der Entwicklung. Ein niedriger TBT-Wert in Lighthouse deutet auf gute INP-Werte in der Produktion hin — ist aber keine Garantie, da reale Nutzereingaben zusaetzliche Variablen einfuehren.