I used to think bundle optimisation was someone else's problem. I'd write code using convenient namespace imports like import * as utils from './utils', run npm run build, and ship whatever came out. My bundles kept growing: 200KB, 300KB, 450KB, but I assured myself it was fine. After all, browsers were getting better, internet connections were faster, and devices were becoming more powerful.

Then I tested my 450KB utility library on a 3G connection. Four seconds to download. Lighthouse gave me an embarrassing performance score. That's when I learned I was shipping 60% unused code.

This article covers what I discovered about tree-shaking in Vite, the mistakes I was making, and how I fixed them.

What Tree-Shaking Actually Does

Tree-shaking is dead code elimination for ES modules. When you use import and export, you create a static dependency graph. Vite (via Rolldown) traces through this graph and removes exports that aren't being consumed. Basically, tree-shaking only works when the bundler can prove code is unused. If you give it ambiguous signals, it keeps everything safe.

The Anti-Patterns I Was Using

Take a utility component called dashboard.utils.ts as a real example. It exports eight standalone functions: hasActiveFilters, mapApplicationToTableData, resetPagination, updateFilterState, updatePagination, mapJobStats, normalizeFilter, and buildPagination. I only needed one, but here's how I used to import it

Vite can statically analyse and determine that only resetPagination is accessed here, and drop the rest, but that's the bundler doing you a favour, not you writing intentional code. You've imported the entire module and handed the cleanup responsibility to your build tool. It works until it doesn't.

And it stops working the moment you do something like this:

Once the namespace object is passed to console.log or spread into another structure, the bundler can no longer prove at build time which properties will be accessed at runtime. It has no choice but to keep all eight exports: hasActiveFilters, mapJobStats, buildPagination, and everything else, just in case.

This is a trap because the first version looks harmless. It gets past your linter, the build succeeds, and you move on. Then three weeks later, someone adds a debug log, passes the namespace to a utility, and suddenly your bundle is carrying dead weight you didn't notice.

The "Just in Case" Import Pattern

Eight dashboard utility functions imported. One actually used. Seven along for the ride on every page load.

The Fixes I Implemented

Named Imports Only

This provides a clear signal to the bundler: only resetPagination is needed. mapJobStats, buildPagination, normalizeFilter, and the rest can be safely removed from the final output.

Switching from namespace imports and over-importing to precise named imports was the single biggest improvement.

Pure Function Annotations

I noticed /* @\_\_PURE\_\_ */ comments in my build output. These tell the minifier a function call has no side effects, meaning if the return value is never used, the entire call can be safely removed.

In the snipper above, both resetPagination and buildPagination just take input, compute a value, and return it. No HTTP calls, no mutations, no DOM access. They have zero side effects. That's exactly what Vite looks for when deciding whether to annotate a call as pure:

Strategic Dynamic Imports

Imagine your project grows and you have a helpers/ directory with multiple utility files, date.helper.ts, dashboard.utils.ts, and others. The temptation is to import them all eagerly:

Every page component, all its dependencies, and all its templates are now bundled together and loaded on the first request, regardless of which page the user is actually visiting.

Instead, lazy-load each page so that it becomes its own separate chunk:

A user who only visits the dashboard never downloads the profile management or jobs page. The router calls loadPage('dashboard') on navigation, and everything else stays unloaded until it's needed.

My Current Practices

1. Named imports only
No import * as unless necessary.

2. Don't pass namespace objects to functions
Log specific properties, not the whole namespace.

3. Dynamic imports for optional features
If it's not needed for the initial render, lazy-load it.

4. Review dependencies
Replace non-tree-shakable libraries when possible.

Key Takeaway

Vite's tree-shaking is powerful, but it only works with your cooperation. Write code that gives the bundler clear signals about what's actually used.

Check your bundle. You might be shipping more dead code than you think.