Bundle Size Budgets and Analysis

The plain-language idea

You already know what bundling and tree shaking do. What that knowledge doesn't give you is a way to answer two very practical questions: what's actually taking up space in this bundle right now, and how big is too big. Those are analysis and budgeting problems, not bundling mechanics problems.

Bundle analysis means visualizing a real, built bundle to see which modules contribute which bytes — usually as a treemap, where each rectangle's area is proportional to that module's size. A size budget is a concrete number (per route, per chunk, or for the whole initial load) that a bundle isn't allowed to exceed, checked against something real instead of vibes.

Two numbers matter here, and they're not the same:

• Advertised or minified size — the raw byte count of the minified source, the number a package's README usually brags about.
• Compressed transfer size (gzip or brotli) — what the browser actually downloads over the wire, since virtually every production server compresses text assets. A library can look large minified and small compressed (repetitive code compresses well) or the reverse.

Budgets should be set against the compressed number, because that's the one tied to real download time.

See it in a real thing: a treemap reveals a duplicate dependency

lodash@4.17.21        (bundled once, ~24kb gzipped)
lodash@3.10.1          <- pulled in transitively by an old chart library
  (a second, near-identical copy, another ~22kb gzipped)

A treemap view of a real bundle (from a tool like webpack-bundle-analyzer, source-map-explorer, or Vite's rollup-plugin-visualizer) would show this as two separate, similarly-sized rectangles both labeled lodash, not one. That's the tell: the same library is bundled twice because two different dependencies in the tree each pinned an incompatible version range, and the package manager couldn't safely dedupe them into one shared copy. Nobody wrote import lodash from "lodash" twice on purpose — it happened silently, several npm installs deep in someone else's dependency, and it shipped an extra ~22kb gzipped that does nothing.

This is exactly the class of problem a bundle analyzer is good at catching and a code review is not: no line of your own source code looks wrong, because the duplication lives entirely in the dependency graph.

What people usually miss

Watch out

• A package that looks "small" in its README can still be expensive. Minified size and gzipped size can diverge a lot; always check the compressed number, since that's the one that determines real download time on a real connection.
• A treemap shows relative size, which is often more actionable than absolute size. A 40kb module isn't automatically a problem — a 40kb module that's 60% of your entire initial bundle almost certainly is, and a treemap makes that proportion visually obvious in a way a flat list of file sizes doesn't.
• Duplicate dependency versions are a genuinely common, genuinely silent source of bloat. They don't show up as a lint error or a failing test — only an analyzer visualization or a manual lockfile audit surfaces two versions of the same library sitting in the same bundle.
• A budget with no enforcement is just a comment nobody reads. Setting a target number for a route or chunk is only the first half; the number is the input to a later, separate step (wiring it into CI so a build actually fails when it's exceeded), not the whole solution by itself.

Why this matters in interviews

"The bundle grew after a recent PR — how would you find out why?" is a real, practical question, and naming a bundle analyzer plus the duplicate-dependency-version failure mode is a much stronger answer than a vague "I'd check the imports."