Hoppa till innehåll 
HTTP-cachehuvuden avgör hur webbläsare och proxyservrar cachar innehåll – om de är felaktigt inställda bromsar de laddningstiden och ökar serverbelastningen märkbart. I det här inlägget visar jag hur små fel i huvudet kan påverka din Cachingstrategi sabotera och hur du med några få korrigeringar kan bli mätbart snabbare.
Centrala punkter
Följande kärnbudskap hjälper mig att snabbt kontrollera HTTP-rubriker och hålla dem rena på lång sikt.
- TTL Välj rätt: Cache statiska tillgångar mycket länge, HTML kort och kontrollerat.
- Validering Använd: ETag och Last-Modified minskar onödiga förfrågningar.
- Konflikter Undvik: Origin- och CDN-rubriker måste stämma överens.
- Versionshantering Använda: Filhashar möjliggör aggressiva cache-strategier.
- Övervakning Etablera: Mäta HIT-frekvensen och öka den systematiskt.
Vad HTTP-cachehuvuden verkligen styr
Cache-Control, Expires, ETag och Last-Modified avgör om innehållet är aktuellt, hur länge det gäller och när webbläsaren ska begära det. Med max-ålder definierar jag livslängden, med public/private lagringsplatsen i webbläsaren eller delade cacher. Direktiv som ingen lagring förhindrar lagring helt, no-cache tvingar fram en omvalidering före användning. För statiska filer är ett års giltighetstid lämpligt, HTML får korta tider med intelligent omvalidering. Jag bygger dessutom på oföränderlig, om filer garanteras förbli oförändrade genom hash-version.
Denna styrning påverkar direkt latens, bandbredd och serverbelastning. En ökad HIT-frekvens förkortar väntetiderna och minskar backend-arbetet. Dessutom optimerar jag överföringen med HTTP-komprimering, så att färre byte behöver transporteras. Genom att göra en tydlig åtskillnad här avlastas CDN, proxyservrar och webbläsarcacher i lika hög grad. Så skapar jag smidiga Laddningstider genom.
TTL-planering i praktiken
Lämplig TTL beror på ändringsfrekvens, risk och återställningsstrategi. För tillgångar med filhash anger jag 12 månader, eftersom jag kontrollerar ändringar via nya filnamn. För HTML orienterar jag mig efter innehållets dynamik: startsidor eller kategorisidor förblir ofta aktuella i 1–5 minuter, detaljsidor med kommentarer kortare. Det är viktigt att Rollback-sökväg: Om ett fel ändå publiceras behöver jag en snabb rensning (Edge) och en tvingad omvalidering (must-revalidate) för webbläsare. API-svar får korta TTL:er, men med stale-Direktiv så att användarna kan se svaren om ett fel uppstår. Jag dokumenterar dessa profiler per rutt eller filtyp och förankrar dem i bygg-/distributionspipeline så att inga „tysta“ ändringar oavsiktligt underminerar aktualitetspolicyn.
Hur felkonfigurationer saboterar strategin
För kort TTL:er som max-age=60 sekunder för CSS, JS eller bilder tvingar fram ständiga förfrågningar och förstör fördelarna med cachen. Ett globalt ingen cacheminne i CMS-konfigurationer bromsar även när stora delar av en sida egentligen är stabila. Om ETag eller Last-Modified saknas laddar webbläsaren filerna helt på nytt istället för att kontrollera dem på ett smart sätt. Onödiga frågesträngar skapar fragmenterade Cache-nycklar och sänker HIT-frekvensen avsevärt. Om Origin skickar no-cache ignorerar CDN kantcacherna – vilket resulterar i längre vägar och högre serverbelastning.
Jag ser resultatet i mätningarna: fler förfrågningar, högre CPU-tid och ökande svarstider. Vid trafikspikar ökar risken för timeouts. Samtidigt ökar bandbreddsförbrukningen utan att användarna märker någon fördel. Med en titt i DevTools upptäcker jag snabbt sådana mönster. Jag börjar då med att justera Cache-kontroll, innan jag utökar serverresurserna.
Rekommendationer per innehållstyp: lämpliga direktiv
Beroende på innehållstyp använder jag olika Huvud, så att cacher fungerar på ett meningsfullt sätt och användarna ser aktuella data. Följande tabell visar beprövade profiler som jag använder i projekt.
| Innehåll | Rekommenderad cachekontroll | Giltighet | Ledtråd |
|---|---|---|---|
| JS/CSS/bilder (versionerade) | public, max-age=31536000, oföränderlig | 12 månader | Använd filnamn med hash (t.ex. app.abc123.js) |
| Teckensnittsfiler (woff2) | public, max-age=31536000, immutable | 12 månader | Observera CORS om laddas från CDN |
| HTML (offentlig) | public, max-age=300, stale-while-revalidate=86400 | 5 minuter | Kort Färskhet, smidig omladdning i bakgrunden |
| HTML (anpassad) | privat, max-age=0, no-cache | revalidering | Ingen vidarebefordran i delade cacher |
| API:er | public, max-age=60–300, stale-if-error=86400 | 1–5 minuter | Fel med stale dämpa |
Dessa profiler täcker typiska webbplatser och hjälper till att snabbt skapa enhetliga Regler Det är viktigt att ha en tydlig versionering för tillgångar så att långa max-age-värden inte levererar föråldrade filer. HTML förblir kortlivat och uppdateras genom omvalidering. API:er får korta tider och ett säkerhetsnät via stale-if-error. På så sätt förblir sidorna tillgängliga även vid störningar. användbar.
Cacha felkoder och omdirigeringar korrekt
Vidarebefordringar och felsidor förtjänar egna regler. 301/308 (permanent) kan cachelagras mycket länge i CDN och webbläsare; jag anger ofta dagar till veckor här för att undvika omdirigeringskedjor. 302/307 (tillfälligt) får korta TTL:er, annars „fryses“ tillfälliga tillstånd. För 404/410 är det värt att ha en måttlig aktualitet (t.ex. minuter till timmar) så att bots och användare inte ständigt frågar efter; vid ofta växlande innehåll håller jag 404 ganska kort. 5xx-Jag cachar i princip inte fel, utan förlitar mig på stale-if-error för att tillfälligt leverera fungerande kopior. På så sätt förblir plattformen stabil och jag minskar omrenderingbelastningen för ofta efterfrågade men saknade sökvägar.
Använd validering på rätt sätt: ETag och Last-Modified
Med ETag och Last-Modified kontrollerar webbläsaren om en resurs verkligen behöver laddas om. Klienten skickar If-None-Match eller If-Modified-Since, och servern svarar helst med 304 istället för 200. På så sätt sparar jag överföring och minskar Trafik tydligt. För statiska filer räcker det ofta med Last-Modified, för dynamiskt genererat innehåll använder jag ETags. Viktigt: Konsekvent ETag-generering så att cacherna känner igen träffar.
Jag kombinerar gärna validering med stale-Direktiv. stale-while-revalidate håller sidorna snabba medan uppdateringar sker i bakgrunden. stale-if-error säkerställer driftsäkerhet vid problem med backend. På så sätt förblir användarupplevelsen stabil och servrarna skonas. Följande kodsnuttar visar typiska inställningar som jag använder.
Header set Cache-Control "public, max-age=31536000, immutable"
/etc/nginx/conf.d/caching.conf location ~* .(css|js|png|jpg|svg|woff2)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }
Avancerade direktiv och detaljer
Förutom max-age använder jag specifikt s-maxage, för att fylla Edge-cacher längre än webbläsare. Så kan CDN till exempel hålla i 1 timme, medan klienter validerar på nytt efter 5 minuter. måste-omvalidera tvingar webbläsare att kontrollera utgångna kopior före användning – viktigt för säkerhetsrelaterade områden. proxy-revalidate riktar skyldigheten mot delade cacher. Med ingen omvandling förhindrar jag att proxyservrar ändrar bilder eller komprimering utan tillstånd. För bred kompatibilitet skickar jag förutom Cache-Control även ett valfritt Upphör att gälla-Datum i framtiden (Assets) eller det förflutna (HTML), även om moderna cacher i första hand följer Cache-Control. När det gäller CDN-strategier skiljer jag mellan webbläsar- och kantregler: public + max-age för klienter, plus s-maxage/Surrogate-Control för kanten. Denna uppdelning maximerar HIT-frekvensen utan risk för föråldrade data på slutapparater.
Samverkan med CDN och edge-cacher
Ett CDN respekterar Ursprungsrubrik – Felaktiga direktiv vid källan inaktiverar globala cacher. För delade cacher ställer jag in public och vid behov s-maxage så att kanterna håller längre än webbläsaren. Surrogate-Control kan dessutom tillhandahålla regler för Edge-cacher. Om no-cache träffar källan vägrar CDN att visa den önskade Förvaring. Därför anpassar jag medvetet webbläsar- och CDN-strategin efter varandra.
Vid nya projekt undersöker jag dessutom förladdningsstrategier. Med HTTP/3 Push & Preload laddar jag kritiska tillgångar tidigt och minskar renderingsblockeringar. Denna teknik ersätter inte caching, utan kompletterar den. Tillsammans med långa TTL:er för tillgångar förbättras startprestandan märkbart. På så sätt arbetar jag med nätverksrankningen innan Server överhuvudtaget börjar svettas.
Vary-strategin i detalj
Varierande bestämmer vilka förfrågningsrubriker som skapar nya varianter. Jag håller Vary minimalt: För HTML oftast Accept-Encoding (komprimering) och eventuellt språk; för tillgångar helst inte alls. Ett för brett Vary (t.ex. User-Agent) förstör HIT-frekvensen. Samtidigt måste ETags som representationsspecifik Spegla variant: Om jag levererar gzip eller br gäller ETags per kodningsvariant och jag ställer in Vary: Accept-Encoding. Om jag använder svaga ETags (W/) ser jag till att generera dem konsekvent, annars uppstår onödiga 200-fel. Typsnitt eller bilder ska i regel klara sig utan Vary, så att nycklarna förblir stabila. Mitt princip: Definiera först vilka varianter som är tekniskt nödvändiga – först därefter utöka Vary, aldrig tvärtom.
Övervakning och diagnostik i DevTools
Jag startar alltid i Nätverksflik webbläsarverktygen. Där kan jag se om svaren kommer från cachen, hur gamla de är och vilka direktiv som gäller. Kolumnerna Age, Cache-Control och Status hjälper till med snabba kontroller. En HIT-frekvens under 50% visar att åtgärder behövs, målvärden på 80% och mer är realistiska. Vid avvikelser kontrollerar jag först de tillhörande rubrikerna.
Verktyg som PageSpeed eller GTmetrix bekräftade mina lokala Mätningar. Jag jämför sedan före/efter ändringarna för att kvantifiera nyttan. Om det tillkommer stora överföringsmängder aktiverar jag konsekvent modern komprimering. På så sätt sparar jag ytterligare millisekunder. Så dokumenterar jag varje justering med hårda Siffror.
Automatiserade kontroller och CI
För att reglerna inte ska urholkas förankrar jag header-kontroller i CI. Jag definierar målprofiler per sökväg och låter varje build kontrolleras slumpmässigt mot staging. Enkla shell-kontroller räcker ofta:
# Exempel: Förväntade direktiv för versionerade tillgångar curl -sI https://example.org/static/app.abc123.js | grep -i "cache-control" # Förväntad kortvarighet och omvalidering för HTML
curl -sI https://example.org/ | egrep -i "cache-control|etag|last-modified" # Inspektera Age-Header och Cache-Status (om tillgängligt) curl -sI https://example.org/styles.css | egrep -i "age|cache-status|x-cache"
I kombination med syntetiska tester planerar jag regelbundna „header-revisioner“. Resultaten återförs till infrastrukturkoden. På så sätt förblir Policys stabil – oavsett vem som senast har gjort ändringar i CMS, CDN eller serverkonfigurationen.
Hostingoptimering: sid-, objekt- och opcode-caching
Förutom webbläsar- och CDN-cacheminnen använder jag Servercacheminnen. Sidcaching levererar färdiga HTML-sidor, objektcaching buffrar databasresultat och OPcache hanterar PHP-bytecode. Dessa lager avlastar backend kraftigt när rubrikerna är korrekt inställda. Det är först kombinationen av snabba kanter, sunda TTL:er och servercacher som ger verkliga toppvärden. På så sätt håller jag svarstiderna stabila, även när Trafik ökar.
Följande marknadsöversikt visar vad jag tittar efter när det gäller webbhotell. En hög träfffrekvens, Redis-tillgänglighet och ett bra pris är avgörande för valet.
| Hostingleverantör | PageSpeed-poäng | Redis-stöd | Pris (startpaket) |
|---|---|---|---|
| webhoster.de | 98/100 | Ja | 4,99 € |
| Annan1 | 92/100 | Valfritt | 6,99 € |
| Annan2 | 89/100 | Nej | 5,99 € |
Ogiltigförklaring och rensningsstrategier
Cache-uppbyggnad är bara halva jobbet – den Ogiltigförklaring avgör säkerhet och smidighet. För tillgångar löser jag ändringar via filhashar, så att inga rensningar behövs. För HTML och API:er planerar jag riktade rensningar: efter distribution (kritiska rutter), efter publicering (endast berörda sidor) eller efter funktionsflaggor. Jag stöder gärna kantcacher via taggar/nycklar för att hela Grupper att tömma istället för att ta bort sökvägarna en efter en. När det är möjligt använder jag „Soft Purge“: innehållet markeras omedelbart som „stale“ och valideras först vid nästa förfrågan. På så sätt undviker jag belastningstoppar genom samtidiga återhämtningar. Det är viktigt med en organiserad mappning: vilka händelser utlöser vilken rensning? Denna logik måste versioneras i plattformen.
Säkerhet och dataskydd: offentligt kontra privat
Personliga sidor hör hemma i Privat cache i webbläsaren, inte i delade cachar. Därför anger jag private, max-age=0 eller no-cache för sådant innehåll. Offentliga HTML-sidor kan få public med kort aktualitet. Om jag är uppmärksam på cookies i begäran förblir innehållet tydligt åtskilt. På så sätt förhindrar jag att främmande användare oavsiktligt Uppgifter andra ser.
Samtidigt tillämpar jag strikta regler för betalnings- och kontoområden. no-store förhindrar all lagring av känsliga svar. För resten av webbplatsen är jag generös så att prestandan blir rätt. Denna tydliga åtskillnad gör plattformen snabb och säker. Jag dokumenterar Profiler, så att alla inblandade förblir konsekventa.
Förstå heuristisk caching
Om Cache-Control och Expires saknas, använder cacherna heuristik tillbaka – ungefär en procentandel av tiden sedan Last-Modified. Detta leder till svårreproducerbara resultat och varierande aktualitet. Jag undviker sådana automatismer genom att uttryckligen förse varje relevant rutt med Cache-Control. När Last-Modified är inexakt (t.ex. vid dynamiska mallar) föredrar jag ETags. På så sätt styr jag aktivt aktualiteten och får stabila mätvärden över alla klienter.
Range-förfrågningar och stora filer
För media och nedladdningar spela Räckvidd-förfrågningar (206 Partial Content) spelar en roll. Jag aktiverar Accept-Ranges och levererar konsistenta ETags/Last-Modified så att webbläsare kan återanvända delar på ett korrekt sätt. För versionshanterade videosegment (HLS/DASH) använder jag långa TTL:er; manifesten själva förblir kortlivade. Viktigt: Hantera If-Range korrekt så att delområden inte leder till föråldrade blandade tillstånd vid ändringar. För känsligt innehåll gäller fortfarande: ingen lagring med no-store, även om Range är i spel.
Åtgärda vanliga fel snabbt: mitt Playbook
Jag börjar med en översikt över rubrikerna: Vilka direktiv levererar Origin och vad ändrar CDN? Därefter definierar jag TTL-profiler per innehållstyp. Versionshanterade tillgångar får ett år, HTML fem minuter plus omvalidering. Jag aktiverar ETag/Last-Modified överallt där det är meningsfullt. Därefter kontrollerar jag om onödiga Vary- eller Query-parametrar påverkar HIT-frekvens trycka.
I nästa steg tar jag hand om nätverksdetaljer utanför cachen. En felaktig Charset-rubrik eller bristande komprimering kostar också tid. Därefter mäter jag igen: DevTools, syntetiska tester och vid behov Real-User-Monitoring. Om värdena stämmer fryser jag reglerna i konfigurationen och håller dem versionerade. Så växer kvalitet Steg för steg.
Kortfattat sammanfattat
Med korrekta HTTP-rubriker styr jag vad som ligger var och hur länge – och sparar både tid och resurser. Långa TTL:er för versionerade tillgångar, korta tider plus omvalidering för HTML och meningsfulla stale-direktiv ger snabbhet och flexibilitet. Rena cache-nycklar, konsekvent versionering och tydliga regler för public/private förhindrar typiska stötestenar. Övervakning ger bevis och visar kvarvarande luckor. Den som går tillväga på detta sätt lyfter Prestanda märkbar och stabil.
