Cache-Control

Kort fortalt: Cache-Control styrer hvor længe browseren (og evt. et CDN) må genbruge en respons, før den skal hente den igen.

Hvad bruges det til?

• Fortælle hvor længe en ressource må caches
• Styring af revalidation (ETag/Last-Modified i kombination)

Typiske forbedringer

• Lange cache-tider på versionerede assets (CSS/JS med hash)
• Kortere cache på HTML hvis indhold ændrer sig ofte

I praksis er Cache-Control en af de vigtigste “grundindstillinger” for hastighed, fordi caching ændrer hvor ofte brugeren skal:

• downloade HTML igen
• downloade CSS/JS igen
• downloade billeder igen

Det påvirker både første besøg (via CDN/edge caching) og gentagne besøg (via browser cache).

Hvilken indflydelse har Cache-Control?

Cache-Control påvirker typisk:

• TTFB: hvis HTML kan leveres fra edge cache, falder TTFB ofte markant
• LCP: hvis kritiske assets (CSS/JS/hero-billeder) caches godt, starter rendering hurtigere
• Stabilitet: færre netværksrequests giver færre variationer mellem pageviews

På content-sites (blog, guides, ordbog) er caching ofte noget af det mest effektive, fordi mange sider er offentlige og kan caches uden personalisering.

Hvornår blev Cache-Control indført?

Cache-Control er en del af HTTP caching-modellen (HTTP/1.1) og har i mange år været den primære måde at styre caching på. Over tid er den blevet endnu vigtigere fordi:

• CDNs og edge caching er blevet standard
• sites loader flere assets (CSS/JS/fonts/billeder)
• performance-krav (Core Web Vitals) gør gentagne loads og stabil levering vigtigere

Hvad betyder de vigtigste directives?

Her er de mest brugte “byggesten”:

• max-age=<sekunder>: hvor længe en respons må caches (typisk i browser)
• s-maxage=<sekunder>: hvor længe en respons må caches i shared caches (CDN/proxy)
• public: respons må caches af shared caches
• private: respons må kun caches i browser, ikke i shared caches
• no-cache: må caches, men skal revalidere før genbrug
• no-store: må ikke caches
• must-revalidate: cache må ikke servere stale uden revalidation
• stale-while-revalidate: cache må servere “stale” mens den opdaterer i baggrunden (hvis understøttet)

Du behøver ikke bruge alt. Det vigtigste er at have en enkel og korrekt politik for HTML vs assets.

HTML vs assets: den vigtigste skelnen

HTML (sider)

HTML ændrer sig oftere end versionerede assets, og det er her man typisk vil være mere konservativ.

Typiske strategier:

• Offentlige sider: public, max-age=0, s-maxage=... + evt. revalidation
• Hvis du kan purge cache ved ændringer: længere s-maxage på CDN kan være effektivt

Hvis du har personalisering (login, geografi, A/B tests), skal du være meget bevidst om variationer, ellers kan du cache forkert indhold til forkert bruger.

Assets (CSS/JS/billeder/fonts)

Hvis filnavnene er versionerede (fx indeholder et hash), kan du sætte meget lange cache-tider, fordi du “skifter filnavn” når indholdet ændrer sig.

Typisk:

• public, max-age=31536000, immutable

Det er en af de mest sikre og effektive performance-forbedringer.

Typiske fejl (som giver langsomt site)

• HTML bliver ikke cached (høj TTFB på alle requests)
• Assets caches for kort tid (brugeren downloader alt igen)
• Assets caches for længe uden versionering (brugere får gamle filer og “mærkelige bugs”)
• CDN cache virker ikke pga. cookies eller varierede headers

Eksempler på “fornuftige” policies

Versionerede assets

• Cache-Control: public, max-age=31536000, immutable

HTML (konservativ)

• Cache-Control: public, max-age=0, s-maxage=600

HTML (mere aggressiv, hvis du kan purge)

• Cache-Control: public, max-age=0, s-maxage=86400