Deutsch
Core Web Vitals & metrics

Total Blocking Time (TBT)

Also known as: TBT

Total Blocking Time (TBT) is a lab metric. It adds up how long the main thread of a page was blocked after First Contentful Paint. Lighthouse measures until Time to Interactive, while other modes such as Timespan can run beyond that. During that time the page reacts late to clicks, taps and key presses.

At a glance

Measures
Time after FCP during which the main thread was blocked long enough to prevent input responsiveness
Assessment
Lighthouse mobile green up to 200 ms, orange up to 600 ms, red above
“Good” threshold
less than 200 ms on average mobile hardware
Data source
Lab; web.dev does not recommend field measurement
Core Web Vital
no, lab proxy for INP

Last checked:

How is it calculated?

Any task on the main thread that runs longer than 50 milliseconds is a long task. The part beyond 50 ms counts as blocking time, and TBT is the sum of these parts. Tasks of 70, 120 and 90 ms give 20 + 70 + 40 = 130 ms.

The three phases of an interactionTimeline of one interaction from the click to the next presented frame. Input delay lasts until the event callbacks start, for example because a long task is still occupying the main thread. Processing duration is the run time of the callbacks. Presentation delay lasts until the next frame is shown. Together they make up the latency of the interaction.click, tap, key pressnext frameInput delayProcessingPresentationMain threadlong task runningevent callbacksrender, painttimeLatency of the interactionInput delay · until the callbacks start. Long tasks on the main thread extend it.Processing duration · run time of all callbacks for the interaction.Presentation delay · from the end of the callbacks until the frame is shown.INP · for most sites, the slowest interaction of a visit.Schematic, durations not to scale.
Every interaction consists of input delay, processing duration and presentation delay. Long tasks on the main thread extend the input delay. According to web.dev, INP is the slowest interaction of a visit for most sites. Sources: web.dev: Interaction to Next Paint (INP); web.dev: Optimize input delay.

Thresholds

Lighthouse rates TBT on mobile as good up to 200 ms, moderate up to 600 ms and slow above that. On desktop the limits are 150 and 350 ms. web.dev recommends under 200 ms on average mobile hardware.

How does TBT relate to INP?

TBT is not a Core Web Vital. web.dev describes it as a lab proxy for Interaction to Next Paint (INP), which is measured in the field. It also says TBT can flag problems where users may notice nothing, for example if they do not interact at that moment.

Web Vitals metrics compared
MetricMeasuresCore Web Vital?Field or lab“Good” per web.dev
LCP (Largest Contentful Paint)Render time of the largest image, text block or video visible in the viewport, from the start of navigationyes (loading)field and lab2.5 s or less
INP (Interaction to Next Paint)Latency of interactions across the whole visit until the next paint; one value that all (or nearly all) interactions fall belowyes (interactivity), since 2024-03-12field; in the lab only with simulated interactions, Lighthouse does not measure INP200 ms or less
CLS (Cumulative Layout Shift)Largest burst of unexpected layout shifts during the entire lifecycle of the pageyes (visual stability)field and lab0.1 or less
TTFB (Time to First Byte)Time from the start of navigation until the first byte of the response arrivesno (helps diagnose LCP)field and lab0.8 s or less
FCP (First Contentful Paint)Time from the start of navigation until any part of the page's content is renderedno (helps diagnose LCP)field and lab1.8 s or less
TBT (Total Blocking Time) (this term)Total time after FCP during which the main thread was blocked long enough to prevent input responsivenessno (lab proxy for INP)lab; web.dev does not recommend field measurementless than 200 ms on average mobile hardware
Speed IndexHow quickly content is visually displayed during page load (from a video of the load)nolab (Lighthouse)Threshold according to Lighthouse: mobile up to 3.4 s “fast” (web.dev gives no value)
FID (First Input Delay), historicalTime from the first interaction until the browser can begin processing event handlersuntil 2024-03-12, replaced by INPfield only100 ms or less

According to web.dev, the 75th percentile of page loads is assessed, mobile and desktop separately. A page passes the Core Web Vitals when LCP, INP and CLS are “good” at the 75th percentile. Chrome tools ended FID support on September 9, 2024. Sources: 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. Last checked: .

Typical causes

Large amounts of JavaScript, third-party scripts and long tasks. Typical countermeasures are less code, code splitting and breaking up long tasks.

Sources

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

Last updated: