Why Bundle Size Matters

JavaScript is the most expensive resource on the web. Byte for byte, a JS file costs more than an image — because the browser doesn't just download it, it parses, compiles, and executes it.

A 500KB image takes time to download. A 500KB JS bundle takes time to download, parse, compile, and run.

Step 1: Measure What You Have

You can't optimize what you can't see. Start with:

• Webpack Bundle Analyzer or Rollup Visualizer to visualize your bundle by module

• bundlephobia.com to check any npm package before you install it

Look for the 20% of modules that make up 80% of your bundle.

Step 2: Code Splitting

Route-based code splitting is the highest-leverage change for most apps. Instead of shipping one massive bundle for every route, ship only the code each route actually needs.

Typical savings: 40–60% reduction in initial bundle size.

Step 3: Tree Shaking

Make sure your bundler is eliminating dead code. This requires using ES module syntax and importing named exports instead of entire modules.

Step 4: Audit Your Dependencies

Run depcheck to find unused dependencies. Common replacements:

• moment.js (67KB) → Intl.DateTimeFormat (built-in)

• lodash (70KB) → native array methods

• axios (13KB) → native fetch

Step 5: Defer Non-Critical Scripts

Scripts that don't affect the initial render should load after it. Use defer for scripts that need the DOM, async for independent scripts.

The Benchmark

A good target for a marketing site initial bundle: under 100KB compressed. For a complex web app: under 250KB. If you're over 500KB, you have work to do.