Een CDN en caching kunnen ervoor zorgen dat websitebestanden sneller laden, maar ze doen dat op verschillende manieren. Je leest hoe verzoeken en bestanden worden opgeslagen, hoe je verouderde inhoud ververst en wanneer caching juist problemen kan veroorzaken.

Hoe een CDN websitebestanden dichter bij bezoekers brengt

Een browser vraagt een webpagina normaal gesproken op bij de server waarop de website draait. Staat die server in Nederland en bevindt de bezoeker zich aan de andere kant van de wereld, dan leggen gegevens een grotere afstand af. Een Content Delivery Network, meestal afgekort tot CDN, verspreidt kopieën van geschikte bestanden over servers op verschillende locaties. Zo kan een bezoeker bijvoorbeeld een afbeelding ophalen bij een server in de buurt, in plaats van bij de oorspronkelijke server van de website.

De oorspronkelijke server heet vaak de origin. Een CDN gebruikt onder meer de locatie van de bezoeker en beschikbare netwerkverbindingen om een geschikte edge-server te kiezen. Als het bestand daar al staat, kan het CDN het direct leveren. Is het nog niet opgeslagen, dan haalt de edge-server het meestal eerst bij de origin op. Daarna kan het bestand tijdelijk op die locatie worden bewaard voor volgende verzoeken.

Een CDN verkleint niet letterlijk een afbeelding en maakt ook geen trage applicatiecode vanzelf snel. Het kan wel de afstand en belasting voor veel statische bestanden verminderen. Denk aan afbeeldingen, stylesheets, JavaScript-bestanden en lettertypen. De precieze winst hangt af van de locatie van bezoekers, de cache-instellingen en de tijd die de origin nodig heeft om bestanden aan te leveren.

Wat caching doet in de browser, op de server en bij het CDN

Bij caching wordt een kopie van een bestand tijdelijk bewaard, zodat die niet bij ieder verzoek opnieuw hoeft te worden opgebouwd of opgehaald. Dat gebeurt op verschillende plaatsen. De browser kan bestanden op het apparaat van de bezoeker opslaan. Een CDN kan kopieën bewaren op zijn edge-servers. Ook een webserver, applicatie of database kan resultaten tijdelijk vasthouden. Die lagen hebben ieder hun eigen regels en levensduur.

Browsercaching scheelt herhaalde downloads bij dezelfde bezoeker. CDN-caching helpt juist wanneer veel bezoekers hetzelfde bestand opvragen. Applicatiecaching kan bijvoorbeeld een berekende productlijst of een databasequery hergebruiken, zodat de website minder vaak dezelfde bewerkingen uitvoert. Een cache-hit betekent dat een bruikbare kopie wordt gevonden; bij een cache-miss moet de betreffende laag het bestand alsnog ophalen of opnieuw berekenen.

Meer caches betekenen niet automatisch een snellere of betere website. Als een bestand op meerdere plekken wordt bewaard, kan een wijziging langer nodig hebben om overal zichtbaar te worden. Bovendien kan een cache op de ene laag een verouderde kopie teruggeven terwijl een andere laag al is bijgewerkt. Beheer vraagt daarom om te weten welke laag welk type inhoud bewaart, hoe lang dat gebeurt en hoe een wijziging door de verschillende lagen heen wordt verwerkt.

Cache-Control en TTL: bepalen hoe lang bestanden geldig blijven

De HTTP-header Cache-Control geeft browsers en tussenliggende caches aanwijzingen over het bewaren van een reactie. Een instelling als max-age bepaalt hoelang een kopie volgens de ingestelde tijd nog vers is. Die periode wordt ook wel de TTL genoemd: time to live. Een lange TTL past vaak bij een afbeelding of stylesheet waarvan de URL verandert zodra de inhoud verandert. Voor een pagina met actuele voorraad of persoonlijke gegevens is zo’n lange periode meestal riskanter.

Headers als public en private helpen aangeven of een reactie door gedeelde caches mag worden opgeslagen of alleen door de browser van een individuele bezoeker. no-store vraagt caches om de reactie niet op te slaan. no-cache betekent niet simpelweg “bewaar niets”: een kopie mag worden opgeslagen, maar moet vóór hergebruik opnieuw worden gecontroleerd. De precieze ondersteuning en interpretatie kunnen per cachelaag verschillen.

