Hvordan fungerer HTTP-caching med immutable assets og en CDN?

Question

IT Interview Practice · Accepted Answer

HTTP-caching lar nettlesere og CDN-er gjenbruke et svar i stedet for å hente det på nytt, styrt av **`Cache-Control`**-headeren. Det vinnende mønsteret for web-apper: **hash asset-filnavnene dine og cache dem for alltid; hold HTML ucachebar.**

## Totrinnsstrategien

```http
# Hashet, versjonerte assets — innholdet endres aldri for en gitt URL
Cache-Control: public, max-age=31536000, immutable
# f.eks.  /static/app.9f2c1a.js   (hashen endres når innholdet endres)

# HTML — må alltid være ferskt så det kan peke på nye asset-hasher
Cache-Control: no-cache
```

- **`immutable`** ber nettleseren aldri revalidere — ingen betinget forespørsel i det hele tatt, selv ved reload. Trygt fordi filnavn-hashen *er* versjonen; nytt innhold = ny URL.
- **`no-cache`** på HTML er misvisende navngitt: det betyr "lagre det, men revalider før bruk" (en 304 hvis uendret), så brukere får alltid HTML som refererer de nåværende asset-hashene.

## Revalidering og CDN-en

- **`ETag`** / `Last-Modified` muliggjør billige `304 Not Modified`-svar når `max-age` utløper.
- En **CDN** cacher på edge-noder nær brukere. Bruk `s-maxage` for den delte CDN-cachen og `stale-while-revalidate` for å servere utdatert innhold umiddelbart mens det oppdateres i bakgrunnen:

```http
Cache-Control: public, s-maxage=600, stale-while-revalidate=86400
```

## Fallgruver

- Å cache HTML med lang `max-age` → brukere sitter fast på gamle versjoner uten mulighet til å bust-e den.
- `immutable` på ikke-hashede URL-er → du kan ikke sende ut en fiks.

## Hvorfor det er viktig

Caching er den billigste ytelsesgevinsten — den gjør gjentatte besøk til null nettverkskostnad og avlaster origin. Mønsteret med hashet-immutable-asset + revalidert-HTML er industristandarden; å forklare *hvorfor* `no-cache` ≠ "ikke cache" signaliserer ekte dybde.

Totrinnsstrategien

Revalidering og CDN-en

Fallgruver

Hvorfor det er viktig

Relaterte spørsmål