What does the Total Blocking Time (TBT) metric measure about a page load, how is its value computed, and why do lab tools use it as a stand-in for a field responsiveness metric they cannot measure?

## Long tasks, and the 50ms allowance A browser's main thread runs work as a queue of tasks, and while one task runs, nothing else on that thread happens — including handling a tap or a click. A task that runs longer than **50 milliseconds** is called a *long task*. The 50ms figure is a convention: it is the point past which a newly arrived input is likely to feel delayed rather than instant. TBT is built directly on that definition. For each long task in the window, its **blocking time** is everything beyond the 50ms allowance: ```js // blocking time contributed by one task const blocking = Math.max(0, taskDuration - 50); // TBT over a load const tbt = tasks.reduce((sum, t) => sum + Math.max(0, t.duration - 50), 0); ``` A 51ms task contributes 1ms. A 300ms task contributes 250ms. Tasks under 50ms contribute nothing at all, which is the key structural property of the metric: **it does not care how many tasks you run, only how long individual ones are.** Splitting one 300ms task into six 50ms tasks drops its TBT contribution from 250ms to zero, even though the total work is identical. Lab tools measure TBT over the loading window — conventionally between First Contentful Paint and the point where the main thread goes reliably quiet — not over the entire session. ## Why the proxy exists at all The field metric for responsiveness, Interaction to Next Paint, is derived from real interactions: someone taps, and the browser measures how long until the next frame reflects it. That definition has a hard consequence — **if nobody interacts, there is no value**. A synthetic run in a lab tool loads the page with no user attached, so INP is not merely inconvenient to compute there; it does not exist. TBT resolves this by measuring the *condition* rather than the *symptom*. It cannot know whether a tap collided with a long task, but it can say precisely how much of the load period was spent in a state where a tap *would* have been delayed. Empirically the two correlate well: pages that ship a lot of blocking JavaScript during load tend to have poor field responsiveness, and driving TBT down usually moves the field metric in the same direction. ## Where the proxy breaks down An interviewer is usually probing for the limits, not the definition: - **TBT only covers load.** Field responsiveness is measured across the whole visit, including interactions ten minutes in. A page with a clean load and one catastrophically expensive filter handler can have near-zero TBT and terrible real-world responsiveness. - **TBT does not know where the user was.** Blocking during a phase where nobody could have interacted counts the same as blocking during the moment the user reached for the button. - **TBT is an aggregate, the field metric is roughly a worst case.** INP reports one bad interaction from the visit; TBT sums many. A page with one dreadful task and a page with many mediocre ones can report the same TBT and behave very differently. - **Lab conditions are chosen, not observed.** TBT depends heavily on the CPU throttling and device class the run simulates. The same page will produce wildly different TBT on an unthrottled desktop run and a simulated mid-tier phone — and the second is closer to what most users actually experience. ## Reading a TBT number Common lab guidance treats TBT under about 200ms as good and over about 600ms as poor on a simulated mobile run, and TBT carries the single largest weight in Lighthouse's composite performance score. Two consequences follow. First, TBT is often the metric that most moves a synthetic score, which makes it a magnet for optimization that does not always help users. Second, an unthrottled run flatters TBT badly enough that a page can be green in the lab and poor in the field — a reason to trust the field responsiveness data whenever you have it, and to treat TBT as the diagnostic that tells you *which* script is responsible. ## What TBT is good for Use it as a localizer, not as a goal. A high TBT during load tells you the main thread is being monopolized while the page is coming up, and the accompanying task breakdown names the script doing it — usually a large framework bundle evaluating, a heavy hydration pass, or a third-party tag executing on the main thread. That attribution is the value: it converts "the page feels sticky while loading" into "this 340ms task belongs to that file".