De belangrijkste conclusie: een CDN en lokale afbeeldingsoptimalisatie lossen verschillende problemen op — een CDN verkort de netwerkafstand die een bestand aflegt, terwijl lokale optimalisatie het bestand zelf verkleint. Sites met veel internationaal verkeer en grote mediabibliotheken hebben meestal baat bij beide; sites met vooral lokale bezoekers halen vaak meer uit het eerst oplossen van formaat en grootte.
Twee verschillende knelpunten, vaak als één gezien
"Mijn afbeeldingen zijn traag" kan twee verschillende dingen betekenen, en de oplossing verschilt afhankelijk van wat er daadwerkelijk aan de hand is:
- Het bestand is te groot. Een JPEG van 2MB is een JPEG van 2MB, hoe dichtbij de server ook staat. Dit is een formaat- en compressieprobleem.
- Het bestand moet te ver reizen. Zelfs een perfect geoptimaliseerd WebP-bestand van 80KB doet er langer over om een bezoeker in Sydney te bereiken als je enige server in Amsterdam staat. Dit is een netwerklatentieprobleem.
Een CDN (Content Delivery Network) lost het tweede probleem op door kopieën van je bestanden te cachen op wereldwijd verspreide servers, zodat een bezoeker downloadt van de dichtstbijzijnde in plaats van je origin-server. Het doet niets aan het eerste probleem — een CDN cachet en serveert een niet-geoptimaliseerd bestand van 2MB, vanuit netwerkperspectief, net zo snel als een klein bestand.
Wat lokale optimalisatie daadwerkelijk doet
"Lokale optimalisatie" betekent hier het verwerken van afbeeldingen op je eigen WordPress-server: converteren naar moderne formaten (WebP, AVIF), comprimeren zonder zichtbaar kwaliteitsverlies, formaat aanpassen aan de daadwerkelijke weergaveafmetingen, en het genereren van de responsive srcset-varianten waaruit browsers kunnen kiezen.
Dit is een eenmalige kost per afbeelding. Zodra een afbeelding is geconverteerd en correct gedimensioneerd, hoeft dit werk niet bij elk verzoek opnieuw te gebeuren — het kleinere bestand is vanaf dan simpelweg wat wordt geserveerd, of dat nu vanaf je eigen server is of achter een CDN.
Erdo Image Optimizer doet precies dit: het gebruikt de eigen GD- of Imagick-bibliotheek van je server om afbeeldingen te converteren en comprimeren, zonder externe API of kosten per afbeelding. Voor de technische details, zie onze gids voor het converteren van WordPress-afbeeldingen naar WebP.
Waar elke optie daadwerkelijk wint
| Factor | Lokale optimalisatie | CDN |
|---|---|---|
| Vermindert bestandsgrootte | Ja — dit is de hoofdtaak | Nee — serveert wat het krijgt aangeleverd |
| Vermindert netwerkafstand | Nee | Ja — dit is de hoofdtaak |
| Eenmalige of terugkerende kost | Vooral eenmalige verwerking | Meestal terugkerend, schaalt met bandbreedte |
| Helpt een publiek in één regio | Ja, direct | Beperkt — weinig afstand te verkorten |
| Helpt een wereldwijd publiek | Indirect (kleinere bestanden gaan overal sneller) | Ja, direct |
| Setup-complexiteit | Plugin installeren + bulkconversie | DNS/origin-configuratie, cache-invalidatieregels |
Een concrete vergelijking
Bekijk een niet-geoptimaliseerde JPEG-hero-afbeelding van 1,8MB, opgevraagd door een bezoeker op 9.000km van de origin-server:
| Scenario | Bestandsgrootte | Geschatte totale laadtijd* |
|---|---|---|
| Niet-geoptimaliseerde JPEG, geen CDN | 1,8 MB | ~2,9s |
| Niet-geoptimaliseerde JPEG, achter een CDN | 1,8 MB | ~2,1s |
| Geoptimaliseerde WebP (~350KB), geen CDN | 350 KB | ~1,3s |
| Geoptimaliseerde WebP (~350KB), achter een CDN | 350 KB | ~0,6s |
*Geschatte, illustratieve cijfers op basis van typische latentie- en bandbreedteaannames voor een verzoek over lange afstand — werkelijke cijfers variëren per host, verbinding en CDN-aanbieder.
Het patroon dat ertoe doet: formaatoptimalisatie alleen (rij 3) verslaat het toevoegen van een CDN aan een niet-geoptimaliseerd bestand (rij 2). Beide gecombineerd (rij 4) verslaan elk apart met een ruime marge. Als je er maar één eerst kunt doen, brengt het fixen van de bestandsgrootte je verder dan het fixen van de afstand.
Wanneer een CDN de moeite waard is
- Je verkeer is echt internationaal, niet alleen lokaal met af en toe een buitenlands bezoek.
- Je mediabibliotheek is groot genoeg dat bandbreedte of CPU van de origin-server zelf een knelpunt begint te worden onder belasting.
- Je serveert al geoptimaliseerde formaten en afmetingen, en wilt de volgende stap in snelheid.
- Je draait WooCommerce of een andere opzet met veel verkeer waarbij origin-serverbelasting tijdens verkeerspieken een reëel risico is.
Wanneer het niet de prioriteit is
- Je publiek is geconcentreerd in één land of regio dicht bij je hosting.
- Je hebt afbeeldingen nog niet naar moderne formaten geconverteerd — dit is bijna altijd de fix met meer impact om eerst te doen.
- Je huidige hosting bevat al een basis-CDN of cachelaag (gebruikelijk bij beheerde WordPress-hosts zoals Kinsta of WP Engine) — controleer dit voordat je voor een tweede betaalt.
Zo controleer je wat je site daadwerkelijk nodig heeft
In plaats van te gokken, voer je een snelle diagnose uit:
- Open PageSpeed Insights en controleer het gedeelte "Diagnose" op gemarkeerde afbeeldingen — als het formaat- of afmetingsproblemen meldt, is dat een lokaal optimalisatieprobleem, geen afstandsprobleem.
- Gebruik een tool zoals WebPageTest met een testlocatie ver van je server (bijvoorbeeld testen vanuit Singapore als je host in Europa staat). Vergelijk de "Time to First Byte" en verbindingstijd met een test vanaf een locatie dicht bij je server. Een groot verschil tussen beide wijst op latentie, niet bestandsgrootte, als de grotere factor.
- Controleer de documentatie van je hostingplan — veel beheerde WordPress-hosts (Kinsta, WP Engine, Cloudways) bundelen standaard een CDN of edge-cachelaag. Betalen voor een tweede CDN bovenop een bestaande helpt zelden.
Een paar CDN-valkuilen om te kennen
Een CDN is eenmaal toegevoegd geen puur voordeel — een paar praktische kwesties duiken op in echte WordPress-opzetten:
- Cache-invalidatie — een afbeelding in de mediabibliotheek vervangen werkt de gecachte kopie van het CDN niet altijd direct bij. De meeste integraties regelen dit automatisch, maar het is de moeite waard om dit te controleren, vooral bij tijdsgevoelige content zoals prijsgrafieken.
- Extra DNS-/verbindingsoverhead bij kleine sites — voor een pagina met slechts 2-3 afbeeldingen kan de overhead van een nieuwe DNS-lookup en TLS-handshake naar een CDN-domein de latentiewinst soms tenietdoen, vooral bij bezoekers die al dicht bij de origin-server zitten.
- CORS-configuratie — als het CDN assets serveert vanaf een ander subdomein, kunnen lettertypen en sommige via JavaScript geladen afbeeldingen CORS-fouten tegenkomen tenzij headers correct zijn ingesteld.
Niets hiervan is een reden om een CDN volledig te vermijden — het zijn configuratiedetails die het waard zijn om te controleren, in plaats van aan te nemen dat een CDN puur gratis winst is.
Beide samen gebruiken
Voor sites die daadwerkelijk beide nodig hebben, telt de volgorde: eerst optimaliseren, dan cachen. Erdo Image Optimizer bevat precies om die reden een optionele BunnyCDN-integratie — afbeeldingen worden lokaal naar WebP/AVIF geconverteerd en correct gedimensioneerd, en het zijn die al geoptimaliseerde bestanden die vervolgens naar de CDN-edge worden gepusht en van daaruit worden geserveerd, in plaats van de originele te grote uploads te cachen.
Tot slot
"CDN" en "afbeeldingsoptimalisatie" behandelen als inwisselbare oplossingen voor hetzelfde probleem is een veelgemaakte fout — ze pakken verschillende lagen van dezelfde totale laadtijd aan. Als de afbeeldingen van je site nog steeds ruwe JPEG's en PNG's zijn, levert het converteren en herformatteren daarvan doorgaans meer op dan er een CDN voor te zetten. Als je formaat en grootte al hebt geregeld en je verkeer echt wereldwijd is, is een CDN de logische volgende stap. Voor de meeste WordPress-sites is de juiste volgorde: eerst optimaliseren, en dan beslissen of de resterende latentie de doorlopende kosten van een CDN rechtvaardigt.