Hvad er code splitting og tree shaking?

Question

IT Interview Practice · Accepted Answer

Begge skærer i den JavaScript, brugere downloader. **Code splitting** opdeler bundlen i chunks, der indlæses on demand; **tree shaking** fjerner kode, du aldrig bruger. De er komplementære: split *hvad* der indlæses, ryst *død* kode ud inde i hver chunk.

## Code splitting

I stedet for én stor bundle opdeles appen, så hver route eller tung feature er en separat chunk, der kun hentes, når der er brug for den:

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

Den dynamiske `import()` er signalet — bundleren udsender en separat fil ved den grænse.

## Tree shaking

Bundleren analyserer statisk ES-modulers `import`/`export` og fjerner exports, som intet refererer til. Det virker kun med **ESM** (statisk, analyserbart) — ikke CommonJS `require`:

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

Det er afhængigt af `"sideEffects": false` i `package.json` og per-funktion-imports; barrel files eller moduler med side effects kan besejre det.

## Afvejninger

- Over-splitting → mange små requests og waterfalls; gruppér relateret kode.
- Tree shaking er skrøbeligt — en fejlmarkeret side effect beholder død kode.

## Hvorfor det betyder noget

Dette er de to håndtag bag "send mindre JS". Interviewere vil have, at du ved, at code splitting afgør *hvad der indlæses hvornår*, tree shaking afgør *hvad der overhovedet er i den*, og at tree shaking afhænger af statisk ESM — en detalje, der adskiller folk, der faktisk har tunet en bundle, fra dem, der kun har læst om det.

Code splitting

Tree shaking

Afvejninger

Hvorfor det betyder noget

Relaterede spørgsmål