English
Core Web Vitals & Metriken

Total Blocking Time (TBT)

Auch genannt: TBT

Total Blocking Time (TBT) ist eine Lab-Metrik, die summiert, wie lange der Hauptthread einer Seite nach dem First Contentful Paint blockiert war. Lighthouse misst bis zum Time to Interactive, andere Messmodi wie Timespan können darüber hinausgehen. Währenddessen reagiert die Seite verzögert auf Klicks, Taps und Tastatureingaben.

Auf einen Blick

Misst
Zeit nach dem FCP, in der der Hauptthread so lange blockiert war, dass Eingaben nicht reagieren konnten
Bewertung
Lighthouse mobil grün bis 200 ms, orange bis 600 ms, darüber rot
Grenze „gut“
unter 200 ms auf durchschnittlicher mobiler Hardware
Datenquelle
Labor; Feldmessung empfiehlt web.dev nicht
Core Web Vital
nein, Labor-Stellvertreter für INP
Doku
web.dev: Total Blocking Time (TBT)

Stand:

Berechnung

Jede Aufgabe im Hauptthread, die länger als 50 Millisekunden dauert, gilt als Long Task. Der Teil über 50 ms zählt als Blockierzeit. Die TBT ist die Summe dieser Anteile. Dauern drei Tasks 70, 120 und 90 ms, ergibt sich eine TBT von 20 + 70 + 40 = 130 ms.

Die drei Phasen einer InteraktionZeitstrahl einer Interaktion vom Klick bis zum nächsten angezeigten Frame. Input Delay dauert, bis die Event-Callbacks starten, etwa weil noch eine lange Task den Hauptthread belegt. Processing Duration ist die Laufzeit der Callbacks. Presentation Delay reicht bis zur Anzeige des nächsten Frames. Zusammen ergeben sie die Latenz der Interaktion.Klick, Tap, Tastenächster FrameInput DelayProcessingPresentationHauptthreadlange Task läuftEvent-CallbacksRendern, MalenZeitLatenz der InteraktionInput Delay · bis die Callbacks starten. Lange Tasks im Hauptthread verlängern sie.Processing Duration · Laufzeit aller Callbacks der Interaktion.Presentation Delay · vom Ende der Callbacks bis zur Anzeige des Frames.INP · bei den meisten Seiten die langsamste Interaktion eines Besuchs.Schematisch, Längen nicht maßstäblich.
Jede Interaktion besteht aus Input Delay, Processing Duration und Presentation Delay. Lange Tasks im Hauptthread verlängern den Input Delay. Als INP gilt laut web.dev bei den meisten Seiten die langsamste Interaktion eines Besuchs. Quellen: web.dev: Interaction to Next Paint (INP); web.dev: Eingabeverzögerung optimieren.

Schwellenwerte

Lighthouse bewertet auf Mobilgeräten bis 200 ms als gut, bis 600 ms als verbesserungswürdig und darüber als schlecht. Für Desktop liegen die Grenzen bei 150 und 350 ms. web.dev nennt als Ziel weniger als 200 ms auf durchschnittlicher mobiler Hardware.

Einordnung

TBT ist keine Core Web Vital. web.dev beschreibt sie als Lab-Stellvertreter für Interaction to Next Paint (INP), der im Feld gemessen wird, und empfiehlt, INP als Maßstab für echte Reaktionsprobleme heranzuziehen. TBT kann Probleme anzeigen, die Nutzer nie bemerken.

Web-Vitals-Messwerte im Vergleich
MesswertMisstCore Web Vital?Feld oder Labor„Gut“ laut web.dev
LCP (Largest Contentful Paint)Renderzeit des größten sichtbaren Bilds, Textblocks oder Videos im Viewport, ab Beginn der Navigationja (Laden)Feld und Laborbis 2,5 s
INP (Interaction to Next Paint)Latenz der Interaktionen während des gesamten Besuchs bis zur nächsten Darstellung; ein Wert, unter dem (fast) alle Interaktionen liegenja (Interaktivität), seit 12.03.2024Feld; im Labor nur mit simulierten Interaktionen, Lighthouse misst INP nichtbis 200 ms
CLS (Cumulative Layout Shift)größte Folge unerwarteter Layoutverschiebungen während der gesamten Lebensdauer der Seiteja (visuelle Stabilität)Feld und Laborbis 0,1
TTFB (Time to First Byte)Zeit vom Beginn der Navigation bis zum ersten Byte der Antwortnein (hilft bei der Diagnose von LCP)Feld und Laborbis 0,8 s
FCP (First Contentful Paint)Zeit vom Beginn der Navigation, bis irgendein Inhalt der Seite dargestellt wirdnein (hilft bei der Diagnose von LCP)Feld und Laborbis 1,8 s
TBT (Total Blocking Time) (dieser Begriff)Summe der Zeit nach dem FCP, in der der Hauptthread so lange blockiert war, dass Eingaben nicht reagieren konntennein (Labor-Stellvertreter für INP)Labor; Feldmessung empfiehlt web.dev nichtunter 200 ms auf durchschnittlicher mobiler Hardware
Speed Indexwie schnell Inhalte beim Laden sichtbar aufgebaut werden (aus einem Video des Ladevorgangs)neinLabor (Lighthouse)Schwelle laut Lighthouse: mobil bis 3,4 s „schnell“ (web.dev nennt keinen Wert)
FID (First Input Delay), historischZeit von der ersten Interaktion bis der Browser mit der Verarbeitung der Event-Handler beginnen kannbis 12.03.2024, ersetzt durch INPnur Feldbis 100 ms

Bewertet wird laut web.dev das 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt. Eine Seite besteht die Core Web Vitals, wenn LCP, INP und CLS am 75. Perzentil im Bereich „gut“ liegen. Chrome-Tools unterstützen FID seit dem 9. September 2024 nicht mehr. Quellen: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Stand: .

Typische Ursachen

Laut Berichten sind das vor allem viel JavaScript, Skripte von Drittanbietern und lange Tasks im Hauptthread. Gegenmaßnahmen sind weniger und kleinerer JavaScript-Code, Code-Splitting und das Aufteilen langer Tasks.

Quellen

  1. Total Blocking Time (TBT) – web.devweb.dev
  2. Total Blocking Time – Lighthouse-Dokumentation, Chrome for Developersdeveloper.chrome.com

Stand: