What Is Unused JavaScript? Complete Guide (2026)

Why Unused JavaScript Hurts Performance and Rankings

JavaScript is the most expensive byte on the web. Unlike images or CSS, JS goes through four stages — download, parse, compile, execute — and unused code pays the first three of those costs in full. Concretely, unused JS:

• Blocks the main thread.Parse and compile run synchronously. While the browser is chewing on a 500 KB bundle that's half dead code, it can't respond to taps or paint the LCP element.
• Inflates Total Blocking Time and INP. Both metrics measure main-thread availability. More unused JS = more long tasks = worse scores.
• Slows Largest Contentful Paint. If the LCP element is rendered by JavaScript (a common pattern in single-page apps), every millisecond of parse cost delays the paint.
• Wastes mobile data and battery. Mobile CPUs parse JS 2–4× slower than desktops. Industry analysis consistently shows mobile parse cost dominates total blocking time on mid-range Android devices.
• Drags down rankings. Core Web Vitals (LCP, INP, CLS) are confirmed Google ranking signals. A bundle that wastes 300+ ms of main thread tends to fail INP at the 75th percentile.

Where Unused JavaScript Comes From

Almost every site accumulates unused JS through the same handful of patterns. Identifying which of these apply to your codebase tells you which fix to reach for.

• Whole-library imports.Importing all of a utility library when you only need one function. The bundler can't always tree-shake what looks like a side-effecting CommonJS module.
• Polyfills shipped to modern browsers. Older toolchains transpile ES2020+ down to ES5 and ship the polyfills to every visitor — including the 95% on evergreen browsers.
• Single-bundle architectures. A SPA that bundles every route into one file forces homepage visitors to download checkout, settings, admin, and dashboard code they may never see.
• Dead code from old features. Components, A/B test arms, and feature-flagged paths that never got removed after the experiment ended.
• Vendor bundles that bypass tree-shaking. A single CommonJS dependency in a chain can poison tree-shaking for the whole vendor chunk.
• Third-party tags.Analytics, chat, and consent scripts often include features you don't use — and they're hard to tree-shake because they're loaded as opaque blobs.

Worked example: a single bad import

The classic offender is a library import that pulls in the whole package instead of the single function you need:

// Bad: pulls the entire library into your bundle (~70 KB)
import _ from 'lodash';
const debounced = _.debounce(handler, 250);

// Good: pulls only the function you use (~2 KB)
import debounce from 'lodash/debounce';
const debounced = debounce(handler, 250);

// Also good: tree-shakable ESM build
import { debounce } from 'lodash-es';

That single change can cut a vendor chunk from ~70 KB to ~2 KB — a 35× reduction for one utility. Multiply that across a real codebase and the savings are in the hundreds of kilobytes.

How to Measure Unused JavaScript

Unused JS shows up in two places: synthetic audits (lab data) and real-user metrics (field data). You want both — synthetic tells you which scripts are bloated; field tells you which pages actually suffer.

• Greadme deep scan— flags every script with > 20 KB or > 50% unused bytes, identifies the offending file, and pairs each finding with an AI-generated fix or a one-click GitHub PR.
• Greadme crawler scan — measures unused JS across every indexable page so you can see which routes or templates carry the most dead code.
• Greadme AI visibility analyzer — checks whether your bundle weight is hurting the CWV scores that AI search engines use as a citation signal.
• Chrome DevTools → Coverage tab— open DevTools, run "Show Coverage" from the command menu, reload the page, and you'll see exactly which lines of every script ran. Anything red is unused on that page load.
• Google Search Console → Core Web Vitals report — shows real-user INP and LCP at the 75th percentile. If those are failing, unused JS is usually a contributor.
• web.dev measure — runs a synthetic audit and lists every script with significant unused bytes, with the savings in KB.

8 Proven Ways to Eliminate Unused JavaScript

// Bad
import * as Icons from 'react-icons/fa';
<Icons.FaCheck />

// Good
import { FaCheck } from 'react-icons/fa';

// Also good — direct path import
import FaCheck from 'react-icons/fa/FaCheck';

// Static import: ships in main bundle
import Modal from './Modal';

// Dynamic import: ships only when the user opens the modal
button.addEventListener('click', async () => {
  const { default: Modal } = await import('./Modal');
  Modal.open();
});

<!-- Modern browsers download this -->
<script type="module" src="/app.modern.js"></script>

<!-- Only legacy browsers download this -->
<script nomodule src="/app.legacy.js"></script>

// webpack.config.js
module.exports = {
  performance: {
    hints: 'error',
    maxAssetSize: 200_000,        // 200 KB per chunk
    maxEntrypointSize: 250_000,   // 250 KB initial entry
  },
};

Common Unused-JS Problems and Fixes

Unused JavaScript Thresholds at a Glance

Synthetic audits use a fixed threshold to decide when unused JS is worth flagging. The rule of thumb:

Industry analysis (HTTP Archive Web Almanac) shows the median page sits in the "Needs improvement" band — most sites ship 35–40% unused JS at p50.

FAQ

What counts as "unused" JavaScript?

Any JS that's downloaded, parsed, and compiled but never executed during the page load. Synthetic audits measure this by instrumenting the script and counting which lines ran. A function that's defined but never called is unused. A whole library you import but only use one method from is mostly unused.

How much unused JavaScript is too much?

Audits flag a script when unused bytes exceed 20 KB or 50% of the file. In practice, the cost becomes painful (visible INP and LCP regressions on mobile) once the unused portion of your initial bundle exceeds ~100 KB.

Does unused JavaScript affect SEO?

Yes, indirectly. Unused JS slows the main thread, which worsens INP and LCP — two of Google's three Core Web Vitals and confirmed ranking signals. Pages with poor CWV at the 75th percentile lose ranking ground in competitive queries.

Why is the median page still 35–40% unused JS?

Three reasons: most sites still bundle every route together, most apps still ship polyfills to modern browsers, and most teams import whole libraries instead of named methods. Each of those is a fix any engineer can make in an afternoon — but they require active attention, and bundle size only gets measured when something breaks.

Will tree-shaking remove all unused JS automatically?

Only if every link in the dependency chain uses ES modules and declares its side effects correctly. A single CommonJS package or a missing "sideEffects": false can force the bundler to keep code it would otherwise drop. Tree-shaking is necessary but not sufficient — code splitting and dynamic imports do the rest.

Does unused JavaScript affect AI search engines like ChatGPT and Perplexity?

Indirectly, yes. Generative search systems most often cite pages that already rank well in traditional search — and Core Web Vitals are part of that ranking signal. Google AI Overviews preferentially surfaces pages that pass CWV. A bundle bloated with unused JS pushes INP above the 200 ms threshold, hurts your rankings, and reduces your odds of being chosen as a citation.

How do I find unused JS without instrumenting the browser myself?

Run a Greadme deep scan on the page — it surfaces every script with significant unused bytes, and pairs each finding with an AI-generated fix. For a manual check, Chrome DevTools' Coverage tab shows used vs. unused bytes line-by-line; Google Search Console's Core Web Vitals report tells you if real users are feeling the pain.