Vary-header og caching: undgå forkert indhold og lav cache-hit-rate

Du kan have perfekt billeder, perfekt JavaScript og “et CDN” – og stadig have en side der føles langsom eller viser forkert indhold, hvis cachen ikke ved hvornår to requests til samme URL faktisk er forskellige.

Det er præcis det Vary handler om.

Kort svar: Vary er en response header der fortæller caches hvilke request-headers der påvirker svaret. Hvis Vary er forkert, får du typisk én af to problemer:

Forkert indhold (fx engelsk til danske brugere, eller forkert komprimering)
Lav cache-hit-rate (cachen bliver splittet i for mange varianter)

Artiklen her er til dig der vil kunne debugge det i praksis – uden at gætte.

Hvad Vary er (forklaret uden RFC)

En cache bruger typisk URL’en som nøgle: /guide/ → “her er HTML’en”.

Men hvis serveren genererer forskellige svar for samme URL afhængigt af requesten, skal cachen vide det. Eksempler:

Browseren beder om Brotli (Accept-Encoding: br) vs gzip (Accept-Encoding: gzip)
Brugeren beder om dansk (Accept-Language: da) vs engelsk (Accept-Language: en)
En variant-test styres af cookie eller header

Vary fortæller: “gem separate kopier baseret på disse request-headers”.

De vigtigste Vary-varianter (og hvornår de giver mening)

`Vary: Accept-Encoding` (Brotli/gzip)

Hvis du leverer både Brotli og gzip, er det normalt at svaret varierer efter Accept-Encoding.

Typisk fejl: en cache gemmer én variant og serverer den til alle → nogle klienter får en encoding de ikke forventer, eller du mister komprimeringsgevinst.

`Vary: Accept-Language` (sprog)

Hvis samme URL leverer forskelligt sprog baseret på Accept-Language, skal Vary ofte med.

Men vær bevidst: det kan skabe mange varianter. Hvis du reelt har separate URL’er pr. sprog, er strategien en anden (og bør kombineres med hreflang/canonical-politik).

`Vary: User-Agent` (device-different indhold)

Det er den klassiske cache-fragmenteringsbombe.

Hvis du sætter Vary: User-Agent, kan din edge-cache ende med at gemme tonsvis af næsten-identiske varianter – og din hit-rate falder, selvom du har mange besøgende.

I 2026 er det sjældent nødvendigt på content-sites med responsivt design. Hvis du har ægte device-different HTML, så dokumentér hvorfor, og mål cache-hit før/efter.

`Vary: Cookie` (personalisering)

Hvis HTML reelt ændrer sig pr. bruger, kan Vary: Cookie være korrekt – men på offentlige pages er det ofte et symptom på et andet problem: at du sender cookies overalt (og dermed gør caching næsten umulig).

Hvis du har login, AB-tests eller consent, så overvej om de kan begrænses til de steder hvor de faktisk er nødvendige.

Den store fodfejl: `Vary: *`

Vary: * betyder i praksis: “der er andre faktorer end headers der påvirker svaret”. Det gør caching besværligt og er ofte et tegn på en misforståelse eller en forkert default.

Hvis du ser den på HTML, så behandl det som et alarmflag: cachen kan ikke trygt genbruge svaret.

Sådan tester du Vary i praksis (konkret)

1) Kig på headers i DevTools

I Chrome DevTools → Network → klik på dokumentet (HTML) eller en CSS/JS-fil og kig efter:

Vary
Cache-Control
Content-Encoding
Age (hvis en shared cache bruges)

Hvis Content-Encoding er br, men du ikke ser Vary: Accept-Encoding, så er det værd at undersøge hvordan jeres CDN håndterer det.

2) Brug curl til at tvinge varianter

Her er tre tests du kan køre mod en offentlig URL:

curl -I https://hurtigere-hjemmeside.dk/ | sed -n '1,20p'

Tving gzip:

curl -I -H "Accept-Encoding: gzip" https://hurtigere-hjemmeside.dk/ | sed -n '1,30p'

Tving Brotli:

curl -I -H "Accept-Encoding: br" https://hurtigere-hjemmeside.dk/ | sed -n '1,30p'

