Minimize Main-Thread Work: How to Fix It

What this check flags

The main thread is a single execution lane, and the browser runs everything through it one job at a time: parsing markup, recalculating styles, laying out boxes, painting pixels, running your JavaScript, and dispatching every click a visitor makes. When one long task grabs that lane and holds it, the tap a user just performed sits in a queue behind unrelated work. Lighthouse breaks the total busy time into buckets so you can see where the seconds went.

Nine times out of ten the dominant bucket is Script Evaluation plus Script Parse/Compile. That is why this audit is really a JavaScript-weight problem wearing a generic name: the engine has to download the script, parse it into an AST, compile it to bytecode, and then run it, all on the same thread that owes the user a response.

A real example, and the fix

Here is the pattern that generates most of the flagged time: a big synchronous chunk of work kicked off during initialization, blocking the thread in one uninterrupted burst.

// Blocks the main thread for hundreds of ms on load
const rows = JSON.parse(hugePayload);       // parse cost
const enriched = rows.map(expensiveTransform); // one long task
renderTable(enriched);

The transform never yields, so the browser cannot slip an event handler in between iterations. The repair is to break the loop into chunks that hand the lane back, or move the whole thing off-thread. Yielding with scheduler.yield() (or a setTimeout(0) fallback) lets a queued click run between batches:

async function processInChunks(rows) {
  const out = [];
  for (let i = 0; i < rows.length; i++) {
    out.push(expensiveTransform(rows[i]));
    if (i % 200 === 0) await scheduler.yield(); // give the thread back
  }
  return out;
}

Genuinely heavy computation (parsing megabyte payloads, image math, crypto) should not chunk on the main thread at all. It belongs in a web worker, where it runs on a separate thread and posts results back when done.

Where the time actually goes

Lighthouse itemizes the main thread by category. Reading this table tells you whether you have a script problem, a rendering problem, or a parsing problem, because the fix for each is different.

How to detect it

1. Lighthouse (Chrome DevTools): run the Performance category and open "Minimize main-thread work". It lists each category with its second count under simulated mobile throttling.
2. PageSpeed Insights: paste the URL to see the same breakdown against real-user field data, so you know whether lab pain matches what visitors feel.
3. DevTools Performance panel: record a load, then read the flame chart. Long tasks are marked with a red corner; hover one to see whether it is Evaluate Script, Recalculate Style, or Layout.
4. DevTools Coverage tab: reload with Coverage recording to see what percent of each script is unused. High unused percentages point straight at bundles worth code-splitting.

How to fix it

Work in this order, because each step shrinks the problem for the next:

• Send less script. Audit dependencies, drop heavyweight libraries for native APIs or lighter alternatives, and delete unused JavaScript. Fewer bytes means less to parse, compile, and run.
• Code-split and defer. Break the monolith into route-level chunks and load only what a page needs. Deferring non-critical scripts keeps them from fighting the initial render.
• Chunk or offload long tasks. Yield inside loops, or push expensive computation to a web worker so the main thread stays free to answer input.
• Prune third parties. Tag managers, chat widgets, and A/B tools run their own scripts on your thread. Audit each one and cut what does not earn its keep.

For the JavaScript side specifically, our guides on reducing JS execution time and fixing high TBT go deeper on the exact tactics.

FAQ

Is this the same as reducing JavaScript execution time?

They overlap but are not identical. Execution time is one bucket inside main-thread work; this audit also counts style, layout, paint, parsing, and garbage collection. If your breakdown is dominated by Script Evaluation, the two audits point at the same fix.

Why does the report look fine on my laptop but fails in Lighthouse?

Lighthouse simulates a mid-range phone with CPU throttling. A fast desktop chews through the same script in a fraction of the time, hiding the problem. Trust the throttled numbers, because that is closer to what most visitors experience.

Does moving work to a web worker always help?

It helps when the work is CPU-bound and does not need the DOM, since workers cannot touch the DOM directly. Data crunching, parsing, and math are ideal. Small tasks are not worth the messaging overhead, so measure before you refactor.

How does this connect to my Core Web Vitals?

A busy main thread is the mechanical cause behind bad INP and Total Blocking Time. When the thread is stuck on a long task, the handler that should react to a click is blocked, so the page feels dead even though it looks ready.

What is a "long task"?

Any uninterrupted stretch of main-thread work over 50 milliseconds. Everything past that 50 ms threshold counts toward Total Blocking Time, which is why the goal is many short tasks rather than a few long ones.