CDN voor WordPress: zo kies je de juiste

Er zijn twee soorten CDN voor WordPress: een asset-CDN, dat een plug-in aansluit door de URL's van je afbeeldingen, CSS en JavaScript te herschrijven, en een full-site proxy, die vóór je hele domein staat en ook de HTML-pagina's zelf kan cachen. Welke bij je past, hangt af van waar je site tijd verliest, wie je bezoekers zijn en hoeveel je aan je DNS wilt veranderen. In deze gids vergelijk je beide soorten en krijg je een checklist om een aanbieder te kiezen.

De basis lees je in wat een CDN is. Weet je nog niet waarom je site traag is, zoek dan eerst de oorzaak met de gids over waarom WordPress-sites traag zijn.

De twee soorten WordPress-CDN

Asset-CDN (statische bestanden via een plug-in)

Een asset-CDN levert alleen statische bestanden. Je maakt bij de aanbieder een pull zone aan en krijgt een hostnaam zoals cdn.example.com. Een WordPress-plug-in herschrijft daarna de URL's in je HTML, zodat bestanden uit wp-content en wp-includes via die hostnaam laden. Bij het eerste verzoek haalt het CDN elk bestand op van je server en bewaart het een kopie.

Je domein, je DNS en je HTML blijven waar ze zijn. Elke paginaweergave gaat nog steeds naar je hosting, die de HTML net als eerst opbouwt. Alleen de bestanden waar de pagina naar verwijst, komen van het CDN.

Full-site proxy (hele domein via nameservers of DNS)

Een full-site proxy neemt het verkeer voor je hele domein over. Afhankelijk van de aanbieder delegeer je je nameservers naar hem of laat je de DNS van je domein naar hem wijzen. Vanaf dat moment passeert elk verzoek, inclusief HTML, eerst de edge-servers van de aanbieder. De edge levert wat gecachet mag worden en stuurt de rest door naar je hosting.

Omdat al het verkeer erdoorheen loopt, kan een full-site proxy de HTML van openbare pagina's cachen, HTTPS afhandelen en aanvallen filteren voordat ze je server bereiken. Het is ook de grotere ingreep, want je hele site hangt ervan af dat de proxy goed is ingesteld.

Wat elke soort cachet

Het verschil dat het meest telt, is de HTML. Op een doorsnee WordPress-site is het trage deel van een paginaweergave de server die de pagina met PHP en de database opbouwt. Een asset-CDN komt niet aan die stap, dus je time to first byte blijft gelijk.

Een full-site proxy kan die HTML voor anonieme bezoekers vanaf de edge leveren, zonder dat PHP of de database er iets mee te maken heeft. Daarom helpt dit type het meest als je TTFB hoog is of je server het in piekuren zwaar heeft.

Assets worden door beide soorten gecachet. Worden je pagina's al snel opgebouwd (bijvoorbeeld dankzij een goede paginacache op de server) en wachten bezoekers vooral op grote bestanden, dan dekt een asset-CDN misschien al veel van wat je nodig hebt.

Voor- en nadelen in de praktijk

Wanneer een asset-CDN volstaat

• Je server reageert al snel, en zware afbeeldingen of scripts zijn de bottleneck.
• Je kunt of wilt de nameservers of DNS van je domein niet wijzigen.
• Je wilt een aanpassing die je terugdraait door een plug-in uit te zetten.

Let wel op de typische bijwerkingen. Bestanden die hard in het thema, in de CSS van een pagebuilder of in inline styles staan, worden vaak niet herschreven en blijven van je origin laden. Weblettertypen die van een andere hostnaam komen, hebben een passende header Access-Control-Allow-Origin nodig, anders weigert de browser ze te gebruiken. En WordPress hangt een querystring ?ver= aan geladen scripts en stylesheets: het CDN moet querystrings in zijn cachesleutel meenemen, anders blijven bezoekers na een update het oude bestand krijgen.

Wanneer een full-site proxy de moeite waard is

• Je TTFB is hoog op openbare pagina's, of de server wordt traag tijdens het versturen van een nieuwsbrief of een actie.
• Je bezoekers zitten verspreid over meerdere landen of continenten.
• Je wilt dat DDoS-filtering en HTTPS vóór je hosting worden afgehandeld.

