Tillbaka till Sällskapet
Tips och tricks· 5 oktober 2026 ·7 min läsning

Cache-Control-huvuden: den enda guiden du faktiskt behöver

Cache-Control bestämmer vad som cachas, av vem och hur länge. Det ser kryptiskt ut och är oftast sex ord som du faktiskt använder. Här är de, plus en distinktion som alla gillar.

Mads Edelskjold
Mads Edelskjold
Grundare, NordicCDN tidigare CTO för datacenter
Cache-Control-huvuden: den enda guiden du faktiskt behöver
Den korta versionen

Markeringen Cache-Control headern svarar på tre frågor: må detta cachas, av vem och hur länge. Sex direktiv täcker nästan alla fall public, private, max-age, s-maxage, no-store och stale-while-revalidate. Cache fingeravtryck tillgångar för ett år, ge HTML en kort friskhet fönster med inaktuella-medan-utvärdering, och hålla genuint personliga svar ur delade cacher.

Cache-Control har ett rykte om sig att vara fiddly, främst eftersom specifikationen innehåller många direktiv som ingen använder. Strippa det tillbaka till de som tjänar sin plats och det är enkelt. Komplexiteten som återstår är dock verklig, och den lever i en skillnad som fångar nästan alla - så vi kommer att komma till det tidigt.

Direktiven är värda att känna till

DirektivVad står det?som lyder den
publicVilken cache som helst kan lagra dettaWebbläsare och CDN
privateEndast användarens egen webbläsare får lagra denEndast webbläsare
max-age=NFärsk i n sekunderAlla
s-maxage=NFärsk i N sekunder i delade cacheminnen, överdriven maxålderCDN och proxyservrar
no-storeFörvara inte detta någonstans, allsAlla
no-cacheFörvara den, men ge nytt liv före varje användningAlla
must-revalidateEn gång gammal, aldrig tjäna utan att kontrolleraAlla
immutableDetta kommer aldrig att ändras. Uppdatera inte vid omladdningWebbläsare
stale-while-revalidate=NServera i upp till N sekunder medan du uppfriskar bakom kulissernaFrämst CDN
stale-if-error=NServera gammalt i upp till N sekunder om ursprunget är felFrämst CDN

no-cache betyder inte att cache inte

Detta är det mest vilseledande direktivet i HTTP och det är värt att vara tydlig med. no-cache betyder "du får behålla en kopia, men du måste kontrollera ursprunget innan du använder det". Svaret lagras fortfarande, det kan bara inte visas utan en begäran om förlängning.

no-store Det är det som betyder inte cache. Om du vill ha ett svar som aldrig skrivs till disk någonstans, är det det direktiv du vill ha.

Den praktiska skillnaden är viktig: no-cache med en ETAg är ganska effektiv, eftersom förlängningen vanligtvis returnerar en 304 utan kropp. no-store Det betyder att hela svaret överförs varje gång.

Den enda skillnaden som lockar alla: maxålder kontra s-maxage

Webbläsare och CDN:er är båda cachar, men du vill sällan att de ska innehålla innehåll under samma tid.

Tänk på en nyhetsartikel. Du vill att ditt CDN ska cacha det i en timme så att ditt ursprung är skyddat. Du vill inte att en besökares webbläsare håller den i en timme, för om du korrigerar ett fel och rensar CDN, har den besökaren fortfarande en gammal kopia och inget sätt för dig att nå den.

s-maxage löser detta genom att endast använda delade cacheminnen:

Cache-Control: public, max-age=60, s-maxage=3600

Webbläsaren cachar i en minut. CDN:n cachar i en timme. Du kan rensa CDN och vara säker på att alla får rättelsen inom sextio sekunder, medan ditt ursprung fortfarande bara tjänar sidan en gång i timmen.

Detta är den form du vill ha för nästan alla HTML: kort i webbläsaren, lång vid kanten, rensa vid förändring. Anledningen till att det spelar roll är att du kan ogiltigförklara ett CDN och du kan inte ogiltigförklara en webbläsare.

föråldrad-under-utvärdering, den underskattade en

Normalt när ett cachelagrat svar löper ut väntar nästa besökare medan cachen hämtar en ny kopia. Den besökaren betalar hela ursprungsfördröjningen, vilket är ett lite orättvist sätt att fördela kostnaden för färskhet.

stale-while-revalidate ändra avtalet. Inom det angivna fönstret efter utgången tjänar cachen den gamla kopian omedelbart och fräschar upp i bakgrunden. Ingen väntar. Nästa besökare får den nya versionen.

Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=86400

Dess syskon stale-if-error Det är värt att lägga till varhelst det är acceptabelt: om ursprunget returnerar en 5xx eller gånger ut, serva den gamla kopian snarare än en felsida. Det är den billigaste motståndskraften du någonsin kommer att konfigurera - din webbplats stannar upp genom ett ursprungavbrott eftersom kanten fortsatte att tjäna vad den hade.

