Skip to content
← All writing
Frontend14 May 20266 min read

Your bundle isn't big. It's badly shaped.

Three webpack settings that mattered more than every dependency we removed.

By Semir Hamid

A team I worked with spent two weeks removing dependencies to get their bundle down. They got it from 1.1MB to 940KB and the page felt exactly the same, because the problem was never the total. It was that all 940KB had to arrive before anything rendered.

Split on routes before anything else

The single highest-leverage change in most apps. Nobody needs the admin dashboard's charting library to read the login page. Dynamic imports at route boundaries, and let the bundler do the rest.

Then check what's defeating tree-shaking

Usually one of two things: a package without a `module` entry, or your own code marked as having side effects. The second one is self-inflicted and free to fix.

json
{
  "name": "@app/ui",
  "sideEffects": ["*.css", "*.scss"]
}

// Without this, the bundler assumes every file in the package
// might do something on import and keeps all of them.

Then look at what's duplicated

Run the analyser and look for the same library appearing twice at different versions. It's almost always a date library or a polyfill, it's almost always transitive, and a resolution override fixes it in one line.

None of this is clever. It's just that bundle size is the metric everyone can see, and time-to-interactive is the one that matters.