CDN caching strategieën die webshops met hoge bezoekersdrukte echt schaalbaar maken

CDN caching strategieën die webshops met hoge bezoekersdrukte echt schaalbaar maken

De meeste webshopteams gaan ervan uit dat een CDN (content delivery netwerk, een wereldwijd verspreid netwerk van servers dat gecachte kopieën van je site dichter bij bezoekers serveert) hun prestatieproblemen oplost. Dat doet het niet, niet op zichzelf. Een CDN met slechte cache-instellingen verplaatst de knelpunten alleen maar dichter naar de gebruiker, terwijl de oorspronkelijke server tijdens een flash sale alsnog bezwijkt. Dit artikel behandelt de CDN caching strategieën die de serverbelasting echt verminderen, productpagina’s snel houden onder druk, en niet per ongeluk verouderde prijzen aan de verkeerde klant tonen.

Een CDN is geen prestatiestrategie. Het is infrastructuur. De strategie zit in alles wat je erin instelt.

Waarom de meeste CDN-instellingen voor webshops tegenvallen

De meeste CDN-instellingen voor webshops hebben een cache-trefferverhouding onder de 50%, wat betekent dat meer dan de helft van alle verzoeken nog steeds de oorspronkelijke server bereikt. Dat ondermijnt het hele doel. De oorzaak is meestal geen slechte CDN-keuze. Het zijn standaardinstellingen die onaangepast blijven, querystrings die de cache fragmenteren, en cookie-headers die het CDN dwingen elk verzoek als uniek te behandelen.

WooCommerce-webshops zijn hier bijzonder gevoelig voor. De WooCommerce-sessiecookie, die bij het eerste bezoek wordt ingesteld, geeft de meeste CDN-configuraties het signaal dat het verzoek gepersonaliseerd is en de cache volledig moet omzeilen. Op een webshop met 10.000 dagelijkse bezoekers kan dat betekenen dat 10.000 verzoeken de oorspronkelijke server bereiken voor pagina’s die voor 9.800 van die bezoekers identiek zijn.

De oplossing is niet ingewikkeld, maar vereist bewuste configuratie. Je moet per URL-patroon beslissen wat werkelijk gepersonaliseerd is en wat alleen gepersonaliseerd lijkt door een cookie die er niet zou moeten zijn.

Cloudflare-data uit 2023 liet zien dat webshops met correct geconfigureerde cacheregels 60 tot 70% minder verzoeken naar de oorspronkelijke server stuurden dan webshops met standaard CDN-instellingen. Het verschil is niet marginaal.

De vier CDN caching strategieën die er toe doen voor webshops

De vier strategieën die de meeste caching-behoeften van webshops afdekken zijn: statische bestandscaching, volledige paginacaching voor anonieme gebruikers, fragmentcaching voor dynamische secties, en stale-while-revalidate voor inhoud die regelmatig wijzigt. Elke strategie lost een ander probleem op, en het gebruik van slechts één ervan is de reden waarom de meeste instellingen tekortschieten.

Statische bestandscaching is de makkelijkste winst. Afbeeldingen, CSS, JavaScript, lettertypen: deze veranderen zelden en kunnen dagenlang of wekenlang op de edge (de geografisch verspreide servers van het CDN, ook wel edge nodes genoemd) worden gecached. Een TTL (time to live, de duur dat een gecachte kopie als geldig wordt beschouwd) van 30 dagen voor bestanden met een versienummer in de bestandsnaam is redelijk en gangbaar.

Volledige paginacaching voor anonieme gebruikers is waar de meeste webshopteams prestaties laten liggen. Een productpagina voor een niet-ingelogde bezoeker is identiek voor alle verzoeken. Cache het. De bezwaar is meestal “maar wat met de voorraadniveaus?”, wat een terechte zorg is, maar een zorg die wordt opgelost door cache-invalidatie, niet door de cache volledig over te slaan.

Fragmentcaching, soms edge-side includes of gedeeltelijke caching genoemd, laat je de statische schil van een pagina cachen terwijl specifieke secties dynamisch blijven. De productomschrijving wordt gecached. De voorraadindicator niet. Dit vereist meer instelling maar loont op drukke productpagina’s.

