Kort fortalt: Ud over max-age kan Cache-Control indeholde stale-while-revalidate=<sekunder>. I det tidsvindue må cachen returnere et lidt forældet svar straks og opdatere sig asynkront - i stedet for at blokere brugeren på synkron revalidation.
Hvad løser det?
Brugeren undgår ofte “hårde” ventetider når:
max-agelige er udløbet, men indholdet stadig er acceptabelt kortvarigt,- origin er langsom et øjeblik, men cache kan servere noget,
- I vil have høj hit-rate på CDN uden at vise meget gamle sider hele tiden.
Simpelt eksempel (idé)
Cache-Control: public, max-age=60, stale-while-revalidate=300Fortolkning afhænger af klient og mellemlag - men idéen er: efter max-age kan cachen i op til 300 sekunder stadig udlevere et stale svar mens den henter frisk i baggrunden, hvis implementeringen understøtter det.
Browser vs CDN
- Browser: Understøttelse og detaljer varierer; test med jeres målgruppe.
- CDN (edge caching): Ofte eksplicit feature (“serve stale”, “stale while revalidate”). Adfærd er ikke altid identisk med browserens - læs dokumentationen.
Pas på med personlige og pris-følsomme sider
På logged-in flows, kurve og priser vil selv kort “stale” HTML ofte være uacceptabel. Her bruges SWR typisk på assets, offentlige JSON-feeds eller andet hvor et kort tidsvindue er forretningsmæssigt ok - ikke på bruger-specifikke dashboards uden særskilt design.
Forhold til ETag
ETag og If-None-Match styrer hvordan revalidation udføres når klienten checker serveren. stale-while-revalidate styrer om I må vise gammelt indhold mens den check sker - komplementære mekanismer under Cache-Control.
Relaterede begreber
FAQ
Er HTTP stale-while-revalidate det samme som SWR i React?
Navnet deler idéen - vis noget nu, opdater i baggrunden - men HTTP-direktivet styrer browser/CDN-cache semantik, ikke React Data Fetching-biblioteket.
Gør SWR siden langsommere?
Pointen er lavere observeret latency for gentagne besøg: brugeren får et svar fra cache mens revalidation kører. Worst case er kort forældet indhold inden for de grænser I sætter.
Kan jeg bruge SWR på logged-in HTML?
Som udgangspunkt nej til offentlig HTML med personlige priser eller kontodata - en kort stale-periode kan være uacceptabel. Brug ofte SWR på versionerede assets, API-responses med lav risiko, eller offentlige dokumenter.
Understøtter alle browsere det ens?
Adfærd varierer mellem browser-lag og fetch-typer. På CDN er det ofte en eksplicit feature - læs udbyderens dokumentation og test jeres konkrete setup.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Forbedr TTFB med caching, edge cache og hurtigere serverrespons
Lær hvordan du reducerer TTFB med page cache, edge cache, korrekt cache strategi og bedre serverrespons på HTML.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
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
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.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
Vary 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.