Een veelvoorkomende fout is één lange cacheduur instellen voor alles. Pagina’s, afbeeldingen en API-reacties hebben niet dezelfde actualiteitseisen. Stel de regels per inhoudstype in en controleer welke headers de server werkelijk verstuurt. De instellingen in een beheerpaneel zeggen niet altijd wat uiteindelijk in de HTTP-respons terechtkomt. Ook CDN-regels kunnen headers aanpassen of overschrijven, waardoor browser en edge-server verschillende bewaartermijnen hanteren.

Bestandsnamen met versies voorkomen problemen met oude bestanden

Een browser kan een stylesheet of script terecht als vers beschouwen zolang de ingestelde cacheduur niet is verstreken. Pas je intussen de inhoud aan, maar blijft de URL hetzelfde, dan kan een bezoeker nog de oude versie gebruiken. Dat kan leiden tot ontbrekende opmaak, foutmeldingen in JavaScript of een pagina die niet goed samenwerkt met de nieuwe versie van de website. Alleen opnieuw publiceren is dus niet altijd voldoende om een wijziging zichtbaar te maken.

Een gangbare oplossing is versiebeheer in de bestandsnaam of URL. Een bestand kan bijvoorbeeld een gegenereerde hash in de naam krijgen. Verandert de inhoud, dan verandert ook de URL. De browser en het CDN zien het nieuwe bestand daardoor als een andere bron en halen het opnieuw op. De oude versie kan vervolgens veilig in caches blijven staan totdat die vanzelf verloopt; bezoekers die de nieuwe pagina laden, krijgen de nieuwe bestandsnaam.

Deze aanpak werkt goed voor bestanden die tijdens publicatie worden opgebouwd, zoals CSS en JavaScript. Let wel op dat de HTML-pagina zelf naar de juiste versies verwijst. Als juist die pagina lang gecachet blijft, kan zij nog steeds oude bestandsnamen bevatten. Ook bij afbeeldingen moet een publicatieproces rekening houden met verwijzingen vanuit contentmanagementsystemen, e-mails of externe pagina’s. Verander dus niet zomaar bestandsnamen zonder te controleren welke onderdelen ernaar verwijzen.

Verouderde CDN-cache verversen met gerichte invalidatie

Soms moet een wijziging zichtbaar worden voordat de ingestelde cacheduur is afgelopen. Een beheerder kan dan een cache purge uitvoeren: het CDN krijgt de opdracht om opgeslagen kopieën te verwijderen, zodat een volgend verzoek verse inhoud ophaalt bij de origin. Afhankelijk van de dienst kan dat voor één URL, een map, een patroon of de volledige cache. Een gerichte purge is meestal veiliger en efficiënter dan alles wissen.

Een volledige purge kan tijdelijk juist extra belasting veroorzaken. Na het verwijderen van veel kopieën krijgen edge-servers bij nieuwe verzoeken cache-misses en vragen ze de bestanden opnieuw op bij de origin. Bij veel gelijktijdige bezoekers kan dat leiden tot tragere reacties of een piek in serverbelasting. Sommige CDN’s bieden daarom mogelijkheden om bestanden vooraf op te warmen of vernieuwing geleidelijk uit te voeren.

Invalidatie heeft bovendien grenzen. Als een browser een bestand lokaal heeft opgeslagen met een lange geldigheidsduur, kan een purge bij het CDN die lokale kopie niet altijd wissen. Als er meerdere lagen zijn, moet de wijziging mogelijk ook in een applicatiecache of reverse proxy worden verwerkt. Controleer daarom na een purge de betreffende URL en responseheaders, bijvoorbeeld of er een nieuwe bestandversie wordt geleverd en of de CDN-status op een cache-miss of nieuwe cache-hit wijst. Zonder die controle is onduidelijk welke laag nog oude inhoud serveert.

Waarom persoonlijke pagina’s niet zomaar gecachet mogen worden

Een gedeelde CDN-cache is vooral effectief wanneer veel bezoekers dezelfde reactie mogen ontvangen. Dat geldt vaak voor een logo of een openbare productafbeelding. Een ingelogde bezoeker kan daarentegen persoonlijke gegevens, een eigen winkelmandje, een accountnaam of afwijkende prijzen zien. Als een gedeelde cache zo’n reactie opslaat zonder de verschillen goed mee te wegen, bestaat het risico dat een andere bezoeker inhoud van de eerste gebruiker te zien krijgt.