Stale-while-revalidate is een cache-control-instructie die het CDN vertelt een licht verouderde gecachte kopie te serveren terwijl op de achtergrond een nieuwe wordt opgehaald. Voor categoriepagina’s die een paar keer per dag worden bijgewerkt, is dit de juiste afweging. De gebruiker krijgt een snelle reactie. De cache vernieuwt zich zonder zichtbare vertraging.

Beslisbox

• Geschikt als: je webshop veel anoniem verkeer heeft, productpagina’s weinig veranderen, en er een duidelijke scheiding is tussen statische en gepersonaliseerde inhoud
• Minder geschikt als: elke pagina sterk gepersonaliseerd is, prijzen per gebruiker in realtime veranderen, of je platform geen aanpassing van cache-control-headers ondersteunt
• Waarschijnlijk overbodig als: je minder dan 5.000 maandelijkse bezoekers hebt en een publiek in één regio, waarbij een goed geconfigureerde oorspronkelijke server de belasting aankan zonder CDN-laag

Cache-invalidatie zonder kapotte productpagina’s

Cache-invalidatie, het proces waarbij je het CDN vertelt een gecachte kopie te verwijderen en een nieuwe op te halen, is waar de meeste caching-strategieën voor webshops mislopen. Het meest voorkomende faalpatroon is óf te agressief invalideren (wat je cache-trefferverhouding vernietigt) óf helemaal niet invalideren (wat verouderde prijzen of uitverkochte producten toont).

De praktische aanpak is op tags gebaseerde invalidatie. Je kent cachetags toe aan pagina’s op basis van de gegevens die ze bevatten. Een productpagina voor artikel SKU-4421 krijgt de tag “product-4421”. Wanneer de prijs of voorraad van dat product verandert, verwijder je alleen de pagina’s met de tag “product-4421”. Cloudflare Cache Tags en de surrogaatsleutels van Fastly ondersteunen dit patroon beide.

Bij projecten met grote productcatalogi is de verleiding groot om hele categorieën te verwijderen wanneer één product verandert. Dat is meestal onnodig en kostbaar in termen van opwarmtijd van de cache. Gedetailleerde op tags gebaseerde verwijdering houdt de cache warm voor de 99% producten die niet zijn gewijzigd.

Bij maatwerk webshop ontwikkeling bespaart het vanaf het begin inbouwen van invalidatiehaken in de productupdateworkflow aanzienlijk nawerk later. Cache-invalidatie achteraf inpassen in een platform dat er niet voor ontworpen is, is een van die taken die altijd drie keer langer duurt dan geschat.

Een patroon dat de moeite waard is om te kennen: als je platform geen op tags gebaseerde verwijdering ondersteunt, geeft een korte TTL (60 tot 300 seconden) gecombineerd met stale-while-revalidate een redelijke terugvaloptie. Je accepteert licht verouderde gegevens in ruil voor een cache die warm blijft.

Gepersonaliseerde inhoud en winkelwagen correct cachen

Gepersonaliseerde inhoud en de winkelwagenstatus mogen niet op CDN-niveau worden gecached. Dat is het directe antwoord, en ook waar de nuance zit. Het doel is niet alles te cachen. Het is zo veel mogelijk cachen terwijl de gepersonaliseerde onderdelen echt dynamisch blijven.

De standaardaanpak is de pagina op te splitsen in een cacheerbare schil en een dynamisch fragment. De schil, met de headeropmaak, navigatiestructuur, productomschrijving en voettekst, wordt op de edge gecached. Het winkelwagenaantal, de gebruikersbegroeting en gepersonaliseerde aanbevelingen worden na het laden van de pagina aan de clientzijde opgehaald via een aparte API-aanroep.

Dit patroon wordt soms “cache then hydrate” genoemd. De gebruiker ziet een snelle paginalaadtijd omdat de schil vanaf de edge wordt geserveerd. De gepersonaliseerde elementen verschijnen een fractie van een seconde later, geladen via JavaScript. Voor de meeste webshop-gebruikssituaties is dit niet merkbaar.

