Vad är code splitting och tree shaking?

Question

IT Interview Practice · Accepted Answer

Båda skär ner den JavaScript som användare laddar ner. **Code splitting** bryter upp bundlen i chunks som laddas på begäran; **tree shaking** tar bort kod du aldrig använder. De kompletterar varandra: dela upp *vad* som laddas, skaka ut *död* kod inuti varje chunk.

## Code splitting

Istället för en stor bundle delas appen upp så att varje route eller tung funktion är en separat chunk som hämtas bara när den behövs:

```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();
};
```

Det dynamiska `import()` är signalen — bundlern skapar en separat fil vid den gränsen.

## Tree shaking

Bundlern analyserar statiskt ES-modulens `import`/`export` och kastar de exports som inget refererar. Det fungerar bara med **ESM** (statiskt, analyserbart) — inte CommonJS `require`:

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

Det förlitar sig på `"sideEffects": false` i `package.json` och per-funktions-importer; barrel-filer eller sidoeffekt-tunga moduler kan omintetgöra det.

## Avvägningar

- Överdriven uppdelning → många små requests och waterfalls; gruppera relaterad kod.
- Tree shaking är skört — en felmarkerad sidoeffekt behåller död kod.

## Varför det är viktigt

Detta är de två spakarna bakom "skicka mindre JS." Intervjuare vill att du vet att code splitting avgör *vad som laddas när*, tree shaking avgör *vad som överhuvudtaget finns i den*, och att tree shaking beror på statisk ESM — en detalj som skiljer folk som faktiskt trimmat en bundle från dem som bara läst om det.

Code splitting

Tree shaking

Avvägningar

Varför det är viktigt

Relaterade frågor