Recept

  • Fingeravtryck statiska tillgångar app.a1b2c3.js, styles.d4e5f6.css

    public, max-age=31536000, immutable. Ett år och aldrig förnyad. Säker eftersom filnamnet ändras när innehållet gör det. immutable Dessutom stoppas webbläsare från att ladda om manuellt.

  • Statiska filer utan fingeravtryck /logo.png

    public, max-age=86400. En dag, eftersom du inte har något annat sätt än att vänta eller byta namn.

  • HTML som du kan rensa

    public, max-age=60, s-maxage=86400, stale-while-revalidate=604800, stale-if-error=604800. Lång vid kanten, kort i webbläsaren, rensa på publicera.

  • HTML som du inte kan rensa

    public, max-age=300, stale-while-revalidate=3600. Shorter, eftersom utgång är din enda ogiltighetsmekanism.

  • API-svar, offentliga data

    public, max-age=0, s-maxage=60, stale-while-revalidate=300. Aldrig betrodd i webbläsaren, kort cachad vid kanten - vilket absorberar majoriteten av dubbla förfrågningar.

  • Personliga sidor – kundvagn, konto, instrumentpanel

    private, no-store. inte no-cache. Inget personligt ska under några omständigheter finnas i ett delat cacheminne.

  • En filt no-store tillämpas överallt "för att vara säker" är den enskilt vanligaste orsaken till en dålig cache träff ratio. Det används också ofta som ramstandard utan att någon väljer det. Kontrollera vad din ansökan faktiskt skickar innan du antar att din konfiguration är vad som gäller.

    ETaggar och förlängning

    Cache-Control bestämmer hur länge något är färskt. När den slutar vara färsk bestämmer validatorer om den behöver laddas ned igen.

    En ETag Det är ett fingeravtryck på svaret. Vid förlängning skickar kunden If-None-Match med det värdet, och om inget ändrats svarar servern 304 Not Modified Utan någon kropp. Last-Modified fungerar på samma sätt med en tidsstämpel och If-Modified-SinceMed en sekunds precision.

    En 304 kostar fortfarande en rundtur, varför det inte är en ersättning för en anständig resa max-age Det sparar bandbredd, inte latens. Skicka validerare ändå, eftersom de gör det dyra fallet mycket billigare.

    Kolla vad du faktiskt skickar

    curl -sI https://example.com/ | grep -iE 'cache-control|etag|age|vary'

    Kör den mot din startsida, en statisk tillgång och en API-slutpunkt. Markeringen Age header berättar hur länge svaret har suttit i en cache, vilket är ett snabbt sätt att bekräfta att CDN faktiskt cachar snarare än bara vidarebefordrar.

    Vanliga frågor

    Vad gör Cache-Control?

    Cache-Control är ett HTTP-svarshuvud som instruerar webbläsare och delade cacheminnen, till exempel CDN, om ett svar får lagras, vem får lagra det och hur länge det förblir färskt. Det är den primära mekanismen för att kontrollera cachelagringsbeteendet, och den har företräde framför det äldre sidhuvudet Utgår.

    Vad är skillnaden mellan no-cache och no-store?

    no-cache tillåter att ett svar lagras men kräver att cachen förnyas med ursprunget innan det serveras, så ett oförändrat svar kan bekräftas med ett lätt 304 svar. no-store förbjuder lagring av svaret var som helst, vilket innebär att hela kroppen överförs på varje begäran. Endast en butik som inte finns i butiken förhindrar faktiskt cachelagring.

    Vad är skillnaden mellan maxålder och s-maxage?

    max-age gäller för alla cachar, inklusive besökarens webbläsare. s-maxage gäller endast för delade cacher som CDN och proxyservrar, och åsidosätter max-age för dem. Det vanliga mönstret är en kort maxålder med mycket längre s-maxage, så CDN skyddar ditt ursprung medan webbläsare bara håller innehåll kort - viktigt eftersom du kan rensa en CDN men inte kan rensa en webbläsare.

    Vad är en gammal-while-revalidate?

    inaktuell-under-revalidate definierar ett fönster efter ett svar löper ut under vilket en cache kan tjäna inaktuell kopia omedelbart medan hämta en ny i bakgrunden. Det tar bort latensstraffet som annars faller på den besökare som kommer först efter utgången, så ingen enskild användare väntar på ursprunget.

    Hur länge ska jag cachelagra statiska tillgångar?

    Ett år max-age=31536000 med det oföränderliga direktivet, förutsatt att filnamnen innehåller ett innehållshash som app.a1b2c3.js. Eftersom en ändring av filen ger ett nytt filnamn finns det ingen risk för att filen är föråldrad. Filer utan fingeravtryck i namnet bör använda något kortare, runt en dag, eftersom namnbyte är det enda sättet att ogiltigförklara dem.

    Varför cachas inte mitt innehåll av CDN?

    Vanligtvis eftersom svaret inte innehåller någon butik, privat eller maxålder = 0, ofta lagt till av en ramstandard snarare än avsiktligt. Andra vanliga orsaker är en Set-Cookie-header på svar som ska delas, eller en Vary-header på något med obegränsade värden som User-Agent. Kör curl – jag mot webbadressen och läs de rubriker som ditt ursprung faktiskt skickar.

    Ställ in dessa en gång per innehållstyp och du kommer sällan att tänka på rubriken igen, vilket är exakt hur en bra cachningskonfiguration ska kännas.

    #caching #cache-kontroll #http-huvuden #prestation
    Omsätt det i praktiken

    Se hur NordicCDN gör detta för din webbplats:

    Mads Edelskjold
    Skrivet av
    Mads Edelskjold Grundare, NordicCDN ex-datacenter CTO

    Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.

    Gör din webbplats laddad direkt

    Starta gratis på två minuter – inget kort krävs.

    Starta gratis