Cache-Control er en af de mest undervurderede performance-forbedringer, fordi den sjældent kræver store kodeændringer, men kan give tydelig effekt på både TTFB og oplevet hastighed.
Målet er enkelt: download færre ting, sjældnere, og lad browser/CDN genbruge det du allerede har sendt. God caching understøtter både TTFB og gentagne besøg - og spiller sammen med CDN og ETag, når du revaliderer i stedet for at hente hele filer igen.
Hvem er artiklen til? Folk der vil forstå hvad Cache-Control betyder i praksis på HTML vs. statiske filer, og hvordan du undgår de klassiske fejl (for kort cache på assets, for lang cache på HTML uden purge, eller cookies der ødelægger edge-cache).
Den simple tommelfingerregel
- HTML: kortere cache (med revalidation), hvis indhold ændrer sig ofte
- Assets (CSS/JS/billeder): lang cache hvis filnavne versioneres
Hvorfor det virker
Mindre download og hurtigere gentagne sidevisninger - og ofte lavere TTFB via edge cache.
Men for at Cache-Control virkelig hjælper, skal du skelne mellem:
- HTML (dokumentet): ændrer sig oftere, og kan være personaliseret
- Assets: kan ofte caches meget længe, hvis filnavne versioneres
Hvad Cache-Control egentlig styrer
Cache-Control er en HTTP-header, der fortæller caches (browser, CDN, proxies) hvad de må gøre:
- gemme responsen
- hvor længe den må genbruges
- om den skal revalidere (ETag/Last-Modified)
- om en shared cache (CDN) må cache den (
public/privateogs-maxage)
Det er værd at vide, at caching i praksis ofte er “lagdelt”:
- browser cache
- CDN/edge cache
- origin/server
Hvis du får cache rigtigt på de to første lag, rammer du færre requests på origin, og din TTFB bliver mere stabil.
max-age vs. s-maxage (browser vs. delt cache)
max-age: hvor længe browseren må bruge en kopi uden at spørge serveren igen (efter første svar).s-maxage: “shared max-age” - typisk til CDN/proxy. Du kan derfor lade browseren revalidere ofte (max-age=0) mens edge stadig må holde en kortvarig kopi (s-maxage=…), så førstegangsbesøg tæt på edge får lavere TTFB.
Det er præcis mønsteret i HTML-eksemplet i afsnittet HTML: konservativ caching længere nede: browseren holder sig frisk, CDN’en reducerer load på origin.
stale-while-revalidate og venner
Nogle setups bruger stale-while-revalidate (se ordbog: stale-while-revalidate): brugeren får en hurtig, evt. lidt ældre kopi mens en frisk version hentes i baggrunden. Det er ikke altid aktiveret som standard - det afhænger af CDN og origin - men det er værd at kende som begreb når du læser response-headers.
Vary og hvorfor den kan ødelægge cache
Headeren Vary fortæller caches at de skal gemme flere varianter af samme URL (fx én per Accept-Language eller Cookie). Et højt Vary kan fragmentere cachen, så færre requests rammer samme nøgle. Hvis du ser mystiske cache misses, er Vary et af de første steder at kigge - sammen med unødige cookies på offentlige GET-requests.
HTML: konservativ caching der stadig giver effekt
HTML er tricky, fordi det ofte ændrer sig (nyeste indlæg, tags, menu) og nogle sites bruger cookies, A/B tests eller personalisering.
En god basis-strategi på et videnssite er:
- HTML:
max-age=0(browser skal revalidere) - CDN:
s-maxagepå fx 10–60 minutter, hvis det er sikkert
Det giver:
- edge hits for mange brugere (lavere TTFB)
- mulighed for at opdatere indhold uden at brugere sidder fast på “gammel” HTML for længe
Hvis du har en purge-mekanisme, kan du ofte cache længere i CDN.
Assets: lang caching, hvis filnavne versioneres
Her ligger det største “gratis” performance-løft.
Når dine assets har versionerede filnavne (fx bundler med hash), kan du sætte:
Cache-Control: public, max-age=31536000, immutable
Fordelen er, at brugeren kun downloader CSS/JS igen, når du faktisk har ændret dem (nyt filnavn).
Hvis dine assets ikke er versionerede, skal du være mere forsigtig, ellers kan du få “mystiske” bugs, hvor browseren holder fast i gammel CSS/JS.
Typiske fejl (som gør caching ubrugelig)
1) Cache-busting cookies på alle sider
Hvis dit site sætter cookies på alle requests, kan nogle CDNs vælge ikke at cache HTML. Det kan gøre TTFB højere end nødvendigt.
2) HTML caches for længe uden purge
Hvis HTML ligger i edge cache i dagevis, kan du få forældet indhold. Det kan være ok for statiske sider, men sjældent for lister (blog-index, emnesider).
3) Assets caches kort, selvom de er versionerede
Det er spild. Hvis filnavn er versioneret, bør cache være lang.
4) Ingen revalidation
For HTML kan revalidation (ETag/Last-Modified) give en god balance: hurtige 304-responses, men stadig “friskhed”.
Gode og dårlige eksempler (hurtigt overblik)
| Situation | Typisk fornuftig header | Typisk fejl |
|---|---|---|
Versioneret CSS/JS (app.a1b2.js) | public, max-age=31536000, immutable | Kort max-age selv med hash i filnavn |
| Dynamisk HTML (nyhedsside) | max-age=0 + kort s-maxage på CDN eller purge ved udgivelse | no-store overalt → intet edge-løft |
| API/json | ofte no-cache / kort TTL | At cache persondata aggressivt ved en fejl |
CDN, edge og klassiske CMS-/shop-scenarier
- CDN/edge:
s-maxage, purge og stale-regler skal matche jeres udgivelsesflow - ellers får I enten forældet indhold eller ingen cache-hit. - Cookies på HTML: session, consent eller kurv kan gøre at delt cache ikke må gemme siden - TTFB stiger for alle. Overvej at holde checkout og personlige sider adskilt fra marketing-URL’er.
- WordPress: page cache kan sænke TTFB markant, men tjek at admin-bar, A/B-tests og «logged in» ikke utilsigtet deaktiverer cache for gæster.
En praktisk opsætning (start her)
Hvis du vil starte enkelt:
- HTML:
Cache-Control: public, max-age=0, s-maxage=600 - Versionerede assets:
Cache-Control: public, max-age=31536000, immutable
Og så tester du:
- kold cache vs varm cache
- forskellige geografier (edge vs origin)
Sådan tester du om caching virker
1) DevTools → Network
Kig efter:
from disk cache/from memory cache- response headers (
cache-control,age,etag,last-modified)
2) WebPageTest
Kør:
- first view
- repeat view
Hvis repeat view ikke er markant hurtigere, er caching typisk ikke sat effektivt op.
Eksempler på fornuftige Cache-Control policies
Nedenstående er eksempler, ikke en universel sandhed. Men de er gode “startpunkter” for mange videnssites.
Versionerede assets (CSS/JS med hash i filnavn)
Når filnavnet ændrer sig ved deploy, kan du cache meget længe:
Cache-Control: public, max-age=31536000, immutable
Det betyder: browseren må genbruge filen i op til et år, og fordi filnavnet ændrer sig ved ny deploy, får brugeren automatisk den nye fil, når det er nødvendigt.
Billeder (statisk indhold)
Hvis dine billeder er statiske eller versionerede, kan de også caches længe. Hvis de kan ændre sig uden filnavnsskift, bør du være mere konservativ.
HTML (konservativ, men effektiv)
En simpel CDN-strategi:
Cache-Control: public, max-age=0, s-maxage=600
Browseren revaliderer, men CDN’et kan servere fra cache i 10 minutter. Det kan reducere TTFB markant, uden at du risikerer at sidde fast med forældet content i lang tid.
ETag og Last-Modified: hvorfor revalidation er nyttigt
For HTML er revalidation ofte den bedste balance:
- Browseren spørger “har du noget nyere?”
- Server/CDN svarer ofte med 304 Not Modified (billigt)
Det kan gøre gentagne besøg hurtige, selv hvis du ikke cacher HTML aggressivt.
Sådan undgår du klassiske cache-fejl
1) “Assets opdaterer ikke” efter deploy
Symptom:
- brugere ser gammel CSS/JS
- layout virker forkert
Årsag:
- assets caches længe, men filnavne er ikke versionerede
Løsning:
- versionér assets (hash)
- eller sænk cache-tiden (mindre ideelt)
2) CDN cacher ikke HTML, selvom du tror det
Årsager kan være:
- cookies på alle requests
privatecache directivesVaryheaders der splitter cachen unødigt
Løsning:
- gør offentlige sider cachebare
- undgå unødvendige cookies på content-sider
3) Du cacher for længe uden purge
Hvis HTML caches i timer/dage, skal du kunne purge, ellers lever du med forældet indhold.
En enkel checkliste til produktion
- Versionerede assets har lang cache + immutable
- HTML har en bevidst strategi (revalidation og evt. edge cache)
- Cookies skaber ikke cache misses på offentlige sider
- Du kan purge HTML cache ved ændringer (hvis du cacher aggressivt)
- Du har testet first view vs repeat view
Relateret på sitet
- Guide: Forbedr TTFB med cache
- Ordbog: Cache-Control
- Blog: Sådan læser du en waterfall (se om gentagne besøg og cache)
Relaterede blogindlæg
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
2026-03-30Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
2025-11-14Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
2026-04-02En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
2026-03-30Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
Sådan læser du en waterfall og finder flaskehalse i load
2026-02-10Lær at læse en waterfall korrekt og find problemer med TTFB, LCP, render blocking og tredjepart, så du kan prioritere den rigtige optimering.
Hvordan du spotter render delay (uden at stirre på score)
2026-04-01Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.
FAQ
Er caching “kun” for gentagne besøg?
Nej. Edge caching (CDN) kan hjælpe første besøg, fordi brugeren rammer et edge node tæt på, i stedet for din origin.
Kan caching gøre SEO dårligere?
Ikke i sig selv. Risikoen opstår hvis du serverer forældet HTML i lang tid uden purge/revalidation. Brug korte TTL’er på HTML eller en purge-strategi.
Hvornår giver `no-store` mening?
`no-store` er relevant for følsomt eller personligt indhold (fx kontosider). På offentlige content-sider fjerner det ofte mulighed for edge-løft og gør performance dårligere end nødvendigt.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
