HTTP cache revalidation

Kort fortalt: Revalidation er når cache (browser eller CDN) ikke bare gætter – men spørger serveren: “er den her ressource stadig den samme?” Hvis den ikke har ændret sig, kan serveren svare 304 Not Modified, og klienten genbruger den cachede kopi.

Det er en af de vigtigste mekanismer til at få hurtige gentagne besøg uden at risikere at vise forældet indhold.

Hvad betyder cache revalidation?

Der er groft sagt tre situationer:

1. Cache miss: intet cachet → hent hele ressourcen (200 + payload).
2. Cache hit (fresh): ressource er stadig frisk ift. max-age → ingen request.
3. Cache hit (stale) + revalidation: ressource er udløbet → send betinget request; få 304 eller 200.

Revalidation er altså “plan B” når du ikke kan (eller vil) sætte meget lang TTL.

De to klassiske mekanismer

ETag + If-None-Match

• Server sender ETag: "abc123"
• Cache gemmer ETag
• Ved revalidation sender klient: If-None-Match: "abc123"
• Server svarer:
  • 304 hvis ETag matcher (ikke ændret)
  • 200 hvis ændret (og sender nyt indhold + ny ETag)

Se også ETag.

Last-Modified + If-Modified-Since

• Server sender Last-Modified: ...
• Ved revalidation sender klient: If-Modified-Since: ...
• Server svarer 304 hvis ikke ændret siden

Denne er ofte “god nok”, men kan være mindre præcis (sekund-opløsning, clock-skævheder).

Hvorfor er det vigtigt for performance?

Hurtigere gentagne besøg

Hvis brugeren besøger siden igen (eller klikker rundt), er revalidation ofte det der afgør om alt føles snappy.

Lavere båndbredde (og bedre mobil-oplevelse)

304 sparer typisk payload – især vigtigt på mobil.

Mindre origin-load

CDN’er kan også revalidate mod origin. God revalidation-strategi kan reducere load og stabilisere TTFB.

Typiske fejl

1) Ingen versionering af statiske assets

Hvis du serverer app.css uden hash/version, tør du sjældent give lang TTL. Så revalidater du hele tiden – og betaler round-trip igen og igen.

Typisk bedre:

• versioner filnavne (fx app.9f3a.css)
• sæt lang TTL via Cache-Control
• og brug revalidation som fallback, ikke som standard

2) Ustabile ETags på flere servere

Hvis ETag beregnes på en måde der ændrer sig pr. server (fx inode, filsystem), kan du få “falske misses” bag en load balancer.

3) Revalidation på HTML uden at forstå cookies

HTML caching handler ofte om cookies og variation. Hvis HTML varierer pr. bruger, kan caching/revalidation blive ubrugelig, og du ender med højere TTFB.

Se Vary og Age header for at forstå cache-status i praksis.

Sådan tjekker du det i praksis

I Waterfall-analyse og DevTools Network kan du se:

• status 304 vs 200
• request headers (If-None-Match, If-Modified-Since)
• response headers (ETag, Last-Modified, Cache-Control)
• om du får cache hit (size/from disk cache/from memory cache)

Relaterede begreber

• Cache-Control – styr friskhed og cachingpolitik
• ETag – den praktiske “version”
• Vary – når responses varierer på headers/cookies
• Reverse proxy – hvor revalidation ofte implementeres i praksis