Du leder efter om Content-Encoding følger med – og om Vary fortæller cachen at de er forskellige.

3) Test sprog-variation (hvis relevant)

curl -I -H "Accept-Language: da" https://example.com/ | sed -n '1,30p'
curl -I -H "Accept-Language: en" https://example.com/ | sed -n '1,30p'

Hvis svaret reelt er forskelligt (sprog), bør Vary typisk afspejle det – ellers vil en cache kunne “låse” et sprog til andre brugere.

Hvornår Vary bliver et performance-problem

Vary er ikke “dårligt”. Det bliver et problem når:

du varierer på for mange headers (cache fragmentering)
du varierer på headers der reelt ikke ændrer indhold (støj)
du varierer på cookies på sider der burde være offentlige

Konsekvensen er ofte lavere hit-rate på edge, og dermed højere TTFB på førstebesøg og mere ustabil performance.

Hvis du vil forstå helheden af caching, så læs Cache-Control basics først – Vary er “cache key”-delen af samme kæde.

Praktisk tommelfingerregel (til content-sites)

Offentlige sider: hold cache-nøgler simple. Vary: Accept-Encoding er ofte nok.
Undgå Vary: User-Agent medmindre du har en meget konkret grund og dokumentation.
Undgå Vary: Cookie på offentlige content-sider. Hvis cookies er nødvendige, så scope dem ned.

Næste skridt

Hvis du har mistanke om cache-problemer, så gør dette i rækkefølge:

Find én vigtig URL og mål den i waterfall
Læs Vary + Cache-Control + Content-Encoding på HTML
Test varianter med curl (encoding / language)
Justér én ting og mål igen

Relateret på sitet:

Cache-Control basics (overblik og strategi)
Ordbog: Vary-header
Ordbog: Edge caching (hvor hit-rate bliver til TTFB)
Ordbog: Brotli og gzip

Relaterede blogindlæg

Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)

2026-04-02

En 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.

Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis

2026-03-30

Reverse 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.

Sådan prioriterer du hastighedsoptimering uden at spilde tid

2026-03-27

Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.

Hvad er Core Web Vitals? LCP, INP og CLS forklaret enkelt

2026-03-20

Få en praktisk forklaring på LCP, INP og CLS. Lær hvad Core Web Vitals måler, hvorfor de betyder noget, og hvordan du kommer i gang.

Lighthouse vs CrUX: hvorfor tallene ikke matcher og hvad du gør

2026-02-28

Forstå forskellen på Lighthouse og CrUX. Lær hvorfor labdata og feltdata kan vise noget forskelligt, og hvordan du bruger dem rigtigt.

Cache-Control forklaret: sådan bruger du caching til lavere TTFB

2026-01-25

Lær hvordan Cache-Control påvirker HTML, CSS, JavaScript og billeder, og få en praktisk gennemgang af caching, TTFB og klassiske fejl.

FAQ

Skal jeg altid bruge Vary: Accept-Encoding?

Ofte ja, når du leverer både Brotli og gzip. I mange setups håndterer CDN/server det automatisk. Det vigtige er at du ikke ender med at cache én encoding-variant og servere den til alle.

Er Vary: User-Agent en god idé?

Sjældent som standard. Det kan fragmentere cachen voldsomt (mange varianter), og moderne responsivt design gør det ofte unødvendigt. Hvis du har ægte device-different HTML, bør du være meget bevidst om cache-nøgler og alternativer.

Påvirker Vary SEO?

Indirekte. Hvis forkert Vary giver forkert sprog eller forældet indhold til brugere/crawlere, eller hvis det ødelægger caching og gør TTFB dårligere, påvirker det oplevelsen og signalerne omkring siden.

Eksterne kilder

MDN og RFC til Vary-semantik + caching-modellen, og referencer til komprimering (Server-Timing bruges kun som eksempel andre steder).

Næste skridt i samme emne

Fortsæt fra forklaring til handling med guides, emner og ordbog.

Se relaterede guides Gå til emneoversigt Slå begreb op i ordbog Læs om metode og kilder

Vary-header og caching