<p>Last month I ran a dependency audit on a production React app. It had 1,847 packages in node_modules. The app took 14 seconds to build and the bundle was 2.3MB gzipped.</p>
<p>After the audit: 891 packages. 6-second builds. 940KB bundle. Same features. Better performance. Zero user-facing regressions.</p>
<p>Here’s exactly how I did it — step by step — so you can do the same.</p>
<h2>Step 1: Understand what you actually have</h2>
<p>Before removing anything, you need visibility. Run this:</p>
<pre><code class="language-bash">npx depcheck
</code></pre>
<p><code>depcheck</code> scans your codebase and identifies:</p>
<ul>
<li><strong>Unused dependencies</strong> — packages in package.json that no file imports</li>
<li><strong>Missing dependencies</strong> — packages your code imports but aren’t in package.json</li>
<li><strong>Phantom dependencies</strong> — packages you use that are only available because something else installed them</li>
</ul>
<p>In my case, depcheck found 23 unused dependencies. Some highlights:</p>
<ul>
<li><code>moment</code> — replaced by <code>dayjs</code> 8 months ago, but never removed</li>
<li><code>lodash</code> — only used for <code>_.debounce</code>, which is 4 lines of vanilla JS</li>
<li><code>axios</code> — the team had migrated to <code>fetch</code> but left axios as a “backup”</li>
<li>Three different CSS-in-JS libraries from three different team experiments</li>
</ul>
<h2>Step 2: Analyze your bundle</h2>
<pre><code class="language-bash">npx vite-bundle-visualizer
<span class="hljs-comment"># or for webpack:</span>
npx webpack-bundle-analyzer
</code></pre>
<p>This generates a treemap showing exactly what’s in your bundle and how much space each package takes. The visual representation makes bloat obvious in a way that package.json never does.</p>
<p>My findings:</p>
<ul>
<li><code>moment</code> with all locales: 287KB (was unused!)</li>
<li><code>lodash</code> full build: 71KB (for one function!)</li>
<li>A markdown parser only used in an admin page: 145KB in the main bundle</li>
</ul>
<h2>Step 3: The replacement strategy</h2>
<p>For each heavy dependency, I asked three questions:</p>
<ol>
<li>Can I remove it entirely?</li>
<li>Can I replace it with a lighter alternative?</li>
<li>Can I lazy-load it?</li>
</ol>
<p><strong>Removals:</strong></p>
<ul>
<li><code>moment</code> → deleted (using dayjs already)</li>
<li><code>axios</code> → deleted (native fetch everywhere)</li>
<li><code>lodash</code> → wrote a 4-line debounce function</li>
<li>3 unused UI component libraries → deleted</li>
</ul>
<p><strong>Replacements:</strong></p>
<ul>
<li><code>date-fns</code> → <code>dayjs</code> (tree-shakeable, 2KB vs 20KB used)</li>
<li><code>uuid</code> → <code>crypto.randomUUID()</code> (built into every modern runtime)</li>
<li><code>classnames</code> → template literals (it was being used for simple string concatenation)</li>
</ul>
<p><strong>Lazy-loaded:</strong></p>
<ul>
<li>Markdown parser → dynamic import, only loads on admin routes</li>
<li>Chart library → lazy loaded behind an intersection observer</li>
<li>PDF generator → loaded on-demand when user clicks “Export”</li>
</ul>
<h2>Step 4: Verify nothing broke</h2>
<p>This is the critical step most people skip. After each removal:</p>
<ol>
<li>Run the full test suite</li>
<li>Build and check bundle size</li>
<li>Smoke test critical user flows</li>
<li>Check for runtime errors in the browser console</li>
<li>Verify SSR still works if applicable</li>
</ol>
<p>I made one removal per commit. If something broke, the git bisect was trivial.</p>
<h2>Step 5: Prevent future bloat</h2>
<p>Added three guardrails:</p>
<ol>
<li><strong>Bundle size budget</strong> in CI — build fails if bundle exceeds 1MB gzipped</li>
<li><strong>depcheck in pre-commit hook</strong> — flags unused dependencies before they get merged</li>
<li><strong>Monthly dependency review</strong> — calendar reminder to run the audit</li>
</ol>
<h2>The results</h2>
<table>
<thead>
<tr>
<th>Metric</th>
<th>Before</th>
<th>After</th>
<th>Change</th>
</tr>
</thead>
<tbody>
<tr>
<td>Dependencies</td>
<td>1,847</td>
<td>891</td>
<td>-52%</td>
</tr>
<tr>
<td>Build time</td>
<td>14s</td>
<td>6s</td>
<td>-57%</td>
</tr>
<tr>
<td>Bundle size</td>
<td>2.3MB</td>
<td>940KB</td>
<td>-59%</td>
</tr>
<tr>
<td>Lighthouse perf</td>
<td>62</td>
<td>89</td>
<td>+44%</td>
</tr>
<tr>
<td>Time to Interactive</td>
<td>4.2s</td>
<td>1.8s</td>
<td>-57%</td>
</tr>
</tbody>
</table>
<p>The performance improvement was directly measurable in user engagement. Bounce rate dropped 12% in the week after deployment.</p>
<h2>The lesson</h2>
<p>Dependencies are easy to add and hard to remove. Every <code>npm install</code> is a decision that compounds. The JavaScript ecosystem’s default is abundance — our job is to practice restraint.</p>
<p>When was the last time you audited your dependencies? Your node_modules might be hiding some surprises.</p>


sirajju

A practical walkthrough of auditing and slimming down a production React app's dependencies. Starting from 1,847 packages and a 2.3MB gzipped bundle, the author used depcheck and bundle visualizer tools to identify unused, redundant, and oversized packages. The process involved removing dead dependencies (moment, axios, lodash), replacing heavy libraries with lighter alternatives or native APIs, and lazy-loading infrequently used modules. The result: 891 packages, 940KB bundle, 6-second builds, and a Lighthouse performance score jump from 62 to 89. The post also covers verification steps after each removal and CI guardrails to prevent future bloat.

I Mass-Deleted My NPM Dependencies and My App Got Faster — Here's the Full Audit Process

<p>The moment.js with all locales being 287KB while unused is such a classic. I’ve seen this exact scenario at three different companies. Also — crypto.randomUUID() replacing the uuid package is something more people need to know about.</p>
