Measuring main-thread responsiveness: Total Blocking Time
Total Blocking Time (TBT) is a lab metric that quantifies how long the main thread is blocked after First Contentful Paint (FCP), preventing the page from responding to user input. It is calculated by summing the blocking time of every Long Task—a task running longer than 50 milliseconds—that occurs within the measured window.
The browser cannot interrupt a task that is already running. If a user interacts with the page during a long task, the browser must wait for that task to finish before responding. Any task longer than 50 ms is long enough that a user is likely to notice the delay. The blocking time for a given task is its duration minus 50 ms, and TBT is the sum of those values.
By default, Lighthouse and other page-load lab tools measure TBT only up to Time to Interactive (TTI). Other tooling may measure over the full trace.
TBT as an INP proxy
TBT predates Interaction to Next Paint (INP) and serves as a lab proxy for it, since INP is difficult to measure accurately in lab conditions. However, TBT is not a substitute for INP: it may flag problems in cases where users do not actually interact at a problematic moment, and it can miss issues for interactions that occur when lab tools are not monitoring. For real-world responsiveness, measure INP in the field.
The advantage over TTI
TTI defines a page as "reliably interactive" only after the main thread has been free of long tasks for five seconds. This means a few marginally long tasks spaced out over time can delay TTI as much as a single massive one, even though those scenarios feel very different to users.
For example, three tasks of 51 ms each produce a TBT of only 3 milliseconds, whereas one 10-second task yields 9950 milliseconds. The larger TBT value in the second case reflects the worse experience. Because TBT is aggregated over the whole period, it is less prone to outliers than TTI.
How to measure TBT
TBT is intended to be measured in the lab, where it is best captured by running a Lighthouse performance audit. Tools that support TBT measurement include Lighthouse and WebPageTest.
Measuring TBT in the field is possible but generally discouraged, as user interaction can introduce significant variance. If you need field data beyond what a single INP interaction reveals, the Long Animation Frames API is a better alternative.
What is a good TBT score?
To deliver a good user experience, a page tested on average mobile hardware should have a TBT below 200 milliseconds. See How Lighthouse determines your TBT score for details on how TBT affects your performance score.
How to improve TBT
Since TBT is a lab proxy for INP, follow the guidance for Optimizing INP as your primary strategy. If you are focusing specifically on TBT, run a Lighthouse audit and examine the opportunities it surfaces.
Generally, reducing TBT involves decreasing the volume of blocking scripts, either by optimizing them so they block less or by cutting the total amount of JavaScript. The following references offer specific techniques:
