Stel je voor: een bezoeker uit Singapore opent je WordPress-site die op een server in Amsterdam draait. Het verzoek legt duizenden kilometers af, en elke milliseconde telt. Een CDN integratie met WordPress - specifiek Cloudflare - brengt je content dichter bij je bezoekers en kan je laadtijden drastisch verlagen. Maar een CDN inschakelen zonder het goed te configureren levert vaak meer problemen dan voordelen op.
In dit artikel duiken we diep in Cloudflare: hoe het werkt, hoe je het correct integreert met WordPress en welke instellingen het verschil maken tussen een halfbakken en een geoptimaliseerde setup. We bouwen voort op de kennis uit eerdere artikelen over full page caching en wat er tijdens een WordPress request gebeurt.
Wat doet een CDN precies?
Een Content Delivery Network is een netwerk van servers (edge nodes) verspreid over de wereld. Wanneer een bezoeker je site opvraagt, levert de dichtstbijzijnde edge node de content uit in plaats van je oorspronkelijke server (origin).
Voor een WordPress-site betekent dit concreet:
- Statische assets (CSS, JavaScript, afbeeldingen, fonts) worden gecachet op edge nodes wereldwijd
- De afstand tot de bezoeker wordt verkleind, wat de latency verlaagt
- Je origin-server krijgt minder verkeer te verwerken, wat ruimte geeft voor dynamische content
Dit verschilt van server-side caching dat op je eigen server draait. Een CDN werkt ervóór: het onderschept verzoeken voordat ze je server bereiken. In een ideale setup combineer je beide lagen.
Waarom Cloudflare?
Er zijn meerdere CDN-providers, maar Cloudflare heeft een aantal kenmerken die het bijzonder geschikt maken voor WordPress:
- Gratis basisplan met CDN, DDoS-bescherming en SSL
- Enorm edge-netwerk met meer dan 300 locaties wereldwijd
- DNS-gebaseerde integratie - geen servereenwijzigingen nodig
- WordPress-specifieke plugin voor automatische cache-purge
- Uitgebreide beveiligingsfeatures inclusief WAF en bot management
Het gratis plan is voor de meeste WordPress-sites ruim voldoende. De betaalde plannen (Pro vanaf $20/maand, Business vanaf $200/maand) voegen features toe zoals Polish (image optimization), Mirage (lazy loading) en geavanceerde WAF-regels.
Stap 1: DNS migreren naar Cloudflare
De eerste stap is je DNS naar Cloudflare verplaatsen. Dit is de basis van de integratie - Cloudflare werkt als een reverse proxy die tussen je bezoekers en je server staat.
Het migratieproces
- Maak een gratis account aan op cloudflare.com
- Voeg je domein toe - Cloudflare scant automatisch je bestaande DNS-records
- Controleer of alle records correct zijn overgenomen (let vooral op MX-records voor e-mail)
- Wijzig de nameservers bij je domeinregistrar naar die van Cloudflare
- Wacht op propagatie (meestal binnen een uur, maximaal 48 uur)
Het oranje wolkje: proxy aan of uit
Bij elk DNS-record zie je een oranje of grijs wolkje. Dit is de belangrijkste instelling:
- Oranje wolkje (Proxied): verkeer loopt via Cloudflare - CDN, caching en beveiliging zijn actief
- Grijs wolkje (DNS only): Cloudflare fungeert alleen als DNS-resolver, geen proxy
Zet het oranje wolkje aan voor je hoofd-A-record en www-CNAME. Laat het grijs voor records die direct naar je server moeten wijzen, zoals mail-subdomeinen of FTP.
Let op: zodra je proxied inschakelt, zien bezoekers het IP-adres van Cloudflare in plaats van je origin-server. Dit is normaal en gewenst - het verbergt je werkelijke server-IP.
Stap 2: SSL/TLS correct instellen
Een veelgemaakte fout: na het inschakelen van Cloudflare ontstaan redirect-loops of mixed content-waarschuwingen. Dit komt door een verkeerde SSL-modus.
Cloudflare biedt vier SSL-modi:
| Modus | Verbinding bezoeker → Cloudflare | Verbinding Cloudflare → origin |
|---|---|---|
| Off | Geen SSL | Geen SSL |
| Flexible | HTTPS | HTTP |
| Full | HTTPS | HTTPS (zelfondertekend OK) |
| Full (Strict) | HTTPS | HTTPS (geldig certificaat vereist) |
Gebruik altijd Full (Strict). Dit vereist een geldig SSL-certificaat op je origin-server - wat je sowieso hoort te hebben. Flexible lijkt makkelijk, maar creëert een onversleutelde verbinding tussen Cloudflare en je server. Dat is een beveiligingsrisico.
Als je origin-server nog geen SSL heeft, installeer dan een gratis Cloudflare Origin Certificate of gebruik Let's Encrypt.
Schakel daarnaast Always Use HTTPS in onder SSL/TLS → Edge Certificates. Dit redirect alle HTTP-verzoeken naar HTTPS en vervangt de redirect in je WordPress-configuratie of .htaccess.
Stap 3: caching configureren
Hier wordt het interessant. Standaard cachet Cloudflare alleen statische bestanden op basis van de extensie (CSS, JS, afbeeldingen, fonts). HTML-pagina's worden niet standaard gecachet. Dit is een bewuste keuze: HTML is vaak dynamisch in WordPress.
Standaard caching-gedrag
Cloudflare cachet automatisch bestanden met extensies zoals .jpg, .png, .css, .js, .woff2 en meer. De volledige lijst staat in de Cloudflare-documentatie over standaard caching.
Voor deze statische assets hoef je niets te configureren. Controleer wel dat je WordPress-site correcte cache-headers stuurt. Cloudflare respecteert de Cache-Control-header van je origin - als die no-cache zegt, cachet Cloudflare het niet.
Cache Rules voor HTML-pagina's
Wil je dat Cloudflare ook volledige HTML-pagina's cachet (vergelijkbaar met full page caching op serverniveau)? Dan gebruik je Cache Rules.
Maak een regel aan onder Caching → Cache Rules:
Regel 1: Cache alles, behalve dynamische paden
URI Path does not start with /wp-admin
AND URI Path does not start with /wp-login
AND URI Path does not contain wp-cron.php
AND Cookie does not contain wordpress_logged_in
Stel de actie in op Cache Everything met een Edge TTL van bijvoorbeeld 4 uur.
Regel 2: Bypass cache voor dynamische content
URI Path starts with /wp-admin
OR URI Path starts with /wp-login
OR URI Path starts with /wp-json
OR Cookie contains wordpress_logged_in
Stel de actie in op Bypass Cache.
Belangrijk: de volgorde van regels doet ertoe. Cloudflare verwerkt ze van boven naar beneden en stopt bij de eerste match. Zet de bypass-regel bovenaan.
Browser Cache TTL
Stel de Browser Cache TTL in op Respect Existing Headers als je server al correcte Cache-Control-headers stuurt. Zo niet, kies een standaard van 4 uur voor statische assets. Vermijd te lange TTL's als je regelmatig CSS of JavaScript wijzigt - of gebruik cache busting via querystrings of versienummers (wat WordPress standaard doet met ?ver=).
Stap 4: de Cloudflare WordPress-plugin
Installeer de officiële Cloudflare WordPress-plugin. Deze plugin doet drie belangrijke dingen:
- Automatische cache-purge - bij het publiceren of bijwerken van een post purget de plugin automatisch de relevante URL's in Cloudflare
- Real IP herstellen - zonder deze instelling ziet WordPress het IP-adres van Cloudflare in plaats van dat van de bezoeker (belangrijk voor analytics, beveiligingsplugins en rate limiting)
- Optimale instellingen - de plugin kan aanbevolen Cloudflare-instellingen met één klik activeren
Configuratie van de plugin
Na installatie:
- Log in met je Cloudflare API-token (maak een token aan met de permissies Zone → Zone → Read en Zone → Cache Purge → Purge)
- Selecteer je domein
- Klik op Apply Default Settings voor de aanbevolen configuratie
De plugin is lichtgewicht en voegt minimale overhead toe. Het alternatief - handmatig de cache purgen via het dashboard of API - is foutgevoelig en schaalt niet.
Real IP-herstel op serverniveau
De WordPress-plugin herstelt het echte bezoeker-IP via PHP, maar het is beter om dit op webserverniveau te doen. Als je NGINX gebruikt, voeg dit toe aan je configuratie:
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 173.245.48.0/20;
# Voeg alle Cloudflare IP-ranges toe
# Zie: https://www.cloudflare.com/ips/
real_ip_header CF-Connecting-IP;
Dit zorgt dat alle server-logs en applicaties het werkelijke IP van de bezoeker zien, niet dat van Cloudflare.
Stap 5: performance-optimalisaties
Met de basis op orde kun je Cloudflare's performance-features activeren.
Speed → Optimization
- Auto Minify (CSS, JavaScript, HTML) - verwijdert witruimte en comments. Let op: dit kan conflicteren met WordPress-minificatie-plugins. Gebruik één van de twee, niet beide.
- Brotli-compressie - schakel dit in. Brotli is efficiënter dan gzip en wordt door alle moderne browsers ondersteund.
- Early Hints (103) - stuurt preload-hints naar de browser terwijl de origin nog bezig is met het genereren van de response. Versnelt het laden van kritieke CSS en fonts.
- HTTP/2 en HTTP/3 - standaard ingeschakeld bij Cloudflare. Controleer dat je origin ook HTTP/2 ondersteunt voor de verbinding tussen Cloudflare en je server.
Image optimization (Pro-plan en hoger)
Met een Pro-plan krijg je toegang tot:
- Polish - comprimeert afbeeldingen automatisch (lossy of lossless) en converteert ze naar WebP
- Mirage - lazy loading en responsive image placeholders voor mobiele bezoekers
Dit vervangt WordPress-plugins voor image optimization en bespaart bandbreedte.
Stap 6: beveiliging instellen
Cloudflare is niet alleen een CDN - het is ook een beveiligingslaag. Deze instellingen zijn relevant voor WordPress:
Bot Fight Mode
Schakel dit in om bekende bots en scrapers te blokkeren. Dit vermindert spam in contactformulieren en comment-spam. Let op: als je legitieme bots gebruikt (monitoring-tools, API-clients), voeg deze toe aan de allowlist.
WAF (Web Application Firewall)
Op het gratis plan krijg je basis WAF-regels. Op betaalde plannen kun je specifieke regels activeren die bekende WordPress-kwetsbaarheden blokkeren, zoals SQL injection op wp-login.php of brute force-aanvallen.
Rate Limiting
Beperk het aantal verzoeken per IP aan gevoelige endpoints als /wp-login.php en /xmlrpc.php. Dit voorkomt brute force-aanvallen zonder dat je een WordPress-plugin nodig hebt.
Overweeg ook om xmlrpc.php volledig te blokkeren als je het niet gebruikt. De meeste moderne WordPress-sites gebruiken de REST API in plaats van XML-RPC.
Veelgemaakte fouten bij Cloudflare en WordPress
Zelfs met een correcte basissetup gaat het vaak mis op deze punten:
1. Dubbele minificatie
Zowel Cloudflare als een plugin zoals Autoptimize minificeert CSS en JavaScript. Dit leidt tot kapotte stylesheets of JavaScript-fouten. Kies één bron voor minificatie.
2. Caching van ingelogde sessies
Als je Cache Everything gebruikt zonder de wordpress_logged_in-cookie uit te sluiten, zien ingelogde gebruikers gecachte pagina's - mogelijk van andere gebruikers. Dit is een privacy-risico. Test altijd in een privévenster.
3. REST API-problemen
Te agressieve security-instellingen kunnen de WordPress REST API blokkeren. Dit breekt de Gutenberg-editor, WooCommerce en andere plugins die de REST API gebruiken. Controleer na het activeren van WAF-regels of je editor nog werkt.
4. Geen cache-purge bij updates
Zonder de Cloudflare-plugin of een vergelijkbare oplossing blijven bezoekers verouderde pagina's zien na een update. Zorg altijd voor automatische cache-purge.
Cloudflare en multi-server setups
Als je WordPress draait op een multi-server setup, fungeert Cloudflare als extra caching-laag vóór je load balancer. Dit heeft een paar voordelen:
- Minder verkeer naar je origin-servers - edge-cached content bereikt je servers niet eens
- Geografische verdeling - Cloudflare's edge nodes fungeren als een wereldwijd gedistribueerde caching-laag
- DDoS-bescherming - aanvallen worden op het edge-netwerk geabsorbeerd, niet op je infrastructuur
Zorg dat je load balancer correct is geconfigureerd om Cloudflare's IP-ranges te herkennen en het echte bezoeker-IP door te geven via de CF-Connecting-IP-header.
Performance meten na implementatie
Na het instellen van Cloudflare wil je het effect meten. Gebruik de technieken uit het artikel over WordPress performance bottlenecks herkennen en meten en let specifiek op:
- TTFB (Time to First Byte) - zou moeten dalen, vooral voor bezoekers ver van je origin
- Cache Hit Ratio - controleer in het Cloudflare-dashboard onder Analytics → Caching. Streef naar >80% voor statische assets
- Origin-belasting - monitor CPU en geheugen op je server. Met een goed werkende CDN-laag zou dit moeten dalen
Controleer de CF-Cache-Status-header in je browser's DevTools. De waarden die je wilt zien:
- HIT - geserveerd vanuit Cloudflare's edge cache
- MISS - opgehaald van je origin, nu gecachet voor volgende verzoeken
- BYPASS - bewust niet gecachet (dynamische content)
- DYNAMIC - Cloudflare cachet dit content-type niet standaard
Als je veel MISS of DYNAMIC ziet op content die gecachet zou moeten zijn, controleer je Cache Rules en origin-headers.
Samenvatting: de ideale Cloudflare-WordPress stack
Een goed geconfigureerde Cloudflare-integratie ziet er als volgt uit:
- DNS via Cloudflare met proxy (oranje wolkje) op je web-records
- SSL Full (Strict) met een geldig origin-certificaat
- Cache Rules die HTML cachen voor niet-ingelogde bezoekers en dynamische paden bypassen
- De officiële WordPress-plugin voor automatische cache-purge en IP-herstel
- Brotli en Early Hints ingeschakeld voor extra performance
- WAF en Rate Limiting op gevoelige WordPress-endpoints
- Redis object caching op je origin voor cache misses die toch je server bereiken
Deze stack combineert edge caching, server-side caching en database caching tot een gelaagd systeem dat WordPress snel houdt - ongeacht waar je bezoekers zich bevinden.
Veelgestelde vragen
Wat is een CDN en waarom heb ik het nodig voor WordPress?
Een CDN (Content Delivery Network) is een netwerk van servers verspreid over de wereld. Het cachet en serveert je content vanaf een locatie dichtbij je bezoeker, waardoor laadtijden flink dalen. Voor WordPress-sites met internationaal verkeer of veel statische assets is een CDN vrijwel onmisbaar.
Is Cloudflare gratis te gebruiken met WordPress?
Ja, Cloudflare biedt een gratis plan dat al basis-CDN, DDoS-bescherming en SSL bevat. Voor de meeste kleine tot middelgrote WordPress-sites is dit voldoende. Betaalde plannen voegen features toe zoals image optimization, WAF-regels en geavanceerde caching.
Kan ik Cloudflare combineren met server-side caching?
Absoluut, en dat is zelfs aan te raden. Cloudflare cachet content op edge-niveau, terwijl NGINX FastCGI Cache of een plugin zoals WP Super Cache op serverniveau werkt. De twee lagen vullen elkaar aan: server-side caching versnelt cache misses bij Cloudflare.
Hoe purge ik de Cloudflare-cache na een WordPress-update?
Met de officiële Cloudflare WordPress-plugin wordt de cache automatisch gepurged bij het publiceren of bijwerken van posts. Je kunt ook handmatig purgen via het Cloudflare-dashboard of de API, bijvoorbeeld per URL of voor de hele site.
Heeft Cloudflare invloed op mijn WordPress-admin?
Standaard niet, mits correct geconfigureerd. Cloudflare moet geen dynamische pagina's cachen, zoals wp-admin of ingelogde sessies. Met de juiste Page Rules of Cache Rules sluit je deze paden uit van caching.