How to Reduce Unused JavaScript (and Speed Up Your Site)

Unused JavaScript is code your browser downloads, parses, and then never runs while the page loads. It is the most common problem we find in website audits, and on most business sites it is also one of the cheapest to fix, because you are usually paying for a script somebody installed once and forgot, or for a library where you use one function out of two hundred. This guide shows you how to find yours, how to reduce it without breaking anything, and how much speed you should honestly expect back.

The scale is worth stating plainly. Across the 161 audits run through our free tool so far, unused JavaScript was the single most flagged issue, appearing 42 times, ahead of slow mobile load at 36 and slow overall load time at 22. Unused code more broadly appeared another 20 times. These are ordinary business sites built by competent people. Nobody sets out to ship dead code. It accumulates.

What the "reduce unused JavaScript" warning actually means

When PageSpeed Insights or Lighthouse tells you to reduce unused JavaScript, it has loaded your page, watched which lines of each script actually executed, and added up the bytes that did not. It flags a file once it finds roughly 20 KiB or more of unused code, then reports an estimated saving in kilobytes and seconds.

Two things about that number matter before you act on it. First, unused does not mean useless. A checkout script is dead weight on the homepage and essential on the cart page, so the fix is often about when a script loads, not whether it should exist. Second, the estimated saving is optimistic, because it assumes you delete the bytes entirely. Deferring a script helps in a different way, by clearing the main thread, but the download still happens.

Why dead JavaScript costs more than its file size suggests

A 300 KB image and 300 KB of JavaScript are not the same expense. The image is downloaded, decoded once, and drawn. JavaScript is downloaded, parsed, compiled, and executed, and that work runs on the main thread, the same single thread the browser uses to render the page and respond to taps.

• Phones do this work several times slower. A bundle that costs 200 milliseconds on your laptop can cost close to a second on a mid range Android device, which is what a large share of your visitors are holding.
• It blocks interaction. Any task over 50 milliseconds is a long task, and while one is running a tap does nothing at all. This is what Interaction to Next Paint measures, and the good threshold is 200 milliseconds.
• It delays your main content. A script in the head without defer stops the HTML parser, which pushes back Largest Contentful Paint, the metric Google grades at 2.5 seconds.
• It compounds. Each third party script opens its own connections and pulls its own dependencies, so the real cost of adding one tag is rarely the size of that one tag.

Where it comes from on a typical business site

• Marketing tags nobody removed. A pixel for a campaign that ended, two analytics tools where one would do, a heatmap trial from last year. The largest and easiest category on most sites.
• Page builder and plugin bundles. Many builders load their full script and style set on every page regardless of what that page contains, so a plain text about page still carries the slider, the popup, and the form engine.
• Whole library imports. Pulling in a complete date, chart, or icon library to use one function ships everything else with it.
• Duplicate work. A carousel library, a lightbox, and a jQuery plugin doing overlapping jobs, added by three different people over three years.
• Chat widgets and A/B testing tools. Both are usually loaded on every page for every visitor, and both are commonly among the heaviest single scripts on a site.

How to find yours in ten minutes

1. Run PageSpeed Insights on your busiest page and read the mobile tab. Expand the "Reduce unused JavaScript" item and look at the file list. The domain names tell you within seconds whether this is your own code or a third party script sitting on your site.
2. Open Chrome DevTools, press Command Shift P (Control Shift P on Windows), and run "Show Coverage". Reload and record. You get a per file bar of used versus unused bytes, which is the same measurement with far more detail.
3. Open the treemap view in Lighthouse and check the third party summary, which shows the blocking time each external script contributes. Sort by that, not by file size, because a small script that runs long is worse than a large one that runs late.
4. Write down every script you cannot explain. Anything without a named owner and a current purpose is a removal candidate, not an optimisation candidate.

How to reduce unused JavaScript, in order of payback

1. Delete before you defer

Removing a script is the only fix that returns every millisecond it cost: the connection, the download, the parse, and the execution. Start with the tags you could not explain in step four. In most audits this alone clears a quarter to a half of the flagged bytes, at no engineering risk beyond confirming that a report you actually read still populates.

2. Load the rest at the right moment

For scripts you keep but do not need immediately, add defer so they run after the HTML is parsed, or async for independent third parties. Better still, load on interaction. A chat widget can wait until someone scrolls or moves toward the corner it lives in, and a video embed can be a static thumbnail that loads the player on click. This routinely takes several hundred kilobytes off the initial load without removing a single feature.

3. Split the bundle by route

On a modern framework, split your code so a visitor to the contact page does not download the booking flow. Every current build tool does this with dynamic imports, and the win is largest where one heavy feature lives on one page. On WordPress the equivalent is dequeuing plugin assets on the pages that do not use them, which is a filter of a few lines rather than a rebuild.

4. Import narrowly, or not at all

Import the three functions you use instead of the whole library, then ask whether the library is needed at all. Date formatting, network requests, and DOM selection are all things browsers now do natively, and several popular dependencies exist mainly to support browsers nobody runs any more.

5. Put the review on the calendar

Scripts accumulate because adding one takes a minute and nobody owns the total. A twenty minute review each quarter, checking the tag manager against the campaigns you are actually running, stops a site drifting back to where it started within a year.

Shipping less code beats loading the same code more cleverly, every time.

What to expect, and when this is the wrong project

On a typical site, deleting dead tags and deferring what remains moves the mobile performance score by ten to twenty five points and takes a second or more off the moment the page becomes usable. That is a real return on an afternoon of work.

Two cases make it the wrong project. If nearly all the flagged bytes come from one platform bundle you do not control, a theme or builder that loads everything everywhere, optimisation buys a few points and then stops, and the honest answer is that the platform itself is the cost. And if your real problem is that visitors arrive but do not enquire, speed is not your bottleneck. A fast page that fails to say what you do, who you do it for, and what to do next converts no better than a slow one.

For the exact files on your own site, run our free website audit: a scored view of speed, usability, and search and AI visibility in under a minute, no signup, naming the scripts that are holding you back. If the result points at something structural rather than an afternoon of cleanup, book a free discovery call and we will tell you plainly whether to optimise or rebuild.