Minimize main thread work: script evaluation is half of it on 33 homepages

FIELD TEST · 2026-10-03 · 34 homepages · single Lighthouse run

Sample and method: 34 homepages (the 30-site panel we have reused since 2026-08-15, plus our own four sites), each loaded once by Lighthouse 13.5.0 in its mobile configuration on 2026-10-03. We read the audit titled "Minimize main thread work" from each JSON report and summed its seven categories. One run per site, no averaging, no repeat. stackoverflow.com returned no usable report, leaving 33; every number below is from those 33.

Minimize main thread work is the Lighthouse audit that totals every task the browser's main thread ran while the page loaded. Across 33 homepages measured once each, that work had a median of 20,720 milliseconds. Script evaluation was 49% of it, style and layout another 17%, and 32 of the 33 homepages stayed busy for longer than the four seconds Lighthouse treats as the flag line.

How we measured it

The audit comes from Lighthouse's performance category and reports one total plus a breakdown into seven named groups: script evaluation, script parsing and compilation, style and layout, rendering, parse HTML and CSS, garbage collection, and a residual group called Other. The total is the sum of those groups, measured in milliseconds of main-thread time during the load.

We ran one headless Lighthouse per host with only this audit enabled, read the group values straight from each JSON, and summed the total for that site. Several hosts redirected us to a market-specific path because of where this machine sits — developer.mozilla.org landed on /zh-CN, canva.com on /zh_cn, and our own querywin.com on /zh — and we kept whatever the redirect served. Lighthouse's own documentation says it flags a page when the main thread stays busy for more than four seconds, and we use that line only as the threshold it is, not as a pass mark.

Minimize main thread work: what the 33 homepages spend it on

Add up all seven groups across all 33 homepages and you do not get an even split. Script evaluation is very close to half of everything, and one group — parsing and compiling scripts — is another 5.5% that exists only because of JavaScript. Together, code is the single largest reason the main thread is busy.

Two things follow. First, on this panel the lever with the most room is the code you ship and run, not the CSS. Second, the medians tell a different story from the totals: on a typical page, style and layout (a median of 4,208 ms) is nearly as large as script evaluation's median share would suggest, because a few very heavy script pages pull the total up. The total answers "what does the panel spend most on"; the median answers "what does a typical page spend most on". They are both worth reading.

Script evaluation is the largest slice

Eleven of the 33 homepages spend more than half their main-thread time inside script evaluation, and 21 of the 33 spend more than 40%. The heaviest page did roughly 105 seconds of main-thread work, of which 62 seconds were script evaluation alone. The table is the ten busiest pages, worst first.

A page does not have to be heavy to be flagged, though. The one homepage that stayed under four seconds, news.ycombinator.com, did 2,006 ms of work in total, almost none of it script evaluation. At the other end, our own four sites sit in the middle of the panel: sizemarker.com 17,655 ms, byerisk.com 15,237 ms, biaojixia.com 13,503 ms, and querywin.com 7,689 ms. None of them is clean, which is the honest reason these numbers are published rather than summarised.

What the numbers do not prove

Three limits matter before you act on any of this. The runs are single and unrepeated, so a second load of the same page can differ; we did not measure the spread. The panel is 33 homepages chosen for convenience, not a sample of the web, so the shares are a description of these sites and not an estimate of anyone else's. And main-thread work is a lab quantity: it is the work the synthetic run did, not the work your visitors' devices did.

We also cannot say which line of script is worth deleting from the totals alone. The audit tells you that script evaluation is large, not which script. For that you need the coverage view or the per-script audits, and this run did not collect either.

Common questions

What does minimize main thread work mean?

It is a Lighthouse audit, and the name is an instruction rather than a number. The audit measures how long the browser's single main thread was busy during load, adds it up, and shows which kinds of work the time went to. "Minimize" is the action it recommends; the milliseconds are what it reports.

How do I minimize main thread work?

On this panel the largest single target is script evaluation, so the first moves are to ship less JavaScript, run it later, and move heavy work off the main thread. Splitting bundles and removing unused code reduce how much script has to be parsed and evaluated; deferring non-critical scripts keeps them out of the load. The style-and-layout group is the second target, and it responds to smaller DOM and simpler selectors rather than to more caching.

Is main thread work the same as total blocking time?

No, and the difference matters. Total blocking time counts only the part of each long task that runs past 50 milliseconds, so it measures how long the main thread was blocked from responding. Main-thread work counts everything the main thread did, including short tasks that never blocked an interaction. A page can have a large main-thread total and a small blocking time, or the reverse.

Does main thread work affect Core Web Vitals?

It feeds interaction to next paint, the responsiveness metric: less work on the main thread means a shorter delay before the browser can paint a reply. It is not a Core Web Vital by itself and it has no published threshold that converts to ranking. Treat the total as a debugging number and interaction to next paint as the field number that follows from it.

The boundary worth keeping: this is a snapshot of one afternoon on one machine, and the front page of a site is not the page most visitors use. The next step that is actually worth doing is to run the same audit against the pages people land on and compare the shares, rather than chasing the lowest total on the home page. Watching that difference across a site is part of what QueryWin works on; for the metric this work feeds, interaction to next paint is the chapter to read next, and the total blocking time survey gives the blocked-time reading of a similar panel. If the work you find is a stylesheet holding the first paint, render blocking resources is the closer match.