Long tasks and blocking time (TBT) explained

What a long task is

A long task is any piece of work on the browser's main thread that runs for more than 50 milliseconds without yielding. Because the main thread handles rendering, input and script, a long task blocks the page from responding to clicks and taps for its whole duration. The 50 ms threshold comes from the Long Tasks API and is the reference point the performance community uses for an interaction that starts to feel sluggish.

A common source of long tasks is expensive work bundled into a single onload handler or render pass: parsing a large script, running a heavy layout, or processing a big array synchronously. The classic symptom is a page that loads, then freezes for a moment before it becomes interactive, or clicks that feel unresponsive right after load.

TBT and INP relationship

Total Blocking Time (TBT) is a field-influenced, lab counterpart to this idea. It sums the time that long tasks block the main thread for a given load, measured in DevTools and Lighthouse as the sum of each long task's duration beyond 50 ms (the portion over 50 ms counts toward TBT). It is a proxy for how unresponsive the page feels during load and is used as a lab stand-in for the field metric Interaction to Next Paint (INP).

The relationship matters: TBT is not directly a field metric you can collect from real users, while INP is measured in the field as the worst interaction's response time. A high TBT predicts poor interactivity, so improving TBT (by removing or splitting long tasks) is one of the clearest levers on interaction responsiveness. A lower-TBT page still needs good INP from real visitors, which is why the CWV field picture pairs them: lab TBT drives the improvement loop, field INP confirms it in production.

A newer API, Long Animation Frames (LoAF), looks at long main-thread frames rather than tasks and is a more direct signal for interaction delay. It is covered in the long animation frames guide. Where TBT tells you the aggregate blocking load, LoAF ties blocking to the specific frame that delayed an input.

Finding and splitting tasks

1. Find the long tasks. Open DevTools Performance and record a reload. Long tasks appear as blocks exceeding 50 ms in the main-thread timeline. The Performance panel and Lighthouse report which scripts and functions contribute.
2. Read the TBT number. In Lighthouse, TBT is shown with FCP and LCP. A TBT below 200 ms is the common good-threshold used; large values are driven by a small number of very long tasks rather than many small ones.
3. Split or defer the work. Move expensive work out of the initial render path so the main thread can respond quickly. Defer non-critical work with idle callbacks or time-slicing using requestIdleCallback, push heavy modules behind a dynamic import so they load on a route or interaction, and split big synchronous loops so they yield between chunks.
4. Yield between units of work. A loop that processes 10,000 items synchronously runs as one long task. Process a bounded batch, yield to the browser, then continue, so input can be handled between batches.
5. Re-measure with real users. Confirm the effect with the web-vitals JavaScript library and field INP, which verifies that the splitting actually reduced interaction delay in production rather than only in the lab.

Long tasks are the mechanism behind several sluggish-site complaints. When a site jumps between interactive and frozen, or a click reacts half a second late right after load, the cause is usually a main thread that never yields. Chasing long tasks, lowering TBT, and then confirming with field INP gives a repeatable path from "feels slow" to a measured, interaction-friendly load.