De cache key bepaalt welke kenmerken van een verzoek worden gebruikt om opgeslagen reacties van elkaar te onderscheiden. Een URL is vaak een belangrijk onderdeel, maar cookies, queryparameters of bepaalde headers kunnen ook invloed hebben. Hoe meer varianten worden meegenomen, hoe kleiner de kans op vermenging, maar ook hoe minder vaak dezelfde cachekopie herbruikbaar is. Sommige CDN-regels negeren cookies standaard voor betere cacheprestaties. Dat kan onveilig zijn als de pagina inhoudelijk van die cookies afhangt.

Maak daarom onderscheid tussen openbare en persoonlijke onderdelen. Een pagina kan bijvoorbeeld grotendeels uit cachebare productinformatie bestaan, terwijl winkelmandje of accountgegevens apart en dynamisch worden geladen. Controleer daarnaast dat privéreacties passende headers hebben en dat CDN-regels die niet alsnog als gedeelde inhoud opslaan. Test niet alleen als beheerder, maar ook met verschillende accounts en een uitgelogde sessie. Zo worden fouten zichtbaar die bij één browser of één testgebruiker verborgen blijven.

Wanneer caching minder geschikt is voor actuele of veranderlijke inhoud

Niet iedere vertraging los je op door meer inhoud te cachen. Bij informatie die snel verandert, kan een lange bewaartermijn bezoekers een onjuist beeld geven. Denk aan voorraadstatus, bezorgopties, actuele prijzen, evenementtickets of financiële gegevens. Hoe groot dat risico is, hangt af van de gevolgen van een verouderde waarde. Een oude afbeelding is meestal minder ingrijpend dan een product als beschikbaar tonen terwijl het al is uitverkocht.

Voor dit soort informatie zijn er verschillende keuzes. Je kunt de betreffende reactie niet cachen, een korte TTL gebruiken of de pagina opdelen in cachebare en dynamische onderdelen. Een voorraadindicatie kan bijvoorbeeld afzonderlijk worden opgehaald, terwijl productbeschrijvingen en afbeeldingen langer meegaan. Dat maakt de implementatie complexer: de browser moet onderdelen combineren, en de pagina moet ook bruikbaar blijven wanneer een aparte aanvraag traag is of mislukt.

Ook technisch kan caching minder opleveren. Een unieke URL per bezoeker, veel queryvarianten of sterk gepersonaliseerde reacties zorgen ervoor dat weinig verzoeken dezelfde cachekopie kunnen delen. Dan voegen beheer en foutopsporing mogelijk meer werk toe dan de cache bespaart. Caching kan daarnaast verbergen dat de origin structureel te langzaam is: een cache-miss blijft dan traag. Beoordeel daarom zowel de snelheid bij herhaalde verzoeken als de prestaties wanneer een bestand nog niet in de cache staat.

Cacheprestaties controleren met headers en echte verzoeken

Om te weten of caching werkt, is alleen een snelle laadervaring op je eigen computer niet genoeg. De browser kan bestanden al lokaal hebben opgeslagen, terwijl een nieuwe bezoeker ze nog bij de server moet ophalen. Test daarom met een lege browsercache en vergelijk dat met een herhaald bezoek. Kijk ook naar verschillende locaties als bezoekers verspreid over meerdere landen zitten. Een CDN kan op de ene plek een kopie hebben, terwijl een andere edge-server het bestand nog bij de origin moet ophalen.

Responseheaders geven aanwijzingen over het gedrag. Let onder meer op Cache-Control, Age, ETag en eventuele CDN-specifieke statusheaders. Een oplopende Age-waarde kan bijvoorbeeld laten zien dat een gedeelde cache een reactie al een tijd bewaart. Een status als HIT of MISS is afhankelijk van de CDN-aanbieder, maar helpt vaak vaststellen of een verzoek uit de cache kwam. Vergelijk bij problemen ook de headers van de origin met die van de uiteindelijke reactie.

Meet niet alleen de totale laadtijd. Kijk naar wachttijd tot de eerste byte, bestandsgrootte, cache-hitratio en belasting op de origin. Een hoge hitratio zegt op zichzelf weinig als juist de belangrijkste pagina’s vaak een miss hebben. Controleer na wijzigingen bovendien foutscenario’s: werkt een pagina nog als de CDN-cache leeg is, en wordt een nieuwe versie na publicatie daadwerkelijk opgehaald? Dat maakt zichtbaar of de ingestelde cache niet alleen snel, maar ook betrouwbaar is.