What Is Main Thread Work? Complete Guide (2026)

Why Main Thread Work Decides How Fast Your Site Feels

Network speed gets the headlines, but main-thread work is what determines whether your page feels alive or frozen. It directly affects:

• Input responsiveness (INP): When the main thread is blocked by a long task, taps and clicks queue up. Visitors perceive any delay over ~100 ms as lag, and over ~300 ms as broken.
• Total Blocking Time (TBT):TBT sums the "blocking portion" (the part above 50 ms) of every long task between First Contentful Paint and Time to Interactive. Heavy main-thread work is, by definition, what TBT measures.
• Smooth scrolling and animation:The browser needs ~16 ms per frame to hit 60 fps. Any task that runs longer than that drops frames, which visitors see as "jank."
• Performance score weight: Common audit scoring weights TBT at ~30% of the overall performance score — the largest single contributor. Cutting main-thread work usually moves the score more than any other intervention.
• AI search visibility: AI-driven answer engines (Google AI Overviews, generative search) tend to source pages that already rank well — and pages with bad TBT/INP rank worse, especially on mobile-first queries.

What Actually Runs on the Main Thread

The "main thread work breakdown" in audit reports splits time across a handful of categories. Knowing which category dominates tells you where to optimize.

• Script evaluation: Running your JavaScript — module initialization, framework hydration, third-party tag execution. On most modern sites this is the single biggest cost.
• Style & layout: Recalculating which CSS rules apply (style recalc) and computing the geometry of every element (layout/reflow).
• Parse HTML & CSS: Turning the raw bytes of your markup and stylesheets into the DOM and CSSOM.
• Script parsing & compilation: Before JavaScript can run, the engine must parse and compile it. Large bundles pay this cost even before they execute.
• Garbage collection: Reclaiming memory from objects that are no longer reachable. Frequent or long GC pauses are a sign of memory churn.
• Rendering: Paint and composite work that happens on the main thread when it can't be offloaded to the compositor (for example, when you animate top or width instead of transform).

A Worked Example: Layout Thrashing

One of the most common ways to multiply main-thread cost is "layout thrashing" — reading and writing layout properties in an interleaved loop. Each read forces the browser to flush pending style and layout work synchronously.

// BAD — forces a synchronous layout on every iteration
for (const card of cards) {
  card.style.width = (card.offsetWidth + 10) + 'px'; // read, then write
}

// GOOD — read all first, then write all
const widths = cards.map(c => c.offsetWidth);
cards.forEach((c, i) => {
  c.style.width = (widths[i] + 10) + 'px';
});

The first version can take 10x or more main-thread time on a list of 100 elements because each iteration triggers a forced reflow. The second version batches reads and writes so layout runs only once.

How to Measure Main Thread Work

Main thread work is a lab metric — you measure it on a controlled mid-range device profile, not from real user data. The categories you're looking for: script evaluation, style/layout, parse/compile, GC, render.

• Greadme's deep scan — surfaces total main-thread time, the per-category breakdown, the longest individual tasks, and the third-party scripts contributing the most. Each issue is paired with an AI-generated fix or a one-click GitHub PR.
• Greadme's crawler scan — measures main-thread work across every indexable page so you can pinpoint which templates (product pages, article pages, listing pages) carry the heaviest scripts.
• Chrome DevTools → Performance panel — record a page load and inspect the flame chart. The summary at the bottom shows the same script/style/layout/paint breakdown by color. Any task with a red corner is a long task.
• Chrome DevTools → Performance Insights — surfaces long tasks and their attributable scripts directly without manual flame-chart reading.
• web.dev measure tool — runs the same lab audit against any public URL and includes the main-thread breakdown.

9 Proven Ways to Reduce Main Thread Work

// Load the rich-text editor only when the user opens it
const openEditor = async () => {
  const { Editor } = await import('./editor');
  new Editor(container).mount();
};

// main.js
const worker = new Worker('/workers/search.js', { type: 'module' });
worker.postMessage({ query, dataset });
worker.onmessage = (e) => render(e.data);

async function processInChunks(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i]);
    if (i % 50 === 0) await new Promise(r => setTimeout(r, 0));
  }
}

requestIdleCallback(() => {
  flushAnalyticsQueue();
  prefetchNextRoute();
}, { timeout: 2000 });

Common Main-Thread Problems and Fixes

How Main Thread Work Relates to Other Performance Metrics

Main thread work is the cause; most user-facing performance metrics are the effect. Cutting it usually moves several scores at once.

FAQ

What is a good amount of main thread work?

Performance audits flag pages where total main-thread work exceeds about 4 secondson a simulated mid-range mobile. There's no hard threshold — lower is always better — but pages under 2 seconds of main-thread work tend to comfortably pass TBT and INP, while pages over 6 seconds almost always fail.

What's the difference between "main thread work" and "long tasks"?

Main thread work is the total time spent on the main thread across all categories. A long task is any single task longer than 50 ms. A page can have a lot of total main-thread work split into many short tasks (relatively healthy) or a small total split into a few very long tasks (much worse for INP and TBT).

Why is script evaluation usually the biggest category?

Modern sites ship hundreds of kilobytes (often megabytes) of JavaScript — frameworks, hydration code, analytics, A/B testing, ads. All of it must be parsed, compiled, and evaluated on the main thread before the page becomes interactive. On mid-range mobile, parse and execution alone can account for 1–3 seconds before any of your code runs.

Do Web Workers actually help?

Yes — anything you move into a Web Worker runs on a different thread and cannot block the main thread no matter how long it takes. The catch is that workers can't touch the DOM, so they're best for pure computation: search, filtering, parsing, encoding, image processing. The main thread sends data in and receives results out via postMessage.

Does main thread work affect AI search engines like ChatGPT and Perplexity?

Indirectly. Generative search systems most often surface pages that already rank well in traditional search — and main-thread work feeds directly into TBT and INP, which feed into Core Web Vitals, which feed into Page Experience ranking. A page with 8 seconds of main-thread work loses both the user (who bounces) and the citation (because the page ranks lower in the first place).

How is main thread work different from network time?

Network time is waiting — the browser is idle while bytes arrive. Main thread work is doing— parsing, executing, laying out, painting. A site on a fast CDN can still feel slow if main-thread work is heavy, and a site on a slow connection can still feel responsive once content arrives if main-thread work is light. They're different bottlenecks and need different fixes.

Will reducing main thread work always improve my performance score?

Almost always. TBT alone is roughly 30% of the standard performance score, and main-thread work also contributes to LCP (via blocked rendering) and Speed Index. The exception is when something else — like a multi-second LCP image — is the dominant bottleneck. Run a deep scan first to see which lever moves the score most.