Wat is een CDN en heeft je website er een nodig?

Een CDN (content delivery network) is een netwerk van servers op veel locaties dat kopieën van de bestanden van je website bewaart en die aan bezoekers levert vanaf een server bij hen in de buurt, in plaats van elk verzoek naar je eigen hosting te sturen. De meeste openbare websites met bezoekers uit meer dan één regio, of met pieken in het verkeer, hebben er baat bij. Een CDN lost trage code of zware pagina's niet vanzelf op, dus het is handig om te weten wat het precies doet voordat je er een inzet.

Zo werkt een CDN

Zonder CDN praat elke bezoeker rechtstreeks met je origin-server: de machine bij je hostingprovider waarop je site draait. Staat die server in Frankfurt en zit de bezoeker in Sydney, dan reist elk verzoek de wereld rond en weer terug. En komen er duizend mensen tegelijk binnen, dan moet de origin ze allemaal zelf beantwoorden.

Met een CDN worden bezoekers in plaats daarvan naar een edge-server gestuurd. Die edge zit tussen de bezoeker en je origin en werkt grofweg zo:

1. Een bezoeker vraagt een pagina of bestand op.
2. DNS stuurt hem naar een edge-server in de buurt.
3. Heeft de edge al een verse kopie, dan antwoordt hij meteen. Dat heet een cache hit.
4. Zo niet, dan haalt de edge het bestand op bij je origin, levert het af en bewaart een kopie voor de volgende bezoeker. Dat heet een cache miss.

Het eerste verzoek voor een bestand is dus niet sneller dan voorheen. Maar elk volgend verzoek voor hetzelfde bestand, van wie dan ook in de buurt van die edge, kan worden beantwoord zonder dat je origin eraan te pas komt. Daar komen zowel de snelheidswinst als de ontlasting van je server vandaan.

Wat een CDN cachet (en wat niet)

Een CDN bepaalt wat het opslaat op basis van de response-headers van je origin, vooral Cache-Control, plus eventuele regels die je zelf instelt. In de MDN-referentie voor Cache-Control (Engelstalig) zoek je directives als max-age, s-maxage, private en no-store het beste op.

Veilig om te cachen

• Afbeeldingen, CSS, JavaScript en webfonts
• Openbare HTML-pagina's die er voor elke bezoeker hetzelfde uitzien: blogposts, landingspagina's en in de meeste webshops ook categorie- en productpagina's
• Downloads zoals pdf's

Moet de cache omzeilen

• Winkelwagens, checkout en betaalpagina's
• Accountomgevingen en alles wat ingelogde gebruikers te zien krijgen
• Pagina's met persoonsgegevens, formuliertokens of prijzen per klant
• Beheeromgevingen zoals /wp-admin

Deze verdeling goed krijgen is belangrijker dan welke andere CDN-instelling ook. Een CDN dat een ingelogde pagina cachet, kan de gegevens van de ene klant aan een andere laten zien. Goed gebouwde CMS- en webshopsystemen markeren zulke antwoorden als privé of zetten cookies die een CDN als signaal gebruikt om de cache te omzeilen. Heb je een webshop, dan laat de gids over WooCommerce sneller maken zien welke pagina's in welke groep horen.

Wat een CDN verbetert

Time to First Byte

Wordt een pagina vanuit een edge-cache geleverd, dan krijgt de bezoeker de eerste byte zonder te wachten op PHP, een databasequery of een trage host. Dat zie je terug in de TTFB (Engelstalig), waarvoor web.dev als vuistregel 0,8 seconden of minder aanbeveelt. Onze gids over TTFB verlagen behandelt de verbeteringen aan serverkant die een CDN aanvullen.

Afstand en latency

Elke round trip tussen browser en server kost tijd, en fysieke afstand maakt dat erger. Leveren vanaf een edge in de buurt maakt elke round trip korter, en dat telt op over de DNS-lookup, de TLS-handshake en de vele verzoeken die een pagina doet.

Belasting van je origin

Cache hits bereiken je server nooit. Tijdens een nieuwsbriefverzending, een uitverkoop of een vermelding op social media hoeft je hosting alleen cache misses en dynamische verzoeken te beantwoorden. Daardoor is de kans veel kleiner dat hij op piekmomenten trager wordt.

Beveiliging en beschikbaarheid

Omdat al het verkeer via de edge loopt, filteren veel CDN's daar ook aanvallen, handelen ze TLS af en blijven ze gecachete pagina's leveren als de origin even onbereikbaar is. Hoeveel je hiervan krijgt, hangt af van de aanbieder en het abonnement.

Wat een CDN niet kan oplossen

Een CDN is een leveringslaag. Het zorgt dat goede pagina's sneller aankomen, maar het kan een zware pagina niet licht maken.

• Trage dynamische pagina's. Checkout, zoekresultaten en ingelogde pagina's worden elke keer opnieuw gegenereerd. Zijn die traag, dan zit de oorzaak in je applicatie, database of hosting.
• Zware front-ends. Een hero-afbeelding van 4 MB of een stapel scripts van derden blijft 4 MB en moet nog steeds in de browser draaien. Dat zie je terug in LCP en INP, niet in de TTFB.
• Layout shift. CLS ontstaat door de manier waarop de pagina is opgebouwd, bijvoorbeeld afbeeldingen zonder afmetingen of banners die laat inladen.
• Een verkeerd ingestelde cache. Stuurt je origin op alles no-store mee, of zet elke pagina een sessiecookie, dan omzeilt het CDN de cache en win je weinig.

