“Zet er een CDN op, dan wordt het sneller.” Het is een advies dat wij ondernemers regelmatig horen herhalen, meestal overgenomen van een snelheidstool, een hostingpartij of een artikel dat voor een Amerikaans publiek is geschreven. Het klinkt logisch: een netwerk van servers over de hele wereld dat uw website dichter bij de bezoeker brengt.

Maar uw bezoeker zit in Zwolle en uw server staat in Amsterdam. Die afstand is ongeveer 100 kilometer. Ons standpunt, kort samengevat: een CDN voor WordPress is voor de meeste Nederlandse bedrijfswebsites geen snelheidsmaatregel, maar kan om andere redenen wel degelijk verstandig zijn. Hieronder de argumenten.

Wat een CDN doet, en waarom afstand hier nauwelijks telt

Een content delivery network bewaart kopieën van uw statische bestanden (afbeeldingen, CSS, JavaScript, lettertypen) op servers verspreid over de wereld. Een bezoeker uit Sydney krijgt die bestanden dan van een server in Sydney in plaats van uit Amsterdam. Dat scheelt honderden milliseconden per bestand, en dat telt op.

Voor een bezoeker uit Zwolle, met een server in Amsterdam, is die winst er niet. De vertraging door afstand binnen Nederland is enkele milliseconden. Een CDN-server in Amsterdam of Frankfurt is niet dichterbij dan uw eigen hosting. Als uw site traag is, ligt dat vrijwel nooit aan die paar kilometer. Het ligt aan de tijd die de server nodig heeft om de pagina op te bouwen, aan te grote afbeeldingen, aan te veel scripts. Een CDN lost daar niets van op.

In onze ervaring ziet u bij een Nederlandse site op Nederlandse hosting na het inschakelen van een CDN meestal geen meetbaar verschil in laadtijd voor Nederlandse bezoekers. Soms wordt het zelfs een fractie trager, omdat er een extra tussenstap bij komt.

Wanneer een CDN wél snelheidswinst oplevert

Er zijn uitzonderingen, en die zijn belangrijk genoeg om eerlijk te benoemen:

  • Uw hosting staat niet in Nederland. Goedkope hosting draait soms op servers in de Verenigde Staten of elders. Dan haalt een CDN de statische bestanden wél dichterbij.
  • U heeft internationale bezoekers. Verkoopt u aan klanten in Spanje, Duitsland of daarbuiten? Dan profiteren die bezoekers direct.
  • Uw hosting is zwak. Als de server moeite heeft met het uitleveren van veel afbeeldingen, neemt een CDN dat werk over. Dat is eigenlijk een pleister op een hostingprobleem, maar soms een praktische.
  • U gebruikt een CDN met paginacaching aan de rand. Diensten zoals Cloudflare kunnen hele pagina’s cachen op hun servers. Dan wordt niet alleen het plaatje, maar de complete pagina zonder tussenkomst van WordPress uitgeleverd. Dat is wel merkbaar, ook in Nederland, maar het vereist zorgvuldige instellingen.

De redenen die niets met snelheid te maken hebben

Hier wordt ons standpunt genuanceerder. Wij adviseren regelmatig een CDN, maar dan vrijwel nooit vanwege de laadtijd. De argumenten zijn andere:

Bescherming. Een CDN staat tussen de buitenwereld en uw server. Kwaadaardig verkeer, botaanvallen en pogingen om uw loginpagina te overbelasten worden daar al afgevangen. Bij een DDoS-aanval is dat het verschil tussen een site die online blijft en een site die uren onbereikbaar is.

Ontlasting bij pieken. Wordt uw site genoemd in een landelijk programma of gaat een actie viraal? Dan vangt het CDN een groot deel van het verkeer op. Uw server hoeft alleen nog de dynamische onderdelen te verzorgen.

Extra functies. Veel CDN-diensten bieden gratis SSL, automatische beeldoptimalisatie, HTTP/3, een firewall met regels en DNS-beheer. Voor sommige sites is dat pakket handiger dan losse plugins.

Hoe Cloudflare die combinatie van bescherming en snelheid precies invult, en wat u moet instellen om geen problemen met WordPress te krijgen, leest u in ons artikel over Cloudflare voor WordPress.

De nadelen die zelden worden genoemd

Een CDN is niet gratis, ook niet als het gratis is. U voegt een extra partij toe aan de keten. Als die partij een storing heeft, ligt uw site eruit terwijl uw eigen server prima werkt. Dat is de afgelopen jaren bij de grote aanbieders meermaals gebeurd.

Verder zijn er praktische valkuilen. Cache die niet wordt geleegd na een wijziging, waardoor bezoekers oude CSS zien. Firewallregels die iDEAL-terugmeldingen of een koppeling met een boekhoudpakket blokkeren. Een “Rocket Loader”-achtige functie die JavaScript herschikt en formulieren breekt. Wie een CDN inschakelt zonder zijn site daarna grondig te testen, ruilt een niet-bestaand snelheidsprobleem in voor een echt functioneel probleem.

En de AVG. Een CDN verwerkt het IP-adres van elke bezoeker. Dat vraagt om een verwerkersovereenkomst en een vermelding in uw privacyverklaring. Bij een Amerikaanse aanbieder speelt ook de vraag waar de gegevens worden verwerkt. Het is geregeld te regelen, maar het is wel iets wat u moet regelen.

Wat wij zelf adviseren

Een fictief maar herkenbaar geval: een accountantskantoor in Utrecht vroeg ons om een CDN in te schakelen omdat een tool dat als verbeterpunt aangaf. Bij het meten bleek de site 4,2 seconden nodig te hebben voor de eerste weergave, waarvan 2,8 seconden wachten op de server. Een CDN zou daar niets aan veranderen. Na het aanpassen van de caching en het verkleinen van de afbeeldingen zat de site onder de 1,5 seconden. Zonder CDN. Dat is de volgorde die wij bij vrijwel elke snelheidsoptimalisatie aanhouden: eerst de oorzaken bij de bron aanpakken, daarna pas kijken of een CDN nog iets toevoegt.

Waar wij wel meteen ja zeggen: webshops met piekverkeer, sites die eerder aangevallen zijn, en sites met een internationaal publiek. Daar is een CDN geen snelheidsmaatregel maar een verzekering, en een goedkope ook.

Conclusie

Verwacht van een CDN geen snellere website als uw bezoekers en uw hosting allebei in Nederland zitten. De winst zit in bescherming, stabiliteit bij drukte en soms in handige extra’s. Weeg dat af tegen de extra afhankelijkheid en het instelwerk. Twijfelt u? Meet dan eerst waar de vertraging van uw site vandaan komt. Ons artikel over de meest voorkomende oorzaken van een trage website helpt u die vraag te beantwoorden voordat u iets toevoegt.