Bundling & Code-Splitting

1The goal: ship less JavaScript

Every other byte (HTML, CSS, images) is cheaper than JS. A JS byte gets downloaded, parsed, compiled, and executed on the main thread — and that execution is what blocks INP and delays interactivity (Lessons 02–03). So the whole game is: send the least JS that makes this page work, and no more. Three tools, in order of impact:

1. Code-splitting — break one giant bundle into chunks loaded on demand, so a route only pays for its own code.
2. Tree-shaking — statically drop code you import but never use (dead-code elimination).
3. Pruning & swapping — kill duplicate deps, replace heavy libraries, analyze what's actually in there — then guard it in CI so it can't creep back.

2Code-splitting — route, component, vendor

A bundler creates a new chunk at every dynamic import() — a “split point.” That chunk is fetched only when the code path runs. The static import at the top of a file always ends up in the initial bundle; import() is the lever. [MDN]

// static — always in the initial bundle
import { formatPrice } from './utils';

// dynamic — its own chunk, fetched only when this runs
button.addEventListener('click', async () => {
  const { openMap } = await import('./heavy-map-widget');
  openMap();
});

React's official pattern is lazy + Suspense; the import must resolve to a module with a default export. [react.dev]

Vendor splitting in practice: route/component splits cut how much JS loads; vendor splitting changes how well it caches. You configure it (Webpack optimization.splitChunks, Vite/Rollup manualChunks) rather than via import(). The nuance: granularity is a trade-off. One giant vendor chunk means a single dep bump busts the cache for the whole vendor bundle for every user; too many tiny vendor chunks bring back the request-waterfall problem. Split into a few sensible groups (e.g. framework vs the long tail), and let content hashing do the rest. [web.dev — granular chunking]

const Checkout = React.lazy(() => import('./Checkout'));

<Suspense fallback={<Skeleton/>}>
  <Checkout/>
</Suspense>

The split feels slower: a spinner on first navigation

A classic consequence: you route-split, and now clicking into a route shows a loading spinner — users say the app got slower. You didn't add cost, you moved it: that route's code is no longer in the initial bundle, so it's discovered at click time → fetch → render. The fix is to pay that cost before the click, not to undo the split:

• Prefetch on intent — fetch the chunk on link hover / touchstart / focus, or when the link enters the viewport (IntersectionObserver). Routers do this: Next's <Link> prefetches in-viewport links, React Router has prefetch. By click time the chunk is cached → instant nav. (Lesson 01 — <link rel=prefetch> / Speculation Rules.)
• Keep the old UI alive — wrap the navigation in React's startTransition/useTransition so the current page stays interactive while the next chunk loads, instead of yanking to a Suspense fallback. [react.dev]
• Make the fallback honest — a skeleton matching the layout (not a spinner), space reserved to avoid CLS, and a ~200ms delay so fast connections never flash it.
• Or merge it back — a tiny route that's almost always visited next gained nothing from splitting but a round-trip. Granularity is a dial.

3Tree-shaking — how it actually works

Tree-shaking = dead-code elimination across modules. The bundler builds a graph of every export and which are actually imported, then drops the unreachable ones. The whole thing rests on one property: [MDN]

• It needs ES Modules. import/export are static — bindings are known at build time without running the code, so the bundler can prove an export is unused. CommonJS require() is dynamic (it's a function call returning a value at runtime), so it can't be statically shaken — a major reason ESM matters. Prefer the -es / ESM build of a dependency (e.g. lodash-es).
• Then dead-code elimination prunes the unused exports during minification (the bundler marks them, the minifier deletes them).

Why sideEffects: false matters

A side effect is code that does something just by being imported — a polyfill, import './styles.css', registering a global, mutating a prototype. By default a bundler must be conservative: even if you use nothing from a module, it may have to keep it in case importing it does something. "sideEffects": false in package.json is a promise to the bundler: “my files do nothing on import — if an export isn't used, drop the whole file.” That upgrades tree-shaking from pruning unused exports to pruning entire unused modules. [webpack]

// package.json — "I have no import-time side effects"
{ "sideEffects": false }

// or list the files that DO (so CSS isn't dropped):
{ "sideEffects": ["*.css", "./src/polyfills.js"] }

4The bundler landscape — and why the new ones are fast

Have an opinion here. The split that matters: old guard written in JavaScript (Webpack, Rollup) vs new guard written in Go/Rust (esbuild, SWC, Turbopack, Oxc/Rolldown) that are 10–100× faster at the parse/transform step. And the architectural trick Vite popularized: don't bundle at all in dev.

SWC (Rust) is the analog for transforms — a Babel replacement Next.js uses to compile TS/JSX fast. [swc.rs] The 2026 theme to name: the JS toolchain is consolidating onto one fast Rust core — Oxc powers Rolldown and oxlint (≈50–100× faster than ESLint) and the formatter, so parser/resolver are shared instead of re-implemented per tool. [oxc.rs] [VoidZero]

Why Vite/esbuild feel instant

• Native ESM dev server. Webpack bundles your whole app before it can serve a dev page → start time grows with app size. Vite serves source files unbundled over native browser ESM and only transforms a module when the browser requests it → dev server starts near-instantly regardless of app size. [vite.dev]
• Dep pre-bundling. Third-party deps (which change rarely and may be CommonJS / have hundreds of internal modules) are pre-bundled once — fast, and avoids hundreds of requests. (Historically esbuild; folded into the Rust pipeline as Vite moves onto Rolldown.)
• Fast HMR. Because modules are independent over ESM, a change invalidates only that module's chain, not a re-bundle — edits reflect in milliseconds.
• Go/Rust parsing. The parse/transform that Babel does in JS is done in a compiled language, parallelized across cores.

The 2026 update worth knowing: Vite originally had a “split-brain” setup — esbuild in dev, Rollup in prod — which meant subtle dev/prod differences. Vite 8 (March 2026) unified both onto Rolldown (the Rust bundler on Oxc), so one engine serves dev and builds prod. The honest framing: the native-ESM dev model is still why dev is instant; Rolldown is what makes the production build Rust-fast and removes the two-bundler inconsistency. [oxc.rs]

5Find the weight — and govern it

You can't shrink what you can't see. The workflow:

• Analyze. webpack-bundle-analyzer / source-map-explorer / rollup-plugin-visualizer render a treemap of what's in the bundle — spot the surprise 300 KB lib, duplicate copies of the same dep at different versions, and dead weight. [analyzer]
• Swap heavy libs. Classic wins: moment (huge, no tree-shaking) → date-fns/dayjs/native Intl; full lodash → per-method or native; a chart/animation lib loaded eagerly → lazy-loaded.
• De-dupe. Multiple versions of the same dep bloat the bundle — resolve to one (peer deps / resolutions / a monorepo single-version policy).
• Compress on the wire. Bundling shrinks parse cost; Brotli/gzip shrinks transfer (different axis — Lesson 16). Both matter.

The Lead move: make it a guardrail, not a cleanup

A one-off bundle diet regresses the moment the next team ships. So you put a size budget in CI that fails the PR when a bundle crosses a threshold — size-limit, bundlesize, or Lighthouse-CI resource budgets. Now bundle size is a team discipline with a number, not a heroic quarterly cleanup. [web.dev]

6Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.