Hva er code splitting og tree shaking?

Question

IT Interview Practice · Accepted Answer

Begge kutter JavaScript-en brukere laster ned. **Code splitting** deler bundelen inn i chunks som lastes ved behov; **tree shaking** fjerner kode du aldri bruker. De er komplementære: del *hva* som lastes, rist ut *død* kode inne i hver chunk.

## Code splitting

I stedet for én stor bundle deles appen slik at hver route eller tung funksjon er en separat chunk som bare hentes når den trengs:

```js
// Route-basert splitting: dashboard-koden lastes ikke ned før du besøker den
const Dashboard = lazy(() => import("./routes/Dashboard")); // sin egen chunk

// Komponent-basert splitting: tung editor lastet ved interaksjon
button.onclick = async () => {
  const { openEditor } = await import("./editor"); // hentet ved klikk
  openEditor();
};
```

Den dynamiske `import()` er signalet — bundleren sender ut en separat fil ved den grensen.

## Tree shaking

Bundleren analyserer statisk ES-modul-`import`/`export` og fjerner eksporter ingenting refererer til. Det fungerer bare med **ESM** (statisk, analyserbar) — ikke CommonJS `require`:

```js
import { debounce } from "utils"; // bare debounce beholdes; throttle osv. ristes ut
```

Det er avhengig av `"sideEffects": false` i `package.json` og per-funksjon-importer; barrel-filer eller side-effektfulle moduler kan motvirke det.

## Avveininger

- Oversplitting → mange små forespørsler og waterfalls; grupper relatert kode.
- Tree shaking er skjørt — en feilmerket side-effekt beholder død kode.

## Hvorfor det er viktig

Dette er de to spakene bak "send mindre JS." Intervjuere vil at du skal vite at code splitting avgjør *hva som lastes når*, tree shaking avgjør *hva som i det hele tatt er i det*, og at tree shaking avhenger av statisk ESM — en detalj som skiller folk som faktisk har tunet en bundle fra dem som bare har lest om det.

Code splitting

Tree shaking

Avveininger

Hvorfor det er viktig

Relaterte spørsmål