Koppel beleid aan het resource, niet aan de server
Maak een inventaris van representatieve URL's voordat je headers wijzigt: een startpagina, contentpagina, application shell, CSS, JavaScript, afbeeldingen, lettertypen, API's, inloggen, account, checkout en downloads. Noteer voor elk of de response publiek of gepersonaliseerd is, of de URL verandert als de bytes veranderen, en hoe snel een correctie bezoekers moet bereiken.
Maak vanuit die inventaris een beleidsmatrix. Een publiek content-geadresseerd asset heeft een ander regel nodig dan HTML op een stabiel adres. Responses zonder Cache-Control kunnen nog steeds heuristisch worden gecached, dus expliciete regels zijn makkelijker te testen.
De periode waarin een opgeslagen response hergebruikt mag worden; max-age geeft dit in seconden.
Gebruik Cache-Control-termen precies
Cache-Control vertelt browsers en gedeelde caches hoe een response opgeslagen en hergebruikt moet worden. max-age=N staat hergebruik toe zolang het antwoord fresh is. s-maxage=N stelt shared-cache freshnes in en overschrijft daar max-age, maar browsers negeren s-maxage. public staat caching toe in elke cache; private staat browsercaching toe maar verhindert gedeelde-cacheopslag.
no-cache staat opslag toe maar vereist origin-validatie vóór hergebruik. no-store betekent dat caches de response niet mogen opslaan, maar is geen volledige privacycontrole. Gebruik must-revalidate wanneer het onacceptabel is om na verval verouderde inhoud te serveren; een onbeschikbare origin kan dan een 504 retourneren in plaats van een stale fallback.
Het verbiedt opslag in plaats van alleen een controle te vereisen; reserveer het voor responses die daadwerkelijk niet opgeslagen mogen worden.
Versioneer immutabele assets vóór toekenning van lange levensduur
Een geversioneerd asset-URL bevat een content-fingerprint of releaseversie, zoals app.4f2c.js. Wanneer de assetbytes veranderen, publiceer je een ander URL en werk je de HTML-verwijzing bij. De cache ziet een nieuw resource, dus bezoekers halen het nieuwe asset op zonder dat een invalidatie elke browser hoeft te bereiken.
Voor een representatie die tijdens haar freshness lifetime niet verandert, is Cache-Control: max-age=31536000, immutable een praktisch patroon. immutable vertelt ondersteunde clients niet conditioneel te valideren zolang het fresh is. Pas dit of een jaarlange max-age niet toe op een mutabel bestand met hetzelfde URL. Bewaar eerdere fingerprinted assets zolang gecachte HTML ze mogelijk nog kan refereren.
HTML kiest asset-URL's, dus release-sequencing moet de gerefereerde generatie behouden.
Houd HTML actueel via validatie, niet via lange caching
HTML heeft meestal een stabiel, menselijk toegankelijk URL en verandert met content, assetverwijzingen, feature flags of beveiligingsmeldingen. Een conservatief publiek HTML-patroon is Cache-Control: no-cache met ETag en Last-Modified wanneer je platform die correct kan produceren. De browser slaat de body op maar gebruikt een conditioneel verzoek vóór hergebruik; een ongewijzigde response kan 304 Not Modified zonder body teruggeven.
ETag identificeert een resourceversie. Bij een stale response kan de browser deze meesturen in If-None-Match; als het overeenkomt, antwoordt de server met 304, anders stuurt hij de nieuwe representatie. RFC-richtlijnen geven de voorkeur aan zowel ETag als Last-Modified op een 200-respons wanneer mogelijk. no-cache belooft geen validatie bij Back- of Forward-navigatie omdat een browser een session-history snapshot kan herstellen.
Een ETag moet veranderen wanneer de representatie verandert; test dit over origins en deployments.
Scheid publieke levering van gepersonaliseerde en gevoelige responses
Een gedeelde cache, zoals een CDN, kan één response hergebruiken voor meerdere gebruikers. Laat deze niet account-specifieke HTML of API-gegevens over meerdere gebruikers hergebruiken. Voor gepersonaliseerde content die in een browser kan leven is private, no-cache een redelijk uitgangspunt: het voorkomt gedeelde opslag en vereist validatie. Een Set-Cookie-header alleen stopt caching niet.
Voor responses die niet opgeslagen mogen worden, gebruik no-store en controleer applicatiecode, CDN-regels, service workers, browseropslag, logs en foutpagina's. Alleen headers zijn geen privacy-, compliance- of betaalveiligheidsprogramma. Laat gekwalificeerde beveiligings-, privacy- en betalingsreviewers gevoelige flows en toepasselijke eisen beoordelen.
Test inloggen, uitloggen, accountwissel en permissiewijzigingen met warme browser- en CDN-caches.
Rol cachewijzigingen uit als een omkeerbare release
Neem baseline-headers en body-gedrag vast voor ongecachede en herhaalde verzoeken. Deploy in staging eerst geversioneerde assets, daarna de HTML die ernaar verwijst, en test oudere gecachte HTML tegen de nieuwe origin. Controleer directe-origin en CDN-paden als beide bestaan. DevTools Network-headers moeten het bedoelde beleid en het herhaalgedrag tonen.
Houd een releasemanifest bij van asset-URL's, headeregels en configuratieversie. Als een release incompatibele clientbestanden combineert, herstel dan compatibele HTML en applicatiegedrag, maar overschrijf geen gepubliceerde fingerprinted file. Verwijs HTML terug naar de bekende-goede generatie en behoud beide generaties zolang gecachte HTML ze mogelijk kan opvragen. Een shared-cache purge kan browsers niet dwingen een fresh response te verwijderen.
Zet header-testfouten, asset 404's en versiemismatches om in wijzigingen voor de checklist van de volgende release.