De nadelen zijn ook echt. Je moet de bypassregels goed instellen, zodat een persoonlijke pagina nooit voor iedereen in de cache belandt. Publiceer of bewerk je een bericht, dan moet de gecachete HTML worden ververst. Je server ziet de proxy voortaan als client, dus je beveiligings- of statistiekplug-ins moeten het echte IP-adres van de bezoeker uitlezen uit de header die de aanbieder meestuurt. En aanvallers die het IP-adres van je server kennen, kunnen de edge nog steeds omzeilen, tenzij je hoster alleen verkeer van de proxy accepteert.

De checklist om te kiezen

Gebruik deze vragen als je aanbieders vergelijkt. Ze gelden voor elk CDN, hoe het ook heet.

HTML-caching en bypassregels

Kan het HTML cachen, en hoe bepaalt het wat het overslaat? Bij WordPress moeten deze verzoeken altijd ongecachet je server bereiken:

• /wp-admin/, wp-login.php en admin-ajax.php
• Bezoekers met een cookie wordpress_logged_in_ (de cookie-referentie van WordPress (Engelstalig) somt alle cookies op die de core zet)
• Reageerders met een cookie comment_author_, zodat ze hun eigen reactie zien die nog op moderatie wacht
• Met een wachtwoord beveiligde berichten, die een cookie wp-postpass_ gebruiken
• Voorbeeldweergaven van berichten en alles wat gepersonaliseerd is, zoals winkelwagens en accountpagina's in een webshop

WordPress helpt je hierbij: voor ingelogde gebruikers, met een wachtwoord beveiligde berichten en 404-pagina's stuurt het Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private mee. Een proxy die Cache-Control-headers respecteert, slaat deze antwoorden dus over. Het risico zit in plug-ins die pagina's personaliseren zonder zulke headers te sturen, dus test die.

De cache legen na het publiceren

Werk je een bericht bij, dan verandert niet alleen het bericht zelf, maar ook de homepage, de categorie- en tagarchieven en de feed. Vraag hoe je de cache leegt: per URL, voor het hele domein, via een dashboard, via een API? Of de cache automatisch wordt geleegd bij het publiceren, hangt af van de aanbieder en je opzet. Zonder die functie heb je een cacheduur nodig die kort genoeg is, of een vaste werkwijze om de cache na bewerkingen te legen.

Afbeeldingsoptimalisatie

Zet het CDN afbeeldingen om naar WebP of AVIF, en levert het nog steeds het origineel aan browsers die het nieuwe formaat niet ondersteunen? Dan heb je misschien geen afbeeldingsplug-in meer nodig die dat werk op je server doet.

SSL tussen bezoeker, edge en server

Bij een asset-CDN heeft de CDN-hostnaam een eigen certificaat nodig. Bij een full-site proxy heeft de edge het certificaat voor je domein. Zorg dat ook de verbinding van de edge naar je server via HTTPS loopt. Praat de proxy gewoon HTTP met een WordPress-site die HTTPS afdwingt, dan kun je in een oneindige redirectlus belanden, zoals de HTTPS-documentatie van WordPress (Engelstalig) uitlegt.

Beveiliging en DDoS-bescherming

Een asset-CDN beschermt alleen de bestanden die het levert. Aanvallen op je pagina's, je inlogpagina of XML-RPC komen nog steeds rechtstreeks op je server terecht. Een full-site proxy kan floods filteren, landen of IP-reeksen blokkeren en misbruikende clients aan de edge afremmen met rate limiting. Kijk wat er in het abonnement zit dat je overweegt en wat extra kost.

Edge-locaties dicht bij je publiek

Een CDN helpt alleen bij afstand als het edge-servers dicht bij je bezoekers heeft. Kijk waar je bezoekers echt vandaan komen, en daarna welke regio's de aanbieder in jouw abonnement dekt.

Installatiewerk en wat er met DNS en e-mail gebeurt

Voor een asset-CDN vul je een hostnaam in bij een plug-in en voeg je misschien één CNAME-record toe. Bij een full-site proxy verhuist je DNS meestal naar de aanbieder. Elk record moet daar dus staan voordat je overstapt, inclusief de MX-records voor e-mail en de TXT-records voor SPF, DKIM en domeinverificatie. De checklist voor nameservers wijzigen zonder downtime loopt dit stap voor stap met je door.

