Why unused JavaScript hurts your site

Package registries like npm have made it easy to pull in hundreds of thousands of public libraries, but that convenience comes with a cost. Too often, bundles ship with packages that the application barely uses — or doesn't use at all. Every byte of that code still needs to be downloaded, parsed, compiled, and executed, which can directly impact your Core Web Vitals.

For Largest Contentful Paint (LCP), unnecessarily large assets compete for bandwidth with other resources. Client-side JavaScript that references LCP candidates only through markup rendered at runtime can delay when those resources are able to load in the first place.

Unused code also factors into Interaction to Next Paint (INP). The extra JavaScript delays resource loading, raises memory usage, and keeps the main thread busier than it needs to be — all contributors to poor responsiveness even if the code itself never runs.

Find what you're not using

Start by inspecting what your application actually ships. Chrome DevTools gives you a quick look at every network request:

  1. Open DevTools with Control+Shift+J (or Command+Option+J on Mac).
  2. Open the Network tab.
  3. Enable Disable cache.
  4. Reload the page.

For a more granular view, the Coverage tab in DevTools reports exactly how much of your CSS and JavaScript is executed versus left unused. Running a Lighthouse audit with a full configuration through the Node CLI will trace how much of that unused code your production build carries.

If your project is bundled with webpack, Webpack Bundle Analyzer shows what's inside the output. Add it to your configuration like any other plugin, then reload the app to get a zoomable treemap of the bundle. Parcel and Rollup have similar visualization tools of their own.

Reading the treemap lets you spot which packages dominate the payload and which ones look out of place. Pay close attention to large domains from a single dependency tree, since that's usually where the waste accumulates.

Cut the libraries you don't need

Once you see the packages in your bundle, verify that each one is actually being used. If a large dependency supplies several modules but you only consume one, switch to a direct import for that component rather than the full package. For any package that isn't imported anywhere in your code, remove it outright. And if a library is only relevant for interaction a user triggers later, lazy load it instead of shipping it on the initial page load.

Some libraries can't be broken into smaller imports. Before you accept them as a fixed cost, evaluate whether a custom implementation is small enough to replace them.