Het winkelwagen-eindpunt zelf mag nooit worden gecached. Het moet altijd de oorspronkelijke server bereiken. Hetzelfde geldt voor betaalpagina’s, accountpagina’s en elke URL die sessiespecifieke gegevens bevat. Stel je CDN in om de cache voor deze URL-patronen expliciet te omzeilen, niet per ongeluk.

Iets wat teams regelmatig verrast: sommige CDN’s cachen een 302-omleidingsreactie als je niet oplet. Als je inlogomleiding of winkelwagomleiding op de edge wordt gecached, breng je een ongemakkelijke middag door met uitleggen aan een klant waarom anonieme bezoekers naar iemand anders zijn accountpagina worden gestuurd.

TTL-instellingen en cache-control headers: wat je instelt en waarom

Cache-control headers zijn de instructies die je server naar het CDN (en naar browsers) stuurt over hoe lang een gecachte kopie bewaard moet worden. Deze verkeerd instellen is de meest voorkomende oorzaak van zowel verouderde inhoud als een slechte cache-trefferverhouding. Dat zijn tegengestelde problemen veroorzaakt door dezelfde verkeerde configuratie.

Een redelijk startpunt voor webshops:

• Versioned statische bestanden (CSS, JS met hash in bestandsnaam): Cache-Control: public, max-age=2592000 (30 dagen)
• Productafbeeldingen: Cache-Control: public, max-age=604800 (7 dagen), met CDN-verwijdering bij update
• Productpagina’s (anoniem): Cache-Control: public, s-maxage=300, stale-while-revalidate=60 (5 minuten op de edge, verouderd serveren gedurende 60 seconden tijdens vernieuwen)
• Categoriepagina’s: Cache-Control: public, s-maxage=600, stale-while-revalidate=120
• Winkelwagen, betaalpagina’s, accountpagina’s: Cache-Control: private, no-store

De s-maxage-instructie geldt specifiek voor gedeelde caches zoals CDN’s, terwijl max-age geldt voor zowel CDN’s als browsers. Met s-maxage kun je een kortere CDN-TTL instellen voor frequente vernieuwingen terwijl je een langere browsercache behoudt voor terugkerende bezoekers, wat handig is voor productpagina’s die af en toe veranderen.

Volgens het HTTP Archive Web Almanac 2023 wordt ongeveer 27% van de cachebare webshop-reacties geserveerd zonder enige cache-control header, waardoor het CDN moet raden. CDN’s zijn niet goed in raden. Ze cachen alles of niets, en geen van beide uitkomsten is wat je wilt.

De vary-header is een andere veelvoorkomende bron van verwarring. Als je server Vary: Cookie stuurt op productpagina’s, maakt het CDN een aparte cache-invoer voor elke unieke cookiecombinatie. Op een WooCommerce-webshop betekent dat vrijwel geen caching. Verwijder de vary-header voor pagina’s die je wilt cachen, en verwerk personalisatie aan de clientzijde.

CDN caching in productie draaien zonder verrassingen

CDN caching in productie draaien zonder verrassingen vereist dat je cache-configuratie behandelt als een volwaardig onderdeel van je implementatieproces, niet als een bijzaak. Het meest voorkomende productie-incidentpatroon is een implementatie die sjablonen of prijzen bijwerkt maar geen cache-invalidatie activeert, waardoor het CDN uren lang de oude versie serveert.

Bouw cache-verwijderingsstappen in je implementatiepijplijn. Wanneer een nieuwe versie van een sjabloon wordt geïmplementeerd, verwijder dan automatisch de relevante cachetags of URL-patronen. Wanneer een productprijs in het CMS wordt bijgewerkt, moet de webhook die de wijziging opslaat ook het verwijderingsverzoek sturen. Dit zijn geen complexe integraties, maar ze moeten worden ontworpen, niet achteraf worden toegevoegd.

Testomgevingen zijn een andere valkuil. Teams testen cachinggedrag op een testomgeving waar het CDN vaak anders is geconfigureerd of volledig uitgeschakeld, en ontdekken na implementatie in productie dat de cache zich heel anders gedraagt dan verwacht. Test cache-control headers in productie met een klein percentage verkeer voordat je volledig uitrolt.

