Videre til indhold 
Jeg bruger cache control hosting til specifikt at styre, hvordan browsere, proxyer og CDN'er cacher indhold, så siderne indlæses hurtigere og stadig er opdaterede. For at gøre dette bruger jeg målrettet direktiver såsom max-age, no-cache eller no-store og dermed balancere ydeevne, friskhed og serverbelastning for HTML, aktiver og API'er.
Centrale punkter
Følgende oversigt viser de vigtigste løftestænger for Weboptimering med cache-kontrol.
- TTL-designLang max-alder for aktiver, korte tider eller revalidering for HTML.
- ValideringETag og Last-Modified reducerer datatrafikken med 304-svar.
- Kontrol af kanter: s-maxage, stale-while-revalidate og stale-if-error for CDN'er.
- Versionering: Filnavne med hash/version giver mulighed for aggressive cacher.
- OvervågningTjek løbende cache-hitrater, 304-kvoter og TTFB.
Hvad gør cache-kontrol så effektiv i hosting?
Jeg flytter arbejde fra Origin-serveren til Cache, reducere ventetiden og spare båndbredde. En korrekt indstillet cache control header styrer, hvor længe filer er gyldige, og hvornår klienten anmoder om dem fra serveren. Jeg planlægger lange gyldighedsperioder for aktiver som billeder, CSS og JS, mens HTML lever i kort tid eller altid er valideret. Det betyder, at brugerne støder på cachelagrede svar oftere og stadig modtager aktuel Indhold. Jeg undgår typiske snublesten som modstridende overskrifter eller manglende versionering på et tidligt tidspunkt, for eksempel med dette Cache-fix-guide.
Grundlæggende: Kombiner direktiver korrekt
Med max-alder Jeg indstiller levetiden i sekunder, såsom 31536000 i et år for statiske ressourcer. no-cache tvinger klienten til at validere før brug, men forbyder ikke lagring. no-store udelukker enhver lagring og beskytter følsomme svar såsom betalingsdata. public tillader caching i delt lagring såsom CDN'er, private er begrænset til browserens cache. immutable signalerer, at filen forbliver uændret, hvilket kan ændres med Versionering (f.eks. app.v1.2.js) er en fremragende tilføjelse.
Klart definerede Vary-overskrifter og cachenøgler
Jeg sørger for, at cachelagrede objekter matcher anmodningstypen. Den Varierer-header hører derfor hjemme i enhver seriøs cachestrategi. Den påvirker cachenøglen og forhindrer forkert genbrug:
- Accept-EncodingObligatorisk for gzip/br, så komprimerede og ukomprimerede varianter cachelagres separat.
- Accept-sprog: Bruges kun, hvis jeg virkelig leverer sprogafhængigt indhold - ellers er der risiko for fragmentering.
- Kage: Jeg undgår en global Variabel: Cookie, fordi det ødelægger cache-hitraten. I stedet segmenterer jeg specifikt efter relevante cookies (f.eks. A/B-variant) eller fjerner irrelevante cookies i udkanten.
- AutorisationIndhold, der afhænger af auth-headere, gemmes ikke i delte cacher, eller jeg nøgler dem bevidst, hvis CDN-udbyderen understøtter dette.
# Apache: meningsfulde Vary-overskrifter til HTML og aktiver
.
Header-fletning Vary "Accept-kodning"
Headerfusion V "Accept-Entwicklung".
Header merge Vary "Accept-Encoding"
Jeg definerer også klare regler for cache-nøgler på CDN'er: Jeg inkluderer ikke forespørgselsparametre, der kun bruges til sporing (f.eks. utm_*) i nøglen. Det forhindrer en nøgleeksplosion uden at bringe friskheden i fare.
Øvelse: Konfiguration på Apache og Nginx
På Apache indstiller jeg regler i .htaccess eller i den virtuelle vært. Jeg adskiller HTML fra aktiver, giver statiske filer en lang levetid og sikrer HTML med revalidering. Jeg undgår konflikter med Expires-headere, og moderne browsere respekterer primært cache-kontrol. På Nginx håndhæver jeg korrekte add_header-positioner og sørger for, at ingen downstream-instruktioner overskriver dem. Det er sådan, jeg kontrollerer Browser-caching konsekvent på tværs af hele stakken.
.
Header set Cache-Control "public, max-age=31536000, immutable"
Header set "public=" </FilesMatch
Header-sæt Cache-Control "no-cache, must-revalidate"
location ~* \.(css|js|png|jpg|svg|woff2)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
placering ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
Kun CDN-caching til HTML
Hvis browseren altid skal tjekke, men Edge har lov til at cache, indstiller jeg forskellige levetider for klient og CDN:
# Apache: Browser revalideret, Edge cachelagret 5 minutter
Header set Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400"
Header merge Vary "Accept-kodning"
# Nginx
placering ~* \.(html)$ {
add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400";
add_header Vary "Accept-Encoding";
}
Validering: Brug af ETag og Last-Modified effektivt
Jeg kombinerer Cache-kontrol med ETag og Last-Modified for at genvalidere på en kontrolleret måde. Efter udløb sender browseren If-None-Match eller If-Modified-Since; serveren svarer med 304, hvis ressourcen er uændret. Dette sparer bytes og reducerer CPU-tiden på Origin betydeligt. Vigtigt: ETags skal være konsistente, ellers vil der opstå unødvendige misses på trods af uændret indhold. På klynger deaktiverer jeg svage ETags eller opretter stærke hashes, så Revalidering forbliver pålidelig.
Konsistens i miljøer med flere servere
Jeg sørger for, at ETags ikke er baseret på inode-baserede funktioner, der er forskellige fra node til node. Jeg leverer enten en stabil hash (build-artefakt) eller stoler på sidst ændrede, når implementeringer er atomare. Til dynamiske svar bruger jeg applikations-ETags, der nøjagtigt matcher payload-hash'en. Hvis revalidering er dyrere end gengivelse, svarer jeg bevidst med 200 og en kort TTL - målingen afgør det.
Strategier efter ressourcetype
Jeg skelner mellem indholdstyper, fordi HTML, aktiver, API'er og følsomme svar har forskellige Kravene. Lange TTL'er for versionerede filer giver de bedste værdier, mens HTML skal forblive stramt styret. Jeg planlægger korte levetider for API'er og indbygger fejltolerance. Jeg forhindrer enhver lagring af personlige eller fortrolige svar. De, der går dybere ind i grænseflader, drager fordel af kompakte mønstre for API-caching i hosting, som jeg tilpasser til responsens egenskaber.
| Ressource-type | Anbefalet direktiv | Årsag |
|---|---|---|
| Statiske aktiver (billeder, CSS, JS) | offentlig, max-age=31536000, uforanderlig | Lang opbevaring; versionering forhindret Stale-Indhold |
| HTML-sider | no-cache, must-revalidate | Frisk indhold gennem Revalidering |
| API'er | offentlig, max-age=300, stale-if-error=86400 | Kort deadline, kan bruges til Fejl |
| Følsomme data | ingen opbevaring | Ingen opbevaring fra Databeskyttelse-Årsager |
Statuskoder, omdirigeringer og fejlsider
- 301 kan og bør caches (lang TTL), da den er permanent. Jeg versionerer mål-URL'er for at lette senere ændringer.
- 302/307 er midlertidige - kort TTL eller revalidering, ellers er der risiko for forkerte stier i cachen.
- 404 Jeg cacher i kort tid (f.eks. 60-300s), så defekte hotlinks ikke belaster Origin uden at blokere for rigtige genskabelser.
- 500+ Jeg cacher ikke, men jeg efterlader Edge stale-if-fejl for at give brugerne den nyeste information.
Udvidede direktiver til CDN'er og Edge
Med s-maxage Jeg adskiller levetiden i edge-cachen fra den i browseren. stale-while-revalidate fortsætter med at levere udløbet indhold, mens edge opdaterer i baggrunden. stale-if-error holder siderne tilgængelige under backend-udfald og øger konverteringen og tilliden. must-revalidate gennemtvinger et tjek efter udløb og forhindrer uønskede fornyelser. Denne kontrol betaler direkte på cache-hitrater og Skalering især under spidsbelastninger.
Surrogat- og kantoverskrifter
I opsætninger med kantgengivelse bruger jeg også surrogatoverskrifter (f.eks. Surrogatkontrol) for at indstille mere CDN-specifikke TTL'er og stale-politikker uden at ændre browserens adfærd. På den måde adskiller jeg strengt slutbrugeren og edge-strategien og bevarer min kontrol over begge niveauer.
Invalidering og frigivelse
Jeg planlægger bevidst ugyldiggørelse: Versionerede aktiver har sjældent brug for rensninger, mens HTML- og API-ruter har brug for dem oftere. Jeg definerer klare rutiner for:
- Rensning efter URL/mønster for hotfixes og fejl.
- Tag-baserede udrensninger (hvis understøttet) for at ugyldiggøre tematisk relateret indhold.
- Trinvis udrulningImplementer først aktiverne og derefter HTML med nye referencer - det forhindrer ødelagte referencer.
WordPress: Implementer caching på en sikker måde
I WordPress aktiverer jeg overskrifter via plugins eller min egen kode og observerer Skabelon-struktur. Statiske filer i wp-includes og uploads får lange TTL'er plus immutable, sider får no-cache med must-revalidate. Forsigtig med indloggede brugere: Private og differentierede cookies forhindrer forkert personalisering i cachen. Jeg fjerner typiske snublesten med klare regler og et kig på disse WordPress caching-fejl. Hvis det er nødvendigt, tilføjer jeg sidecaching på serversiden og OPCache for at gøre PHP-udførelsen mærkbar. falder.
<?php
funktion add_cache_headers() {
if (!is_admin()) {
header('Cache-Control: public, max-age=31536000, immutable', true);
}
}
add_action('send_headers', 'add_cache_headers');
Afværg personalisering og cookies
Jeg sørger for, at Set-Cookie ikke er indstillet over hele linjen på alle sider. Unødvendige cookies forhindrer delt caching. Jeg leverer eksplicit til indloggede brugere:
# Eksempel på header for indloggede sessioner
Cache-kontrol: privat, no-store, max-age=0
Vary: Accept-kodning
Liste- og detaljesider uden personalisering får på den anden side fuld CDN-kraft. Hvor personalisering er nødvendig, arbejder jeg med edge-fragmenter eller små API-payloads og får resten cachelagret aggressivt.
Almindelige fejl og hvordan jeg løser dem
For lav TTL genererer unødvendigt serverarbejde og højere svartider. Manglende eller modstridende headere tvinger browsere til heuristisk adfærd og koster performance. Uden versionering risikerer jeg forældede aktiver på trods af lange cacher. Forskellige ETag-strategier på flere servere fører til fejl; jeg sikrer konsistente hashes eller deaktiverer ETags der. Jeg tjekker også, om mellemmænd som gateways har deres egne Overskrift og overskrive.
Undgå heuristisk caching
Hvis hverken Cache-Control eller Expires er angivet, gætter browserne. Jeg slår derfor altid eksplicitte direktiver fra og rydder op i gamle problemer (f.eks. Pragma: no-cache fra gamle proxyer) for at opnå en deterministisk adfærd.
Forespørgselsstrenge og cache-busting
Jeg bruger cache-busting via filnavn-hashes (style.abc123.css) i stedet for query-strenge. Mange cacher behandler forskellige forespørgsler som separate objekter og øger dermed antallet af objekter; med uændrede filer fører en ny hash på den anden side til en ren ugyldiggørelse.
Overvågning, test og målinger
Jeg måler effekter og foretager målrettede korrektioner i stedet for at foretage gennemgribende ændringer, fordi data slår mavefornemmelsen. klar. Jeg bruger curl til at tjekke headers, DevTools til at simulere første og gentagne visninger og Lighthouse til at evaluere effekten på nøgletal. På server- og CDN-siden overvåger jeg cache-hitrater, 304-kvoter, bytebesparelser og TTFB. Logfiler viser mig, om HTML virkelig bliver revalideret, og om der sjældent bliver anmodet om aktiver igen. Det giver mig mulighed for at genkende huller tidligt og forbedre målrettet.
Yderligere diagnostiske signaler
- Alder-header viser, hvor længe et objekt har ligget i cachen - ideelt til at tjekke s-maxage.
- Cache-status (hvis tilgængelig) afslører HIT/MISS/STALE og kilden (BROWSER, CDN, ORIGIN).
- Server-timing Jeg bruger det til mine egne markører (f.eks. cache;desc=“revalidated“) for at gøre stier synlige i værktøjer.
Jeg automatiserer kontroller i CI/CD-pipelinen: Efter hver udrulning validerer et lille testkatalog overskrifter, statuskoder og svarstørrelser for de vigtigste ruter. Regressioner opdages med det samme.
SEO og forretningseffekter
Hurtigere levering styrker Core Web Vitals, reducerer antallet af afvisninger og øger Synlighed. Hver tur/retur, der undgås, reducerer serveromkostningerne og minimerer risikoen for spidsbelastninger. Med trafikintensive websteder sparer jeg en mærkbar mængde datamængde hver måned; afhængigt af taksten kan det løbe op i et trecifret beløb i euro. En høj cache-hitrate stabiliserer også svartiderne for kampagner og salg. De, der øger ydeevnen på en forudsigelig måde, øger normalt også Konvertering.
Praktisk tjekliste i 7 trin
(1) Inventariser filer og adskil HTML, aktiver, API'er og følsomme svar; disse Segmentering gør det lettere at lave regler. (2) Indfør versionering for CSS/JS/billeder; brug hashes i filnavne og sæt immutable. (3) Indstil no-cache og must-revalidate for HTML; hold siderne friske og kontrollerbare. (4) Definer korte TTL'er for API'er plus stale-if-error for at afbøde fejl. ophold. (5) Aktiver ETag eller Last-Modified konsekvent; tjek 304 kvoter. (6) Synkroniser CDN- og Origin-headers; brug s-maxage til Edge. (7) Mål hitrater, TTFB og bytebesparelser; optimer iterativt og dokumenter beslutninger.
Yderligere praktiske cases og eksempler
- API'er med betingede anmodningerJeg tillader udtrykkeligt GET/HEAD-svar i den delte cache (offentlig) med en kort TTL og ETag. Jeg cacher kun POST-svar, hvis de er præcist definerede og uændrede - de kan ikke caches som standard.
- Store filer og anmodninger om rækkevidde: For Media leverer jeg Accept-områder: bytes og lange TTL'er; Edge aflaster Origin, når den genoptager downloads.
- Responsive billederHvis jeg udsender forskellige billedvarianter afhængigt af enheden, taster jeg specifikt (f.eks. i henhold til DPR eller Width) og undgår ukontrolleret Vary på for mange signaler.
- Ingen forvandling: Hvis billedkvalitet eller kryptografi er kritisk, bruger jeg Cache-kontrol: no-transform, så proxyer ikke ændrer ressourcen.
Opsummering til at tage med
Jeg bruger Cache-Control specifikt til at Ydelse, for at harmonisere aktualitet og omkostninger. Lange TTL'er plus versionering for aktiver, revalidering for HTML og korte deadlines for API'er giver pålideligt gode resultater. ETag og Last-Modified reducerer datatrafikken, mens s-maxage og stale-politikker udnytter edge caching. Overvågning gør effekterne synlige og viser, hvor jeg bør stramme op. Dette holder hosting hurtig, kontrollerbar og økonomisk attraktiv.
