Web Performance

Bundle Optimization

Reducing how much JavaScript a page ships, by splitting it and removing what is unused.

Bundle optimisation is reducing the JavaScript a page has to download, parse and execute — by splitting code so each route loads only its own, removing unused dependencies, and deferring what is not needed for the first render. It is usually the largest available improvement to Interaction to Next Paint, because parsing and execution block the main thread.

Definition

The techniques are code splitting by route or component, tree shaking to drop unused exports, lazy loading below-the-fold interactivity, and auditing dependencies — a date library or icon set imported whole is a common single-line cause of hundreds of kilobytes.

Transfer size understates the cost: a compressed bundle still has to be decompressed, parsed and executed, and that work happens on the main thread on a device far slower than a developer laptop.

Why It Matters

JavaScript is the most expensive resource per byte. Images delay what is shown; a large bundle delays when the page responds at all, which is what INP measures.

Example

Importing an entire icon library for four icons ships thousands of unused ones. Per-icon imports drop it to the four actually rendered.

The dependency audit is usually the biggest win

Code splitting gets the attention, but the largest single reductions usually come from one import.

An icon library imported whole for four icons ships thousands. A date library imported for one formatting call ships every locale. A UI kit imported at the package root pulls in components the page never renders. Each is a single line, each is invisible in review, and each can be tens or hundreds of kilobytes.

Check what the bundle actually contains before splitting it. A bundle analyser answers this in minutes, and the fix — a per-item import, or a smaller alternative — is usually smaller than the refactor that splitting requires.

How SlapMyWeb checks this

The audit reports total JavaScript transfer size and request count, and measures the main-thread work during load — which is what actually determines responsiveness. Transfer size alone understates the cost, because a compressed bundle still has to be decompressed, parsed and executed on a device far slower than a developer laptop.