De productpagina toont de oude prijs na een flashpromo – ondersteuning geeft “de CDN” de schuld. In werkelijkheid stuurt PHP Cache-Control: public, max-age=3600 naar de HTML-catalogus, Cloudflare respecteert deze richtlijn en alleen de winkelwagen-API retourneert no-store. JavaScript-items blijven actueel dankzij de hash in de bestandsnaam; de HTML-catalogus blijft een heel uur bevroren. Niemand heeft gedocumenteerd welke laag welke bron cachet.
HTTP-cacheheaders vormen het contract tussen uw oorsprong, het CDN en de browser. Als je verkeerd uitgelijnd bent, betaal je meerdere keren: latentie voor de gebruiker, oorsprongsoverhead of verouderde inhoud die het vertrouwen verzwakt. Een CDN geactiveerd zonder coherent beleid voegt een netwerkstap toe zonder het voordeel weg te nemen.
De suite stelt een resource-voor-resource-matrix in – geen schuifregelaar voor ‘cache ingeschakeld’ in het hostingpaneel.
Cache-Control: de richtlijnen die er echt toe doen
Cache-Control is de richtlijn die het meest wordt gelezen door browsers en CDN's. Elk zoekwoord heeft een specifiek effect:
| Richtlijn | Effect |
|---|---|
max-leeftijd=N | Bron als nieuw beschouwd N seconden aan browserzijde |
s-maxage=N | Dezelfde logica, maar voor gedeelde caches (CDN) |
geen winkel | Geen opslag — gevoelige gegevens, accountpagina's |
geen cache | Geautoriseerde opslag, verplichte verlenging vóór gebruik |
onveranderlijk | Vingerafdrukken van activa genomen — geen onnodige hervalidatie |
verouderd-terwijl-opnieuw valideren | Een verouderde versie weergeven tijdens een asynchrone vernieuwing |
Voor dynamische HTML (catalogus, artikelen, gepersonaliseerde pagina's) geeft u de voorkeur aan 'privé, geen cache' of een korte 'max-leeftijd' gekoppeld aan hervalidatie. Voor statische assets met een hash in de naam (/app.abc123.js), is public, max-age=31536000, onveranderlijk de verwachte standaard.
Een CDN raadt uw bedoeling niet; het gehoorzaamt de headers, tenzij er een expliciete overschrijfregel in het paneel staat.
Controleer bij shared hosting of een VPS met geïntegreerd CDN (OVH, Infomaniak, etc.) of de panelregels niet in tegenspraak zijn met wat uw applicatie verzendt. Conflicten tussen nginx, PHP en het CDN zijn een van de meest voorkomende oorzaken van verouderde inhoud.
CDN, oorsprong en de Vary-header-trap
De Vary-header vertelt de cache welke dimensies van het verzoek het antwoord beïnvloeden. Er komen steeds twee gevallen naar voren:
Varieren: Accept-Encoding — essentieel als u Brotli en gzip bedient, afhankelijk van de client. Zonder Vary kan een CDN de gzip-versie in de cache opslaan en deze aanbieden aan een klant die Brotli verwacht.
Varieren: Accepteren — nodig als u via de Accept-header over het afbeeldingsformaat (WebP, AVIF) onderhandelt. Zonder Vary kan het CDN een AVIF aanbieden aan een browser die dit niet ondersteunt. Voor de volledige strategie, zie WebP en AVIF.
Configureer cachesleutel aan CDN-zijde: neem codering op, sluit sessiecookies uit op openbare middelen. Een Set-Cookie op een CSS-bestand kan bij sommige providers edge-caching voorkomen.
ETag, 304 reacties en laden op oorsprong
Met voorwaardelijke hervalidatie kunt u voorkomen dat u een ongewijzigd bestand opnieuw downloadt. De client verzendt 'If-None-Match' met de ontvangen ETag; de server antwoordt 304 zonder tekst als de inhoud identiek is.
In een cluster met meerdere knooppunten wordt een door een machine gegenereerde ETag (inode, tijdstempel) inconsistent: de client ontvangt 200s in plaats van 304s, en de oorsprong neemt de belasting over. Geef de voorkeur aan een stabiele inhoudshash, of delegeer de cache naar het CDN met een lange duur op activa met vingerafdrukken.
Voor een gebruiker blijft een JSON API (/api/me, /api/orders), no-store of een zeer korte cache met sleutel per gebruiker de norm. Een gedeelde CDN-cache op deze routes maakt privégegevens openbaar.
Strategie per resourcetype
Elk type bestand verdient zijn eigen beleid – gedocumenteerd, getest, gedeeld met het team:
| Bron | Aanbevolen beleid |
|---|---|
| CSS/JS met hash | 1 jaar, onveranderlijk |
| Statische afbeeldingen | 7 tot 30 dagen + gerichte opschoning bij implementatie |
| Openbare HTML | korte max-age + verouderd-terwijl-revalidate, of no-cache |
| Gebruikers-API | privé, geen winkel |
| Feeds, sitemaps | Korte max-age of ETag-revalidatie |
In WordPress wijzigen plug-ins headers zonder coördinatie - controleer het wp_headers-filter en vergelijk wat nginx, PHP-FPM en de CDN retourneren. Een paginacache-plug-in kan conflicteren met een minificatie-plug-in die bestandsnamen wijzigt.
Voor implementatie en invalidatie kunt u deze lezing vergelijken met HTTP/2 en multiplexing: minder verbindingen compenseren niet voor slecht in de cache opgeslagen assets.
Opschonen, implementeren en klassieke fouten
Bij elke audit komen drie fouten terug:
- Vergeet het opschonen van CDN na HTML-implementatie zonder vingerafdrukken: de bezoeker ziet urenlang de oude versie.
Cache-Control: max-age=0zonderno-store— variabel gedrag afhankelijk van de CDN; toch een winkel.- Cookies op assets —
Set-Cookieop een statisch bestand kan edge-caching blokkeren.
Test systematisch met curl -I vanaf de CDN-rand en vanaf de oorsprong. De headers moeten identiek zijn of het verschil moet worden gedocumenteerd (TLS-beëindiging naar CDN, compressie, enz.).
Vergelijk aanbiedingen met geïntegreerde CDN via onze overzicht en de vergelijker — sommige hosts leggen standaardregels op die u moet kennen voordat u deze implementeert.
De bovenkant: CDN ingeschakeld, niets cachebaar
Dit is wat het selectievakje ‘CDN ingeschakeld’ in het paneel niet zegt.
Om de drie lagen te laten samenwerken, betekent dit dat je accepteert dat elk bestandstype zijn eigen beleid heeft – en niet een globale “cache aan”-instelling.
Beslis en ga vooruit zonder blinde vlek
In een halve dag kun je de cache weer gezond maken:
- Teken een matrix bron → richtlijn (
Cache-Control,Vary, duur) en deel deze met het team. - Vingerafdruk statische items (hash in naam) voor lange looptijden zonder blind opschonen.
- Controleer de Vary-headers als u over compressie of afbeeldingsindeling onderhandelt.
- Test met
krul -Ivanaf rand en oorsprong — documenteer verwachte afwijkingen. - Plan een gerichte opschoning voor elke HTML-implementatie, nooit een “opschoning van alles” zonder een rollback-wachtrij.
- Vergelijk hosts met CDN via de overzicht als u migreert of opnieuw onderhandelt over uw stack.
Voor een snelle controle gebruikt u een HTML-URL en een JS-bestand. De headers moeten consistent zijn in alle drie de lagen. Als je al host bij een Europese speler, raadpleeg dan hun profiel op Hébergeurs.eu om de standaard CDN-regels te achterhalen.
Veelgestelde vragen
openbaar versus privé versus geen winkel?
Met 'public' kan het CDN het antwoord voor alle bezoekers in de cache opslaan. 'privé' beperkt de opslag tot de browser van de gebruiker - geschikt voor accountpagina's. 'no-store' verbiedt elke opslag, ook in het geheugen, van gevoelige gegevens. Met no-cache is opslag mogelijk, maar vereist hervalidatie vóór gebruik.
max-leeftijd en s-maxage?
max-age is van toepassing op de browser; s-maxage naar gedeelde caches zoals CDN. Op een asset met versiebeheer (/app.abc123.js) vermijdt een lange max-age in combinatie met onveranderlijk onnodige verzoeken. Dynamische HTML verdient een korte duur of systematische hervalidatie.
Hoe ongeldig maken na implementatie?
Fingerprint de bestanden (hash in de naam), purgeer de CDN gericht op de betreffende URL’s of voeg een versieparameter toe. Vermijd het volledig opschonen van de productie zonder een rollback-plan; het kan de oorsprong verzadigen als al het verkeer terugkeert naar fouten.
ETag of laatst gewijzigd?
De ETag maakt nauwkeurige voorwaardelijke revalidatie mogelijk (304-respons zonder lichaam). Last-Modified werkt ook, maar de ETag op basis van een content-hash is betrouwbaarder in clusters. Pas op voor door machines gegenereerde ETags: deze maken hervalidatie ineffectief.
De effectieve cache wordt in de headers gelezen – niet in het CDN-selectievakje van het hostingpaneel.