JavaScript Bundle Size Analyzer

In 2026, a frontend team ships a feature, the build succeeds, the tests pass — and the site gets measurably slower for everyone on a phone, because the new dependency added 90 KB of gzipped JavaScript that nobody measured. Bundle size is the rare performance metric that is both entirely within a developer's control and almost completely invisible without a tool. This analyzer exists to make it visible at the moment of the decision: before the merge, not after the regression.

The problem is a side effect of how the modern web is built. When webpack popularised module bundling around 2015, it let developers import freely from a vast npm ecosystem and ship one optimised file. That convenience hid the cost: a single import could pull in a library, its dependencies, and their dependencies, all concatenated into the bundle. moment.js became the cautionary tale — 72 KB gzipped, not tree-shakeable, included in full whether you used one date format or fifty — and the reason date-fnsand dayjs exist.

The countermeasures shaped today's tooling. Tree-shaking — dead-code elimination across ES modules, pioneered by Rollup and adopted by webpack — meant libraries that shipped as ES modules could be pruned to only the functions you imported. Code-splitting let apps load JavaScript per-route instead of all at once. And webpack-bundle-analyzer gave the world the treemap: the now-iconic picture of a bundle where the size of each box is the size of each module, and the moment-shaped rectangle dominating the view became a meme and a to-do item at the same time. The treemap on this page is that same visualization, rendered from your stats file in the browser.

Measurement turned into governance through the idea of a performance budget. Alex Russell's "Can You Afford It?" and the web.dev guidance crystallised a number — roughly 170 KB of gzipped JavaScript for the initial load — as the ceiling that keeps time-to-interactive tolerable on the median phone over 4G. The figure is deliberately strict because, as Addy Osmani documented in "The Cost of JavaScript," bytes are not equal: a megabyte of images decodes lazily, but a megabyte of JavaScript must be downloaded, parsed, compiled and executed on the main thread before the page is interactive — roughly a second of CPU on a median Android, before a line of it runs.

That is why this tool reports raw size next to gzip size, and parse time next to download time. Compression is a transport optimisation: gzip and Brotli shrink the bytes on the wire, which helps users on slow networks, but the browser still parses the full decompressed payload, which is what hurts users on slow CPUs — and slow CPUs and slow networks are usually the same users. A bundle that is small over the wire can still feel sluggish if its uncompressed size is large, so the honest verdict needs both numbers, which is what the budget bands and the network matrix here are built from.

The discipline that keeps bundles small is the same one that keeps dependency trees small: ask, before adding anything, what it costs. The leanest sites lazy-load everything off the critical path, prefer tree-shakeable libraries, swap heavyweight dependencies for modern featherweight ones, and wire a size check into CI so the budget is enforced by a robot rather than remembered by a human. This analyzer answers the "what does it cost" question in seconds — and pairs naturally with the npm dependency analyzer for the install footprint and the vulnerability scanner for the security of everything you ship.