Reducing Bundle Size in Modern Web Apps

JavaScript costs more than its size

A kilobyte of JavaScript is more expensive than a kilobyte of an image, because the script must be downloaded, parsed, compiled, and executed before it does anything, and much of that work blocks the main thread. The cost is felt most on lower-end devices, where parsing and execution are slow, so a bundle that feels fine on a developer’s machine can make a page sluggish or unresponsive on a typical phone. Bundle size is a proxy for this whole chain of work.

This is why reducing bundle size is one of the highest-impact performance levers on the web. Trimming the JavaScript a page ships improves not just download time but the parse and execution time that determines when the page becomes interactive.

Ship only what the page needs

The largest gains usually come from not shipping code a page does not use. Code splitting breaks the application into pieces that load on demand, so a visitor to one page does not download the code for every other page. Tree shaking removes code that is never referenced, so unused functions from a library do not ride along. Together they narrow the bundle to what the current page actually requires.

• Split code so each page loads only what it needs, not the whole application.
• Rely on tree shaking to drop code that is never referenced.
• Defer loading code for features the user has not yet reached.

Dependencies are where bundles balloon

A single dependency added without thought can be larger than all the code a team wrote. A heavy library pulled in for one small function, or a package that bundles far more than is used, inflates the bundle out of proportion to the benefit. Auditing what each dependency costs, preferring smaller focused libraries, and sometimes writing the small amount of code yourself rather than importing a large package are how teams keep bundles in check.