What are code splitting and tree shaking?

Question

IT Interview Practice · Accepted Answer

Both cut the JavaScript users download. **Code splitting** breaks the bundle into chunks loaded on demand; **tree shaking** removes code you never use. They're complementary: split *what* loads, shake out *dead* code inside each chunk.

## Code splitting

Instead of one big bundle, the app is split so each route or heavy feature is a separate chunk fetched only when needed:

```js
// Route-based split: the dashboard code isn't downloaded until you visit it
const Dashboard = lazy(() => import("./routes/Dashboard")); // its own chunk

// Component-based split: heavy editor loaded on interaction
button.onclick = async () => {
  const { openEditor } = await import("./editor"); // fetched on click
  openEditor();
};
```

The dynamic `import()` is the signal — the bundler emits a separate file at that boundary.

## Tree shaking

The bundler statically analyzes ES module `import`/`export` and drops exports nothing references. It only works with **ESM** (static, analyzable) — not CommonJS `require`:

```js
import { debounce } from "utils"; // only debounce is kept; throttle, etc. are shaken out
```

It relies on `"sideEffects": false` in `package.json` and per-function imports; barrel files or side-effectful modules can defeat it.

## Trade-offs

- Over-splitting → many tiny requests and waterfalls; group related code.
- Tree shaking is fragile — a mis-marked side effect keeps dead code in.

## Why it matters

These are the two levers behind "ship less JS." Interviewers want you to know code splitting decides *what loads when*, tree shaking decides *what's in it at all*, and that tree shaking depends on static ESM — a detail that separates people who've actually tuned a bundle from those who've only read about it.

Code splitting

Tree shaking

Trade-offs

Why it matters

Related questions