Remove Unused JavaScript: How to Find and Fix It

What this means

"Unused JavaScript" is code the browser downloads but does not execute during the page load. A common case: you ship one bundle for the whole site, but a given page only calls a fraction of it. The rest is still fetched and processed before the browser can move on. The audit measures this with Chrome DevTools Coverage data, a line-by-line breakdown of which code ran, then reports the wasted bytes and the time you could save.

Why it matters

Unused JavaScript hurts performance two ways. First, the browser must download, parse, compile, and evaluate the script before it can finish rendering, which delays your LCP element from appearing. Second, even scripts loaded asynchronously compete for bandwidth with the resources you actually need, which is especially costly on mobile.

There is an interactivity cost too. Heavy script execution ties up the main thread, so the page can look ready while taps and clicks feel sluggish. That is exactly what Interaction to Next Paint (INP) measures. Shipping less JavaScript is one of the most reliable ways to improve LCP and INP at once.

How it gets flagged

Lighthouse flags every JavaScript file with more than 20 KiB of unused code and lists each one with its potential byte and time savings. To see the detail, open Chrome DevTools, click the three-dot menu, choose More tools, then Coverage, and reload the page. Each script shows a usage bar with unused lines in red. That red is your shortlist: the bigger the band on a large file, the more there is to win.

How to fix it

1. Split your code

Code-splitting breaks one big bundle into smaller chunks so the browser only downloads what a page needs. If you run a single-page app and see large amounts of "unused" JavaScript, the fix is usually better route-level splitting, not deleting code. React teams can use React.lazy(); Vue can lazy-load routes through Vue Router; Angular splits by route out of the box.

2. Tree-shake your bundles

Tree-shaking is dead-code elimination: your bundler drops exports that are never imported. Make sure your build uses ES modules and production mode so webpack, Rollup, or esbuild can shake effectively. This is often the only practical way to strip unused code out of large third-party libraries.

3. Defer and lazy-load non-critical scripts

Sometimes you need a script, just not during the initial load. Move it off the critical path with the defer attribute, or load it on interaction (for example, only initialise a chat widget when the user clicks it). A script that loads on interaction is no longer counted as unused JavaScript during the audited load. While you are in the build, also minify your JavaScript so the bytes you keep stay small.

4. Audit and trim third-party scripts

Tag managers, analytics, A/B testing, heatmaps, and social embeds are frequent sources of unused code. List every third-party tag, confirm each still earns its place, and remove or consolidate the rest. Load the ones you keep after the page is interactive rather than in the head.

5. Remove unused plugins (especially on a CMS)

On a CMS like WordPress, the easiest win is often removing plugins you no longer use, since each one can enqueue its own scripts site-wide. Replacing a trivial plugin with a few lines of code can delete a whole bundle from every page.

False positives

Coverage is a snapshot of one page load, so "unused" does not always mean "deletable." A script may be unused at load but essential the moment a user opens a menu, submits a form, or scrolls to a lazy-loaded section. That code shows as red even though you need it. The right response is usually to defer or split it so it loads on demand, not to remove it. Treat the audit as a ranked list of candidates, not a delete list.

Some unused code remaining after optimisation is normal. If your content depends on JavaScript, confirm nothing critical breaks; our JavaScript SEO and rendering guide covers how to keep search engines and AI crawlers seeing your content while you trim.

FAQ