Your app might look clean โ€” but if your node_modules is full of packages you don't actually use, it's like carrying a suitcase full of bricks you never open.

These unused libraries don't just clutter your project โ€” they can hurt performance, increase load times, and affect how real users experience your product.

Let's break it down.

๐Ÿ˜ The hidden cost of extra code

Even if you're not using a package, it might still:

  • Be included in your bundle
  • Be transpiled, analyzed, and watched by your dev tools
  • Add to the size of serverless functions
  • Introduce unused polyfills or side effects
  • Trigger unnecessary dependency updates

And worst of all: it often goes unnoticed.

๐Ÿ‘€ Why should users care?

Because it's the user who ultimately pays for your bloat:

  • Slower page loads, especially on mobile
  • Laggy interactions (main thread blocked)
  • Higher Time to Interactive (TTI) and LCP
  • Increased bundle size, even if only by a few KB per library
  • More chances of breaking due to transitive dependencies

A 200ms delay in interactivity can make users bounce. That unused charting library you forgot to remove? It's costing you conversions.

๐Ÿ” Common offenders

  • Old UI libraries no longer in use (e.g., Chakra, MUI, Bootstrap โ€” all at once ๐Ÿ˜…)
  • Analytics SDKs not configured
  • Unused date libraries (moment, date-fns, luxon)
  • Duplicate utility libraries (lodash, underscore, custom helpers)
  • Icon libraries pulled entirely instead of per-icon (@fortawesome/fontawesome, etc.)

๐Ÿ›  Real example: dead weight in the bundle

// This still imports ALL of lodash ๐Ÿ˜ฌ
import _ from 'lodash'
console.log(_.get(user, 'profile.name'))

Even if you're using one function, that line can cost 70KB+ if not tree-shaken properly.

Now imagine that repeated across 10+ unused or misused libraries. That adds up.

๐Ÿšซ Even dev-only dependencies can leak

  • Bundlers sometimes include dev-only libraries (like faker, eslint, @storybook/addon-*)
  • Misconfigured tools or poor tree-shaking can pull these into production builds
  • Serverless deployments include node_modules โ€” bloating cold start time

This slows down not just pages, but builds, CI, testing, and even deployments.

โœ… Best practices to avoid this

  • Run npm prune or pnpm prune before builds
  • Use import { get } from 'lodash' or switch to lodash-es
  • Regularly audit with npm ls, npm-check, or depcheck
  • Remove unused pages/components that still import old packages
  • Enable bundle analysis (@next/bundle-analyzer, webpack-bundle-analyzer)
  • Prefer native APIs when possible (e.g., URLSearchParams, Intl.DateTimeFormat)

๐Ÿงช Dev tooling to the rescue

  • Next.js: Add @next/bundle-analyzer
  • Vite: Use rollup-plugin-visualizer
  • Webpack: Try webpack-bundle-analyzer

These help you see exactly what's bloating your app โ€” and cut it.

๐Ÿ“Ž Final thoughts

Unused or unnecessary libraries are more than just "a few extra KB". They're:

  • Slowing down users
  • Increasing risk of bugs
  • Making your builds and deployments heavier
  • Breaking performance budgets

Clean code isn't just readable โ€” it's lean.

If it's not used, remove it. If it can be replaced with native code, do it. Your users will feel the difference โ€” even if they never see the code.