Wat je maandelijks checkt

• Cache-trefferverhouding per URL-patroon: streef naar boven de 80% voor product- en categoriepagina’s
• Verzoekvolume naar de oorspronkelijke server: een plotselinge piek betekent meestal een gebroken cache-configuratie, geen verkeerspiek
• Tijd tot eerste byte (TTFB) vanaf edge nodes: moet onder de 100ms liggen voor gecachte reacties
• Verwijderingslatentie: hoe lang duurt het tussen een productupdate en het serveren van de nieuwe versie door het CDN
• Foutpercentage op cache-omzeilingsroutes: winkelwagen- en betaaleindpunten mogen nul CDN-cachingfouten hebben

Eén observatie uit productiewerk: de eerste keer dat een team hun werkelijke cache-trefferverhouding bekijkt, is het getal bijna altijd lager dan iedereen verwachtte. Een verhouding van 30 tot 40% is gangbaar op webshops die ervan uitgingen dat ze “een CDN gebruikten.” Dat getal boven de 75% krijgen kost doorgaans één gerichte sprint aan configuratiewerk, geen platformmigratie.

CDN caching strategieën voor webshops gaan niet over het kiezen van de juiste CDN-aanbieder. Ze gaan over cache-trefferverhouding, TTL-configuratie en invalidatielogica. Volgens Cloudflare-prestatiedata uit 2023 verminderen correct geconfigureerde cacheregels de verzoeken naar de oorspronkelijke server met 60 tot 70% vergeleken met standaardinstellingen. Studio Ubique bouwt en configureert webshopplatforms waarbij caching vanaf het begin deel uitmaakt van de architectuur, niet wordt toegevoegd na het eerste verkeersincident.

Veelgestelde vragen

Wat is een goede cache-trefferverhouding voor een webshop?

Een cache-trefferverhouding boven de 80% voor product- en categoriepagina’s is een redelijk doel voor de meeste webshops met veel anoniem verkeer. Onder de 60% betekent meestal dat querystring-fragmentatie, op cookies gebaseerde cache-omzeiling, of ontbrekende cache-control headers de CDN-configuratie ondermijnen.

Kan ik WooCommerce-productpagina’s cachen met een CDN?

Ja, maar je moet de WooCommerce-sessiecookie voor anonieme gebruikers verwijderen of negeren voordat het CDN productpagina’s zal cachen. De meeste CDN-aanbieders laten je cookie-negeringsregels per URL-patroon instellen. Zonder deze stap behandelt het CDN elke anonieme bezoeker als een unieke sessie en omzeilt de cache volledig.

Hoe vaak moet ik mijn CDN-cache verwijderen bij productupdates?

Verwijder bij wijziging, niet op schema. Gebruik op tags of sleutels gebaseerde invalidatie zodat alleen de pagina’s met het bijgewerkte product worden verwijderd. Geplande volledige cache-verwijderingen zijn een bot instrument dat langzaam opwarmt en je oorspronkelijke server blootstelt tijdens de opwarmperiode.

Wat is het verschil tussen max-age en s-maxage in cache-control headers?

max-age geldt voor zowel browsers als gedeelde caches zoals CDN’s. s-maxage geldt alleen voor gedeelde caches en overschrijft max-age voor CDN’s. Met s-maxage kun je een korte CDN-TTL instellen voor frequente vernieuwingen terwijl je een langere browsercache behoudt voor terugkerende bezoekers, wat handig is voor productpagina’s die af en toe veranderen.

Mogen winkelwagen- en betaalpagina’s ooit door een CDN worden gecached?

Nee. Winkelwagen- en betaalpagina’s bevatten sessiespecifieke gegevens en moeten altijd vanaf de oorspronkelijke server worden geserveerd. Stel je CDN in om de cache voor deze URL-patronen expliciet te omzeilen met Cache-Control: private, no-store, en controleer of de omzeiling werkt in productie, niet alleen in de testomgeving.