Ligt je probleem in een van deze punten, dan hoort de oplossing in de pagina of de applicatie. Een CDN blijft daarnaast nuttig, maar het is geen vervanging. De gids over Core Web Vitals legt uit welke meetwaarde naar welke oorzaak wijst.

Heeft je website een CDN nodig?

Een CDN is meestal de moeite waard als een of meer van deze punten voor jou gelden:

• Je bezoekers komen uit meer dan één land of werelddeel.
• Je TTFB is hoog voor openbare pagina's, vooral ver van je host vandaan.
• Je server heeft het zwaar of wordt trager bij pieken in het verkeer.
• Je draait een CMS of webshop waar de meeste bezoeken binnenkomen op pagina's die voor iedereen hetzelfde zijn.
• Je wilt DDoS-bescherming en HTTPS geregeld hebben vóór je hosting.

Het maakt minder uit als je site puur lokaal is, heel klein, al vanaf een snelle statische host dicht bij je publiek wordt geleverd, of bijna volledig gepersonaliseerd is (bijvoorbeeld een interne tool achter een login). In die gevallen levert betere hosting of het tunen van je applicatie misschien meer op dan een CDN.

Zo test je of het werkt

Meet eerst, voordat je iets aanzet. Haal een paar openbare pagina's door corewebvitals.page en noteer LCP en de andere meetwaarden, plus je gegevens van echte gebruikers als Google daar genoeg van heeft. De gids over websitesnelheid meten legt uit hoe je een eerlijke voor-en-navergelijking opzet.

Staat het CDN live, controleer dan de response-headers van een pagina die gecachet zou moeten worden. Vraag hem twee keer op:

curl -sI https://www.example.com/ | grep -i -E 'cache|age'

Het eerste verzoek is vaak een miss. Het tweede zou in de cacheheader van de aanbieder een hit moeten tonen, met een leeftijd (age) die oploopt. Blijft elk verzoek een miss of een bypass, kijk dan naar Cache-Control en Set-Cookie in het antwoord van je origin. Herhaal daarna je metingen vanaf verschillende locaties en vergelijk.

Zo helpt fast.site je

fast.site zit vóór je bestaande hosting, dus je houdt je host en je CMS. Je voegt je domein toe in het dashboard, zet je nameservers om naar fast.site en verifieert. De propagatie wordt automatisch gecontroleerd, en daarna beheert fast.site de DNS voor het domein.

Het cachen gebeurt met Fast Edge Cache™. Bij een miss haalt de edge de pagina op bij je origin en bewaart een kopie; bij een hit antwoordt hij zonder je server te benaderen. De vervaltijd volgt de Cache-Control-headers van je origin of je eigen regels, en winkelwagens, checkout en ingelogde sessies omzeilen de cache. De response-header fs-cache toont HIT, MISS of BYPASS, zodat je elke pagina zelf kunt controleren. Je kunt per URL purgen in het dashboard of via de API, en een cache warmer houdt belangrijke pagina's warm.

Bezoekers worden via GeoDNS naar de dichtstbijzijnde gezonde edge in Noord-Amerika, Europa, Azië-Pacific of Zuid-Amerika geleid, afhankelijk van je abonnement. Elk domein krijgt daarnaast automatische DDoS-detectie op Layer 7 en gratis SSL-certificaten die automatisch worden verlengd. De details vind je in de cachingdocumentatie en op de pagina met functies.

Meet je eigen site voor en na. Je kunt starten met een gratis proefperiode van 7 dagen, zonder creditcard. De abonnementen vergelijk je op de prijspagina.

Veelgestelde vragen

Vervangt een CDN mijn webhosting?

Nee. Je site staat nog steeds op je hosting, en die blijft de origin. Het CDN zit ervoor en levert gecachete kopieën, maar alles wat dynamisch is, zoals een checkout, wordt nog steeds door je server gegenereerd.

Is een CDN goed voor SEO?

Indirect wel. Google gebruikt signalen voor paginagebruik zoals de Core Web Vitals, en een CDN kan de laadtijd verbeteren, vooral de TTFB en daardoor vaak ook de LCP. Betere posities zijn niet gegarandeerd, want content en relevantie wegen veel zwaarder.

Kan een CDN mijn site juist trager maken?

Dat kan als het slecht is ingesteld. Omzeilt het CDN bijna elk verzoek, dan maakt elk verzoek een extra omweg via de edge naar je origin. Controleer na de installatie de cacheheaders en zorg dat openbare pagina's echt hits opleveren.

Heb ik een CDN nodig als al mijn bezoekers uit één land komen?

Voor de afstand niet per se, maar voor belasting en bescherming vaak nog wel. Staat je host dicht bij je publiek en vangt hij pieken goed op, dan is de winst kleiner. Wordt je server trager bij drukte, dan helpt edge caching nog steeds.

Maakt een CDN mijn webshop of loginpagina's kapot?

Niet als dynamische pagina's de cache omzeilen. Winkelwagen, checkout en accounts mogen nooit voor iedereen gecachet worden. Test deze flows na de installatie, ingelogd en uitgelogd, en controleer dat de cacheheader daar een bypass toont.