Reduce unused JavaScript: 29 of 32 homepages load code they never run

FIELD TEST · 2026-10-02 · 32 homepages · single Lighthouse run

Sample and method: 34 homepages attempted (the 30-site panel we have reused since 2026-08-15, plus our own four sites), each loaded once by Lighthouse 13.x in its mobile configuration on 2026-10-02; we read the unused-javascript audit from each JSON report. Two were dropped — railway.com produced no report and www.shopify.com hit a protocol timeout — leaving 32. One run per site, no averaging, no repeat.

Reduce unused JavaScript is the Lighthouse audit that measures how much of every downloaded script the browser parses and never runs. Across 32 homepages measured once each, 29 carried at least one such script. The median site shipped 347 KB of code that never executed, the busiest shipped 1.4 MB, and three homepages shipped none at all.

How we measured it

The audit is the one Lighthouse titles "Reduce unused JavaScript", and it works from V8's code coverage rather than from a size guess. For every script the page loads, it reports two numbers: the bytes transferred, and the bytes of that script that were never executed before the run ended. The difference is the waste it reports.

We ran one headless Lighthouse per host with only that audit enabled, read the per-script values straight from the JSON, and summed the waste for each site. We did not re-run any site, and we did not touch the pages. Several hosts redirected us to a market-specific path because of where this machine sits — developer.mozilla.org landed on /zh-CN, slack.com on /intl/zh-cn, canva.com on /zh_cn, stripe.com on /nl, and our own querywin.com on /zh — and we kept whatever the redirect served.

Reduce unused JavaScript: 29 of 32 homepages carry it

Three homepages came back with nothing to report: Astro's marketing site, MDN, and Hacker News. Every other host carried at least one flagged script, and the top four each carry more than 1 MB of code that never ran. The table is the full panel, worst first, in kilobytes.

The shape is a long tail with a heavy head. Sorted into bands, four homepages carry more than a megabyte and four carry less than 200 KB, with three more that flag nothing. The median of 347 KB is waste alone — code that was fetched and never ran — and it sits on top of whatever the page's scripts actually executed.

Unused JavaScript is not dead weight you can see. The page renders fine; the visitor pays for code that never runs.

Where the waste comes from

Split by origin, roughly two-thirds of the wasted bytes — 9,977 KB of 15,430 KB — come from scripts served by a domain other than the site's own, even after counting subdomains as first-party. The single clearest example is Google's reCAPTCHA: the same widget shows up near the top of the list on several unrelated hosts, at roughly 250 KB of unused JavaScript each, because the page loads the full internationalized script and uses a fraction of it.

Two patterns run through the table. First, third-party tags are a large share of the waste and the hardest to remove, because you rarely control how much they ship and they change under you. A tag manager that measures 755 KB, or a CAPTCHA that costs a quarter of a megabyte on every page, is a decision made by someone else that you still pay for. Second, first-party bundles waste too: the New York Times' vendor chunk and Wired's paragraph bundle are each around a quarter-megabyte of code the first screen never touches. Neither pattern has a one-line fix, which is the honest news in this table.

What this means for you

Your own number takes one command, no account and no sign-up.

npx lighthouse https://example.com/ \
  --only-audits=unused-javascript \
  --output=json --output-path=ujs.json --quiet

• Run it on your homepage and on one heavy inner page. Homepages and article pages waste JavaScript in different places
• Read the third-party entries first. They are the ones you can often delete or delay without touching your own build
• Treat the waste number as a floor. It counts only the code that had not run by the time the run ended, so it undercounts interactions a real visitor triggers
• Do not chase the number by deleting code you cannot confirm is unused. Coverage measures this run, not every path through the app
• Do not assume a framework's code-splitting already solved it. Wired and the New York Times both split their bundles and both still top the list

If you want to see what the same scripts cost before the first paint, that is a different measurement: render blocking resources covers the ordering half, and async vs defer on 27 homepages covers how the scripts are loaded. The main-thread time they burn is the subject of the total blocking time survey.

What the numbers do not tell you

Three limits, and the first one matters most. The audit only counts code that had not executed when the run stopped. A script that a visitor never triggers — a modal, a checkout flow, an admin path — looks entirely unused here even if a minority of visitors use it every day. This is a floor, not a verdict.

Second, "nothing flagged" is not the same as zero unused JavaScript. Lighthouse only lists scripts above a reporting threshold, so a site with several small partly-unused files can come back clean. The three zeroes in this table are a good outcome, but we cannot tell you from this run whether Astro, MDN and Hacker News truly ship nothing unused or simply ship nothing large enough to list. We did not measure below that line.

Third, this is one lab run per site and a single snapshot. Coverage is stable against re-runs in a way that load timings are not, but it still describes the homepage as it existed on 2026-10-02, on one machine, with market redirects on some hosts. Treat a single reading as a direction, not a score.

Common questions

How did you measure this?

One headless Lighthouse run per homepage on 2026-10-02, mobile configuration, reading the unused-javascript audit from the JSON output. No repeats, no averaging, no field data. The sample is 32 homepages of one type, and it includes our own four sites. Two of the 34 attempted were dropped and are named in the method block.

How do I find unused JavaScript on my site?

Run the audit in the command above, or open the Coverage panel in Chrome DevTools, which shows the same data live. The audit gives you the number and the file list; DevTools lets you click a file and see exactly which lines never ran. Start with the largest third-party script, because removing it usually needs no build change.

Does unused JavaScript affect SEO?

Not directly. There is no ranking signal called "unused bytes". It matters through the cost it adds to loading and to the main thread, which show up in Core Web Vitals — mainly largest contentful paint and interaction to next paint. Treat it as a performance input, not a ranking field.

Is unused JavaScript the same as render-blocking JavaScript?

No. Render blocking is about ordering — a script that stops the page from painting until it arrives. Unused JavaScript is about volume — code that arrived and never ran. A script can be deferred, so it never blocks, and still waste a quarter of a megabyte. They are different problems with different fixes.

Why do third-party scripts waste so much?

Because they are built to work on every site that embeds them, so they ship every branch and every locale in one file and let the page use a fraction. The internationalized reCAPTCHA script in this panel is the pattern: one file, many languages, one page that needs one of them. You usually cannot slim it down, only decide whether it belongs on the page at all.

Next step

The number is easy to get and hard to argue with. Take your own, sort the third-party entries first, and ask of each one whether the page still does its job without it. Watching how much of the code you ship actually runs is part of what QueryWin works on.