Inzicht

Zoek naar een response-header die bij elk verzoek hit, miss of bypass laat zien, en naar statistieken over de cache-hitratio, verkeer vanaf de edge versus de origin en foutpercentages. Zonder die gegevens kun je niet zien of het CDN iets nuttigs doet.

Meet voor en na

Beoordeel een CDN niet op gevoel. Leg een nulmeting vast voordat je overstapt:

1. Test je homepage, een bericht en een archiefpagina met corewebvitals.page. Noteer de gegevens van echte gebruikers (als je site genoeg verkeer heeft) en de Lighthouse-resultaten voor mobiel en desktop.
2. Meet vanaf je eigen computer hoe snel de server de HTML levert:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. Vraag na de overstap dezelfde pagina twee keer op en bekijk de headers. Het tweede verzoek moet een cache hit tonen.

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

4. Log in en controleer of wp-admin en je front-end een bypass tonen, geen hit.
5. Vergelijk de gegevens van echte gebruikers opnieuw als die zijn bijgewerkt, want ze beslaan de laatste 28 dagen.

De gids over websitesnelheid meten legt uit hoe je zo'n vergelijking eerlijk houdt.

Zo helpt fast.site je

fast.site is een full-site proxy. Het staat vóór je bestaande WordPress-hosting, dus je houdt je hoster en je site. Je voegt je domein toe in het dashboard, laat je nameservers naar fast.site wijzen en verifieert. Vanaf dat moment beheert fast.site je DNS, dus alle bestaande records, inclusief MX-records voor e-mail, moeten in de DNS-zone van fast.site staan.

Fast Edge Cache™ levert openbare pagina's en assets vanaf edge-servers in de regio's die bij je abonnement horen. fast.site respecteert de Cache-Control-headers die je WordPress-site meestuurt, en de response-header fs-cache toont HIT, MISS of BYPASS, zodat je wp-admin en ingelogde sessies zelf kunt controleren. Na het publiceren leeg je de cache van losse URL's of van het hele domein in het dashboard, met een logboek, of via de API vanuit je eigen scripts.

JPEG- en PNG-afbeeldingen worden direct naar WebP omgezet voor browsers die het ondersteunen, met AVIF afhankelijk van je abonnement. Elk domein krijgt automatische Layer 7-DDoS-detectie en gratis SSL-certificaten die automatisch worden verlengd. Meer details vind je op de WordPress-pagina en in de cachingdocumentatie.

Meet je site voor en na met dezelfde pagina's en tools. Je kunt het testen met een gratis proefperiode van 7 dagen.

Veelgestelde vragen

Heb ik een CDN-plug-in nodig voor WordPress?

Alleen voor een asset-CDN, want de plug-in herschrijft je bestands-URL's naar de CDN-hostnaam. Een full-site proxy werkt op DNS-niveau en hoeft geen URL's te herschrijven, want je domein blijft hetzelfde. Sommige aanbieders bieden toch een plug-in voor taken zoals de cache legen.

Vervangt een CDN mijn cachingplug-in?

Niet per se. Een paginacache op je server versnelt elk verzoek dat het CDN mist en al het ingelogde verkeer, zoals de cachedocumentatie van WordPress (Engelstalig) beschrijft. Met een full-site proxy maakt hij minder uit voor anonieme bezoekers, maar het kan zelden kwaad om hem te houden.

Maakt een CDN wp-admin of het inloggen kapot?

Dat hoort niet te gebeuren, zolang wp-admin, de inlogpagina en ingelogde bezoekers de cache omzeilen. WordPress stuurt no-cache-headers mee voor ingelogde gebruikers. Test het na de installatie: log in, bewerk een bericht en controleer de cacheheader op de beheerpagina's.

Waarom zie ik mijn wijzigingen niet nadat ik een bericht heb bijgewerkt?

Het CDN levert nog de gecachete kopie. Leeg de cache van de bericht-URL en van de pagina's die het bericht tonen, zoals de homepage en de categoriearchieven. Controleer bij CSS en JavaScript of het CDN de querystring ?ver= in zijn cachesleutel houdt.