A heavy site that pauses on interaction

Symptoms

The page loads, but a few milliseconds after a click, tap, swipe, or scroll the site stalls. A modal opens two beats late, the spinner freezes mid-animation, typing lags on a form, and the tab shows "Not responding" on a mission-critical pass. In Performance or a profile, this freeze maps to a long main-thread task: one uninterrupted script run (usually 50ms or more) that blocks the browser from processing the input event, painting the next frame, or advancing the queue.

Why the main thread comes to a stop

The browser's main thread performs parsing, layout, paint, and nearly all script work. A long task occupies it for the entire run of that task. When it is blocked, input events, timers, and rAF callbacks all sit in a queue. The task that owns the freeze is either:

1. A huge synchronous script that runs after load (a framework boilerplate, an analytics pile).
2. A handler that does expensive work, such as a filter over a large list, layout-reading, or a network fetch, on the interaction itself.
3. A third-party sweep: a tracker, chat widget, A/B test, or ad bundle that ships a big script the page never needed.

The audit pair that shows this is Lighthouse's "Reduce main thread work" plus the interaction timeline in the tab's Performance panel. The first reports the bottleneck in aggregate; the second lets you click the offending long task and read its self time.

Step 1: Find the obstacle with the tools

1. Open DevTools, Performance, reload, and record an interaction.
2. The task that spans the freeze shows duration and a calling script, usually named after its bundle.
3. Check Lighthouse's "Reduce main thread work" audit below the "Interaction" section. It breaks the time into script, style, layout, and paint.
4. Scroll the Network panel for third-party children: a chat or analytics iframe that was not part of the original page.

Step 2: Cut the culprit

Work the list from biggest to smallest yield:

1. Defer or async the heavy third party. Anything that attaches at window load but only needed for an action moves to defer/async. The render-blocking resources page covers attribute choice.
2. Code-split the app. Split a large bundle into chunks loaded for the view that needs them. A page showing a dashboard does not need the checkout chunk until checkout opens.
3. Make handlers cheap. In the event handler, move computation out of the critical chunk or behind a yielded requestIdleCallback / setTimeout(0).
4. Move pure work to a Web Worker. Anything that does not touch the DOM (batch math, file hashing) runs there and never blocks the main thread.
5. Destroy what dies. Remove event listeners when the element unmounts, tear down observers, and pause timers on hidden tabs. A tab that keeps ticking in the background accumulates tasks nobody sees.

Verify after the change

Re-run Lighthouse and watch the Reduce main thread work total drop by hundreds of milliseconds. Repeat the check with a longer interaction, not a single fast click. Cut a third party and the queue of tasks that arrives with it disappears; the page after a full script cleanup runs the same interactions in the single-digit milliseconds that the old one needed to register a click.

The deeper INP optimisation page shows how this cleanup interacts with the responsiveness metric. And if the slowdown happens at page build rather than interaction, the render-blocking resources fix order applies.

Prevention

Set a budget for third-party runtime: a remarketing pixel plus a chat widget plus analytics is already a few hundred milliseconds of their scripts alone. Review the list after every marketing or tool addition, and re-audit the interaction path before each release.