Hoppa till innehåll 
Jag ska visa dig hur du använder HTTP-headern Cache-kontroll använder på ett målinriktat sätt för att minska laddningstiderna, spara på förfrågningar och effektivt styra webbläsarens cache. Du får tydliga riktlinjer, smarta kombinationer och praktiska inställningar för HTML, CSS, JS, bilder och API:er – utan gissningar, men med konkreta Handgrepp.
Centrala punkter
Följande viktiga aspekter hjälper dig säkert att snabbt och pålitlig Cache-strategi.
- max-ålder som tidsinställare: styr kylningstiden i sekunder
- offentlig/privat: anger vem som får spara i cacheminnet
- ingen cacheminne mot. ingen lagring: ompröva istället för att förbjuda
- ETag och Senast modifierad: Villkorade hämtningar sparar data
- Versionering + oföränderlig: långa cacher utan gamla problem
Grunderna: Vad gör Cache-Control-rubriken?
Huvudet innehåller instruktioner som anger om, hur länge och av vem ett svar ska finnas i Cache får finnas. Jag skiljer här mellan klientcacher i webbläsaren och gemensamma cacher som proxyservrar eller CDN:er, som ofta betjänar flera användare och därmed ger ytterligare Effektivitet medföra. Medan den föråldrade Expires-headern använder ett datum, använder jag med Cache-Control relativa tidsperioder via max-age, vilket är mindre felbenäget. På så sätt bestämmer jag hur länge en resurs förblir „färsk“ och om den måste valideras på nytt innan den används. På så sätt håller jag möjligheten öppen att kontrollera dynamiskt innehåll och att lagra statiska filer lokalt under mycket lång tid.
Cache-Control gäller både i svar och i förfrågningar, vilket är till nytta för mig vid omvalidering, till exempel i kombination med ETag eller Last-Modified för Villkorlig Förfrågningar. Jag ställer till exempel in aggressiva värden för oförändrade tillgångar och försiktiga regler för HTML. Denna uppdelning säkerställer att efterföljande anrop i möjligaste mån hämtas från webbläsarens cache och därmed Serverbelastning minskar. Det är viktigt med ett välplanerat samspel så att jag inte oavsiktligt blockerar resurser eller låter dem löpa ut för tidigt. Den som tar dessa grunder till sig lägger grunden för korta laddningstider och tydliga regler för cache-beteendet.
Viktiga riktlinjer förklarade på ett lättbegripligt sätt
Med max-ålder Jag anger livslängden för en resurs i sekunder, räknat från leveransdatumet. För bilder, CSS, JS och teckensnitt väljer jag ofta 31536000 (ett år), så att återkommande besökare använder nästan allt lokalt. För HTML-sidor ställer jag in en kortare giltighetstid, cirka 300 sekunder, eller kombinerar dem med omvalidering så att ändringar snabbt blir synliga. Lång giltighetstid utan filversionering leder lätt till gamla versioner i cachen, därför varierar jag filnamnen vid varje release. På så sätt kombinerar jag snabb uppdatering med hög Andel träffar i cachen.
Direktiven allmänheten och privat styra vem som får cacha. Jag tillåter ”Public” för innehåll utan personalisering, så att även proxyservrar och CDN:er kan cacha det. Jag tilldelar ”Private” när endast användarens webbläsare ska behålla en kopia, till exempel på kontosidor. På så sätt förhindrar jag att personuppgifter hamnar i gemensamma cacheminnen och där gå fel. Denna åtskillnad sparar besvär och skyddar känslig information.
ingen cacheminne tolkas ofta felaktigt: Det förbjuder inte lagring, men kräver en omvalidering hos servern innan den används igen. Detta passar för innehåll som ändras regelbundet utan att behöva laddas om helt varje gång det hämtas. Med ETag eller Last-Modified lagrar klienten data lokalt och frågar bara om de fortfarande är aktuella. På så sätt undviker jag onödiga byte och upprätthåller ändå Innehåll färskt. För mycket känsliga data är dock ”no-cache” fortfarande för slapp.
ingen lagring är den strängaste åtgärden, eftersom den förbjuder all lagring i webbläsaren och i proxyservrar. Jag använder detta för inloggningssidor, betalningsprocesser eller dokument med konfidentiella uppgifter. På så sätt finns inga kopior i tillfälliga mappar som av misstag skulle kunna hamna i fel händer. När jag använder no-store kombinerar jag ofta detta med max-age=0 för att förhindra all återanvändning att utesluta. Säkerheten går före prestandan här.
måste-omvalidera tvingar fram en förfrågan till servern så snart tidsgränsen har löpt ut. Om servern slutar fungera får cachen inte bara fortsätta att leverera resursen. Denna direktiv är lämplig för områden där konsistens är viktigare än en flexibel strategi vid driftstopp. Jag använder den när föråldrade data skulle kunna leda till felaktiga beslut. Regeln skapar tydliga Bindande karaktär under förloppet.
Utökade riktlinjer för delade cacheminnen och driftsäkerhet
Utöver grundinställningarna använder jag s-maxage, stale-under-validering och stale-om-fel, för att på ett målinriktat sätt styra proxyservrar och CDN:er och säkerställa en smidig upplevelse för användarna även vid störningar. s-maxage ställer in en egen TTL endast för delade cacher (webbläsarna ignorerar den). På så sätt kan jag t.ex. hålla cachen kort i webbläsaren (max-age=600), men cacha den längre i Edge (s-maxage=86400). stale-under-validering gör det möjligt för cacheminnen att fortsätta leverera föråldrat innehåll under en viss tid, samtidigt som uppdateringen redan pågår i bakgrunden. stale-om-fel träder i kraft vid fel (t.ex. 500/timeout) och skyddar användarupplevelsen genom att visa en något äldre version istället för att visa ett tydligt felmeddelande.
Ett praktiskt exempel på offentliga API-svar eller JSON-sitemaps som sällan ändras ser ut så här: Cache-Control: public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600. På så sätt hålls webbläsarna relativt uppdaterade, CDN:erna är effektiva och användarna märker varken korta avbrott eller fördröjda omvalideringar. Jag låter medvetet kritiska eller personaliserade områden vara opåverkade av sådana mjuka riktlinjer.
Samverkan med Expires, ETag och Last-Modified
Jag använder Upphör att gälla högst som en reservlösning, eftersom Cache-Control går att styra mer precist och har företräde om båda är inställda. Med ETag skickar jag ett unikt avtryck av resursen, så att webbläsaren via If-None-Match kan initiera en enkel omvalidering. Last-Modified anger datum och tid för den senaste ändringen och fungerar tillsammans med If-Modified-Since. Båda metoderna sparar bandbredd, eftersom servern endast skickar tillbaka statuskoden 304 om innehållet är oförändrat. Detta samspel håller data nära användaren och minskar Rundresor.
Ska jag ta den? Villkorliga förfrågningar, minskar kostnaderna per sidvisning avsevärt utan att jag blockerar nytt innehåll. Denna teknik kompletterar korta max-age-värden i HTML och säkerställer aktuella visningar. När det gäller tillgångar med versionshantering förlitar jag mig däremot främst på lång giltighetstid och undviker onödiga valideringar. På så sätt avlastar jag Server och påtagligt påskynda uppföljningsbesök. Sammantaget skapas en smidig dataväg med tydliga regler.
ETag/Last-Modified i praktiken: starkt, svagt och skalbart
I distribuerade miljöer ser jag till att ETags konsekvent beräknas över alla instanser. Filbaserade ETag-värden som inkluderar inoder leder till onödiga missar i kluster. I Apache ställer jag därför medvetet in ETag-beräkningen så att:
# Apache: konsekventa ETag-värden för statiska filer
FileETag MTime Size
# Valfritt: ta bort standard-ETag och ställa in egen logik
#Header unset ETag
Med Nginx räcker det ofta med etag på; för statiska filer. För dynamisk Jag genererar ETags själv i svaren – helst som en hash av svarstexten. Om jag behöver en viss tolerans vid mindre ändringar (t.ex. formaterade tidsstämplar) använder jag svaga ETags (W/"..."), som gör att innehåll som är semantiskt identiskt kan identifieras som oförändrat trots skillnader i byte. Som reservalternativ använder jag Last-Modified, till exempel till tidpunkten för uppdateringen av dataposten. Viktigt: ETag och Last-Modified på samma gång Det skadar inte att erbjuda det – klienten väljer själv vad den stöder.
Använd Vary på rätt sätt: Personalisering utan cache-kaos
Varierande bestämmer vilka förfrågningshuvuden som ska ingå i cache-nyckeln. Jag håller medvetet Vary enkelt: Accept-Encoding är standard (Gzip/Brotli), Acceptera språk endast om jag ger språkspecifika svar. Från Vary: User-Agent avråder jag från det, eftersom det får cacheminnet att svälla explosionsartat. Om innehållet är beroende av cookies föredrar jag att privat eller . ingen lagring, istället för att underhålla omfattande Vary-regler. När det gäller tillgångar tar jag bort onödiga cookies i möjligaste mån, så att allmänheten-Caching vid edge-enheten träder i kraft. Om API-autentisering via header används, kan Vary: Auktorisering förhindra att delade cacher blandar ihop svar från olika användare – men ofta är det dock så att privat det bättre och tydligare valet.
Jag kontrollerar i DevTools om Vary-fältet ställs in oavsiktligt (t.ex. av middleware), eftersom ett „brett“ Vary-fält minskar träfffrekvensen avsevärt. Ett fåtal, noggrant utvalda rubriker gör att cachen förblir överskådlig och effektiv.
Strategier efter innehållstyp
Jag gör en tydlig åtskillnad mellan statiskt och dynamiskt innehåll för att kunna dra nytta av fördelarna med båda. Statiska tillgångar får långa livslängder och tydlig identifiering via versionerade filnamn. HTML och personligt innehåll hanterar jag mer försiktigt, så att ändringar snabbt blir tillgängliga och inga data hamnar i fel cacheminnen. API:er differentierar jag efter ändringsfrekvens och informationens känslighet. Denna differentiering medför Hastighet utan att äventyra sekretessen och Korrekthet.
Tabellen nedan sammanfattar praktiska inställningar och visar fördelarna på ett överskådligt sätt.
| Typ av resurs | Exempel på rubrik | Varför | Ledtråd |
|---|---|---|---|
| CSS/JS/Bilder/Teckensnitt | Cache-kontroll: offentlig, max-age=31536000, oföränderlig | Lång livslängd Webbläsarens cache, färre förfrågningar | Versionshantering av filnamn för en överskådlig Rullande Uppdatera |
| HTML är inte anpassad | Cache-Control: no-cache, must-revalidate (eller max-age=300) | Aktualiteten är fortsatt hög, datamängden är fortsatt liten | Med ETag/Last-Modified för enkel revalidering |
| Anpassad HTML | Cache-Control: private, no-cache, must-revalidate | Ingen lagring i gemensamma cacheminnen | Skydda sessionsdata och Läckage Undvik |
| API:er som är statiska / sällan ändras | Cache-Control: public, max-age=3600 | Hög träffsäkerhet hos många Kunder | Var flexibel inför frekventa driftsättningar |
| API:er som är mycket dynamiska/känsliga | Cache-Control: no-store, max-age=0 | Lägg inte undan känsliga uppgifter | Direkt Aktualitet istället för risk |
För bildgallerier, stora JS-paket eller webbtypsnitt lönar sig långa max-age-värden snabbt. Jag är noga med versionssträngar i filnamnen så att användarna aldrig ser föråldrade paket. HTML-koden hålls kort och använder omvalidering så att även små korrigeringar av texter eller priser snabbt publiceras. API:er får sina regler beroende på användningsprofil och behov av ändringar. Denna kombination ger varaktiga resultat flotta Sidvisningar och sparar Bandbredd.
SPA vs. MPA: Kort HTML-kod, stora resurser
När det gäller enkel-sida-appar anser jag att Index-HTML särskilt kortlivade (t.ex. ingen cachning, måste förnyas eller . max-age=60), eftersom den styr vilken version av paketet som laddas. Alla kompilerade chunkar, teckensnitt och bilder är däremot strikt versionshanterade och får public, max-age=31536000, immutable. På så sätt ser jag till att en ny version med uppdaterad index-HTML omedelbart hänvisar till de korrekta, nya filnamnen, medan befintliga användare stora Hämta tillgångar från den lokala cachen.
Frågesträngar som cache-busting (?v=123) använder jag bara där filnamnen inte går att ändra så lätt. Det är bättre med unika filnamn (hashar), eftersom de segmenterar cachen på ett tydligare sätt och ger upphov till färre specialfall.
Serverkonfiguration: Apache och Nginx
I Apache lägger jag oftast in rubrikerna i filen .htaccess, förutsatt att modulen mod_headers är aktiverad. För statiska resurser anger jag en lång giltighetstid, medan HTML hanteras strängare. I Nginx gör jag detta i location-block, ofta tillsammans med direktivet expires som reservlösning. Jag testar varje ändring med DevTools i fliken ”Nätverk” för att se de verkliga header-värdena. På så sätt förhindrar jag felaktiga regler som annars kan leda till kostsamma Felaktiga förfrågningar skapa.
# Apache (.htaccess)
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, must-revalidate"
# Nginx (serverblock)
location ~* \.(jpg|jpeg|png|gif|css|js|woff2?)$ {
expires 365d;
add_header Cache-Control "public, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
Jag ser till att inga konkurrerande regler i uppströms-tjänster motverkar dessa rubriker. Ett uppströms-CDN får till exempel ställa in egna TTL-värden, vilket jag måste styra medvetet. Om alla nivåer stämmer överens förblir resurserna tillförlitliga lätthittad och konsekvent. Den som granskar noggrant här undviker långdragna felsökningssessioner. Små kontroller sparar mycket tid senare Tid.
CDN- och proxy-praktik: Konfigurera s-maxage och Stale-strategier
För Edge-cacher kompletterar jag serverkonfigurationen med s-maxage samt Stale-direktiv. Exempel från Apache:
# Apache: CDN-optimerade regler
Header set Cache-Control "public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600"
Och i Nginx:
# Nginx: Optimering av delad cache
location ~* \.(json|xml|map)$ {
add_header Cache-Control "public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600";
}
Många CDN:er följer dessa direktiv direkt. Om ditt edge-lager förväntar sig egna rubriker (t.ex. surrogatrubriker) återspeglar jag logiken där och håller webbläsar- och delad cache-strategi tydligt åtskilda. Tack vare versionshantering behöver jag sällan rensa cachen; om det ändå behövs planerar jag det som ett målinriktat, litet ingrepp.
Särskilda fall: omdirigeringar, felsidor och formulärflöden
Omdirigeringar: 301-svar kan enligt specifikationen cachelagras. När jag ställer in tillfälliga omdirigeringar (302/307) anger jag tydliga TTL-värden eller ställer medvetet in ingen lagring, så att ingenting blir fastställt. Permanenta 301-omdirigeringar får ha en måttlig TTL – ändringar blir då ett medvetet och samordnat steg.
Felrapporter: 404/410-svar kan cachelagras under en kort tid (t.ex. max-age=60), för att minska bot-belastningen. Vid 500-talet har jag, beroende på omgivningen stale-om-fel aktiv, så att användarna hellre ser en äldre, fungerande sida än ett felmeddelande.
POST/Nedladdning: Svar på POST-förfrågningar lagras vanligtvis inte i webbläsarens cache. För filexporter som innehåller personuppgifter (t.ex. fakturor) använder jag konsekvent ingen lagring plus säker leverans (t.ex. Content-Disposition), så att inget lagras av misstag. Icke-personanpassade, stora nedladdningar (t.ex. utgåvor) kan däremot med fördel utnyttja offentliga cacher under lång tid.
Undvik typiska misstag
Många förväxlar ingen cacheminne med „ingen cache alls“, vilket leder till onödig belastning. Om man läser det korrekt tillåter no-cache cachelagring, men kräver omvalidering. En annan klassiker: långa max-age-värden utan versionshantering för CSS eller JS, vilket gör att föråldrade filer behålls. Bristande åtskillnad mellan HTML och statiska resurser går ut över hastigheten, eftersom HTML sällan får cachas aggressivt. Den som ignorerar detta bromsar Användarupplevelse från.
Konflikter mellan server, CDN och applikation saboterar cachingeffekterna utan att man märker det. Kontrollera därför överskrivningar och mellanlager om rubriker ändras „som genom ett trollslag“. Här kan det vara bra att titta på loggen och svarskedjan för att avslöja felaktiga prioriteringar. En kortfattad checklista och typiska fallgropar kring Sabotage av cachehuvud underlättar kontrollen. Tydliga prioriteringar förhindrar Biverkningar vid driftsättningar.
Att göra prestationsvinster mätbara
Jag utvärderar effekterna av Cache-Control med hjälp av mått som TTFB, LCP och antalet Förfrågningar per sidvisning. En titt i DevTools visar mig om filer hämtas från „from disk cache“ eller „from memory cache“. Lighthouse, WebPageTest och liknande verktyg ger indikationer på om webbläsarens cachelagring fungerar konsekvent. Jag mäter före och efter en ändring så att jag tydligt kan se verkliga förbättringar. Denna disciplin säkerställer optimeringar begriplig och målinriktat.
Stora bilder, webbteckensnitt och paket som inte laddas vid uppföljande besök har en särskilt stor effekt. HTML-koden förblir nära servern för att användarna snabbt ska få tillgång till nytt innehåll. API:er gynnas märkbart när ofta använda rutter har en måttlig TTL. Resultaten visar sig i form av kortare laddningstider, mindre datavolym och en jämnare serverbelastning. Den som konsekvent kontrollerar detta sparar på lång sikt Resurser.
Service Worker och HTTP-cache: låt dem inte motarbeta varandra
Om jag använder en Service Worker stämmer dess strategi överens med mina HTTP-headers. För statiska, versionerade tillgångar passar „cache-first“ med lång TTL och oföränderlig Utmärkt. För HTML eller API-data som ändras ofta föredrar jag „network-first“ eller „stale-while-revalidate“, så att användarna snabbt får svar och att uppdateringar kommer in i realtid. Viktigt: Service Workern bör respektera omvalideringar (vidarebefordra If-None-Match/If-Modified-Since) istället för att artificiellt behålla innehåll.
Jag vill dessutom göra en tydlig åtskillnad: HTTP-cachen får gärna ta hand om en stor del av arbetet; service workern kompletterar funktionen, den ersätter den inte. På så sätt förblir felsökning och drift överskådliga.
Att förstå direktiv på begärandesidan
Även förfrågningar kan styra cachelagringen. Cache-Control: no-cache på Begäran tvingar fram en omvalidering hos servern, max-age=0 är liknande. ingen lagring I begäran förbjuds lagring av svaret längs kedjan. För offline-fall kan endast om den finns i cachen kan vara användbart: Klienten accepterar då endast svar från cachen. Denna mekanism är till hjälp i appar som ska erbjuda en definierad upplevelse även vid svag anslutning.
Bästa praxis för ditt arbetsflöde
Jag börjar med en inventering: Vilka filtyper finns, vilka är anpassade och vilka ändras sällan? Därefter tillämpar jag regler på ett differentierat sätt så att tillgångarna bevaras länge i Cache förblir oförändrad och HTML-koden hålls uppdaterad. Genom att ta bort versionssträngar i filnamnen undviker man risken för föråldrade paket och möjliggör snabba körningstider. Under regelbundna underhållsperioder kontrollerar jag rubriker och träfffrekvenser för att tidigt kunna upptäcka trender. Denna rutin håller webbplatsen högpresterande och förutsägbar.
Jag dokumenterar konfigurationer kort och tydligt så att framtida ändringar inte av misstag förstör något. Distributionsskripten uppdaterar automatiskt filernas hashvärden så att jag inte glömmer något steg. För releaser använder jag utrullningar med begränsad räckvidd för att testa beteendet i drift. Feedback från övervakning och loggar flödar direkt tillbaka till header-reglerna. På så sätt förblir strategin realistisk och effektiv.
Versionshantering och oföränderliga tillgångar
Jag lägger till hashvärden i filnamnen, till exempel app.20260817.js, och anger sedan public, max-age=31536000, oföränderlig. På så sätt vet webbläsaren att filen aldrig byts ut „tyst“ och slipper göra omvalideringar. Vid nästa release får filen ett nytt namn, vilket gör att webbläsaren laddar just den nya versionen. På så sätt undviker jag föråldrade versioner efter en distribution. Denna taktik passar bra ihop med många Strategier för cachekontroll de mest skiftande stackarna.
För HTML använder jag inte immutable, eftersom sidan ofta ändras och jag vill ha flexibel omvalidering. Detsamma gäller för API-svar med varierande data. Typsnitt och stora bilder är särskilt lämpliga eftersom användarna återanvänder dem flera gånger på olika enheter. Det är viktigt att ha en fullständig koppling mellan hashvärden och releaseversioner. Dokumentation och tydliga Namn undvika förväxlingar inom teamet och i builds.
Praktiska steg för testning och felsökning
Jag öppnar DevTools och granskar svarsrubrikerna på fliken ”Nätverk” för att kontrollera Cache-Control, ETag, Expires och Varierande att kontrollera. En ny uppdatering utan cache (Ctrl+F5) visar mig om reglerna verkligen fungerar. Därefter laddar jag sidan som vanligt och kontrollerar vilka element som hämtas från cachen. För proxyservrar och CDN tittar jag på rubriker som Age eller X-Cache, om sådana finns. Dessa kontroller upptäcker konflikter och felaktiga Prioriteringar snabbt.
På servernivå jämför jag konfigurationer och loggar för att upptäcka avvikelser. Ett vanligt fel: En applikation lägger till header i efterhand och skriver över serverreglerna. I CI/CD-pipelines testar jag header automatiskt i stagingmiljön för att undvika överraskningar i produktionssystemet. Vid problem använder jag tillfälligt korta TTL-värden tills orsaken har hittats. Med tydliga tester håller jag Kontroll om cachingbeteendet i alla lager.
Webbläsarens verklighet: lagringstyper och rensning
Webbläsare skiljer mellan minnes- och diskcache. Små filer som används ofta drar nytta av minnescachen (extremt snabba träffar), medan stora resurser ofta hamnar på hårddisken. Mobila enheter rensar mer aggressivt – därför planerar jag inte in någon strategi som uteslutande bygger på mycket lång webbläsarpersistens, utan säkrar mig med bra metoder för omvalidering. oföränderlig Det förhindrar visserligen onödiga omvalideringar, men bara så länge posten inte har tagits bort på grund av utrymmesbrist.
Att ta bort
Ställ in Cache-kontroll Använd följande strategier: långa giltighetstider och ”immutable” för versionerade tillgångar, försiktiga regler och omvalidering för HTML och personligt innehåll. Kombinera ”max-age” med ”ETag” eller ”Last-Modified” för att spara bandbredd och säkerställa att innehållet är aktuellt. Kontrollera alla nivåer, inklusive CDN, så att reglerna inte motverkar varandra. Undvik att använda no-store bara av reflex, och använd det endast där dataskydd har absolut prioritet. Med tydlig uppdelning efter innehållstyp, konsekvent versionering och löpande mätning uppnår du märkbart snabbare sidor och behåller Suveränitet om din caching.
