Total blocking time

The browser handles interaction on the same thread that runs scripts, so a running task means input waits.

A response within about fifty milliseconds feels immediate, so work under that ceiling is not experienced as unresponsiveness.

Only the excess counts: a seventy-millisecond task contributes twenty, and a task under the threshold contributes nothing.

Which means the measurement targets the long tasks specifically, rather than penalising a page for doing work at all.

Ten tasks of forty milliseconds contribute zero and ten of a hundred contribute five hundred, which is the distinction the threshold draws.

Parsing and executing a large JavaScript bundle, which is usually the largest single contributor.

Hydrating a server-rendered page, where the framework walks the whole tree attaching behaviour.

Third-party scripts, which are frequently the worst offenders and the ones nobody profiles because they are not your code.

Expensive layout work triggered by script reading and writing style properties in an interleaved pattern.

Large synchronous data processing on load, which is rare and dramatic when it happens.

The field measurement of interaction responsiveness reports what real visitors experienced when they interacted.

Total blocking time is its laboratory proxy: it correlates with it and is measured without needing real traffic.

The correlation is not exact, because the field measurement covers the whole visit while this covers the load.

Which is why a page with a good blocking time and poor field responsiveness usually has expensive handlers rather than a heavy load.

And why improving this is a reasonable way to move that, without being a guarantee.

Shipping less JavaScript, which is the intervention that works and the one nobody wants to hear.

Splitting bundles so that only what the current route needs is parsed and executed.

Deferring or removing third-party scripts, or loading them after interaction rather than during load.

Breaking long tasks into shorter ones, which yields to the browser between them and lets input be handled.

Moving heavy computation off the main thread, which suits genuine processing and not framework overhead.

Rendering measurements are taken during the scan, alongside the payload figures that explain them.

JavaScript payload and the heaviest individual script files are reported, since those are what the measurement usually reflects.

Third-party resources are listed separately, which is where the contribution is frequently concentrated.

The coverage of the measurement is stated, since a figure over part of the resource inventory is not comparable with one over all of it.