Typ de URL van een willekeurige WordPress website in PageSpeed Insights en je krijgt gemiddeld een score van onder de 50. Niet van een verouderde website uit 2010, maar van nieuwe sites die vorige maand live zijn gegaan. WordPress heeft structurele redenen waarom het traag is, en die redenen worden met elke nieuwe plugin en elk nieuw thema alleen maar erger. In dit artikel leg ik precies uit waarom, en wat de twee routes zijn om het op te lossen.
De echte oorzaken van een trage WordPress site
Het snelheidsproobleem bij WordPress begint niet bij de hosting of de verbinding van je bezoeker. Het begint in de architectuur van het systeem zelf.
Plugins zijn de eerste boosdoener. De gemiddelde WordPress-site draait op 20 tot 30 actieve plugins. Elke plugin laadt zijn eigen CSS-bestanden, JavaScript-bestanden en database-queries. Bij elk paginabezoek verwerkt de server al die verzoeken opnieuw, van begin tot eind. Een contactformulier-plugin laadt zijn scripts op elke pagina, ook op de homepagina waar helemaal geen formulier staat. Een SEO-plugin voegt metatags toe via meerdere database-calls per verzoek. Een beveiligingsplugin scant elk inkomend verzoek real-time. Al die kleine brokjes overhead stapelen zich op tot seconden laadtijd.
Page builders zijn de tweede grote oorzaak. De populairste page builders voor WordPress, zoals Divi, Elementor en Avada, zijn ware monsters van CSS en JavaScript. Elementor laadt standaard meer dan 300 kilobyte aan scripts, ongeacht hoe simpel de pagina die je bouwt is. Al die animatie-opties, layoutvarianten, sliders en widgets worden ingeladen op elke pagina, ook op pagina's die ze niet gebruiken. Het resultaat is een website die al vertraagd is voordat de werkelijke content begint te laden.
De database is de derde factor. WordPress slaat vrijwel alles op in MySQL: posts, pagina's, revisies van bewerkingen, plugin-instellingen, sessiedata, transient-opties. Met elke update, elke bewerking, elke bezoeker groeit die database. Na een jaar intensief gebruik bevatten sommige WordPress-databases duizenden revisies van een enkele pagina. Queries worden langzamer, de server werkt harder, en de laadtijd stijgt.
Hosting verergert het probleem. De meeste WordPress-sites draaien op gedeelde hosting voor 3 tot 10 euro per maand. Op gedeelde hosting deel je een server met honderden andere websites. Als een buurwebsite plotseling veel verkeer krijgt, heeft dat direct invloed op jouw laadtijd. PHP-verwerking op goedkope gedeelde hosting is traag, en WordPress heeft PHP nodig voor elk verzoek.
Core Web Vitals: waarom snelheid direct je Google-ranking beïnvloedt
In 2021 introduceerde Google de Core Web Vitals als officiële rankingfactor. Dat zijn drie meetwaarden die de gebruikerservaring meten:
- LCP (Largest Contentful Paint): hoe lang duurt het voordat het grootste zichtbare element geladen is? Google vindt alles onder 2,5 seconden goed. Boven 4 seconden is slecht.
- INP (Interaction to Next Paint): hoe snel reageert de pagina op een klik of invoer? Onder 200 milliseconden is goed.
- CLS (Cumulative Layout Shift): verschuiven elementen terwijl de pagina laadt? Dat is frustrerend voor de gebruiker en slecht voor je score.
De meeste WordPress-sites met een standaard thema en plugins scoren slecht op LCP en INP. De reden is simpel: er is zoveel JavaScript dat geblokkeerd laadt voordat de pagina zichtbaar wordt, dat de browser letterlijk moet wachten voordat hij de pagina kan tonen.
Wat de cijfers zeggen over laadtijd en conversie
Onderzoek toont aan dat de meerderheid van mobiele bezoekers een pagina verlaat als die langer dan drie seconden laadt. Voor e-commerce is het effect direct: een trage laadtijd remt conversies, ook als je dat nooit precies meet.
Voor lokale bedrijven is het effect minder direct meetbaar, maar niet minder reëel. Een potentiële klant die jouw website opent en drie seconden naar een wit scherm staart, klikt eerder weg dan iemand die direct content ziet. Dat zijn misgelopen contactaanvragen die je nooit als zodanig registreert, omdat de persoon al weg is voordat je ze kunt tellen.
Bovendien: Google rankt langzame sites lager. Een PageSpeed-score van 30 is niet alleen een slechte gebruikerservaring, het is een actieve handicap in de zoekresultaten ten opzichte van concurrenten met snellere sites.
Route 1: WordPress optimaliseren
Als je WordPress wilt houden, zijn er stappen die de situatie aanzienlijk verbeteren. Dit is het stappenplan:
Stap 1: Verwijder overbodige plugins. Audit elke plugin die je actief hebt. Gebruik je het echt? Kan het met ingebouwde WordPress-functionaliteit of met één betere plugin? Elk verwijderde plugin is minder overhead.
Stap 2: Schakel over naar een lichtgewicht thema. GeneratePress en Kadence zijn beide sub-30 kilobyte aan basisCSS. Vergelijk dat met Divi (meerdere honderden kilobytes) en het verschil is enorm. Je verliest de visuele drag-and-drop builder, maar wint snelheid terug.
Stap 3: Installeer WP Rocket of een vergelijkbaar caching-systeem. Caching slaat de HTML-output van elke pagina op, zodat de server die niet opnieuw hoeft te genereren voor elk bezoek. Dit is de snelste manier om direct effect te zien. WP Rocket kost 59 dollar per jaar en verdient zichzelf terug.
Stap 4: Optimaliseer afbeeldingen. Gebruik WebP-formaat en comprimeer elke afbeelding voordat je hem uploadt. Een plugin zoals ShortPixel doet dit automatisch. Afbeeldingen zijn in de meeste gevallen de grootste bijdrager aan de totale paginagrootte.
Stap 5: Gebruik een CDN. Een Content Delivery Network serveert je statische bestanden (afbeeldingen, CSS, JavaScript) vanaf servers dicht bij de bezoeker. Cloudflare heeft een gratis plan dat al merkbaar verschil maakt.
Met al deze optimalisaties kom je op een score van 75 tot 90 op PageSpeed. Dat is aanzienlijk beter dan de gemiddelde WordPress-site, maar er zijn twee problemen: het kost regelmatig onderhoud (plugins updaten, database opruimen, caching bijhouden), en zodra je nieuwe content of plugins toevoegt, kan de score opnieuw dalen.
Route 2: Moderne technologie
De fundamenteel andere benadering is een website bouwen met een framework dat van de grond af is ontworpen voor snelheid. Next.js is het meest gebruikte framework in dit segment. In plaats van HTML te genereren bij elk verzoek via een database, genereert Next.js statische HTML-bestanden tijdens het buildproces. Die bestanden worden direct geserveerd aan de bezoeker, zonder database-queries, zonder PHP-verwerking, zonder plugin-overhead. Dat is wat een website zonder CMS inhoudt: vooraf gebouwde pagina's, direct geserveerd.
Het resultaat: een pagina die in 0,3 tot 0,8 seconden laadt. LCP-scores van 0,5 seconden zijn normaal. PageSpeed-scores boven de 95 zijn de standaard, niet de uitzondering. Dat is niet omdat Next.js een "betere versie van WordPress" is, maar omdat het een compleet andere architectuur heeft.
Het nadeel: je kunt niet zelf content beheren via een vertrouwde interface, tenzij je een headless CMS toevoegt. Dat is een extra systeem (zoals Sanity, Contentful of Strapi) dat je content beheert, terwijl de Next.js-website die content razendsnel toont. Dit is meer setup, maar het geeft je het beste van beide werelden: beheergemak én topsnelheid.
Next.js vs. WordPress: een concrete vergelijking
Om het concreet te maken: ik heb recent een klant op Gran Canaria geholpen die een WordPress-site had met een PageSpeed-score van 28 op mobiel. Na migratie naar Next.js met dezelfde content en hetzelfde ontwerp was de score 97. De gemiddelde laadtijd daalde van 5,8 seconden naar 0,6 seconden. Het aantal contactaanvragen steeg in de eerste maand met 34%, zonder andere wijzigingen aan de site.
Dat is uiteraard geen garantie voor elk project, maar het illustreert wat een architectuurverschil kan doen. De verbetering was niet het gevolg van beter hostingpakket of slimmere optimalisaties, maar van een fundamenteel andere manier van bouwen.
Wat kost een trage website je echt?
Een WebsiteScore van 28 in PageSpeed is geen abstracte score. Het heeft directe financiële gevolgen. Als je website 500 bezoekers per maand trekt en 3% van die bezoekers neemt contact op, zijn dat 15 leads per maand. Als je laadtijd verbetert waardoor 20% meer bezoekers de pagina niet verlaat, zijn dat 12 extra bezoekers per maand die de kans krijgen je site te zien. Bij een gemiddelde contactratio zijn dat 3 tot 4 extra leads per maand, structureel.
Bovendien rankt een snelle site hoger in Google. Elke positie omhoog in de zoekresultaten levert gemiddeld meer klikken op. Een combinatie van betere snelheid en hogere ranking kan het organisch verkeer in een jaar tijd verdubbelen.
Welke route past bij jou?
Een blog met veel content die je wekelijks zelf beheert en uitbreidt? WordPress met goede optimalisatie is een prima keuze. Een bedrijfswebsite, portfolio, dienstenpagina of landingspagina die je een paar keer per jaar aanpast? Een moderne statische site is bijna altijd sneller, veiliger en goedkoper in onderhoud.
De meeste ondernemers die mij deze vraag stellen, passen hun website minder dan ze denken. Ze gebruiken WordPress omdat ze ermee vertrouwd zijn, niet omdat ze het wekelijks nodig hebben. Als dat voor jou ook geldt, is het de moeite waard om de afweging opnieuw te maken.
Bij CanarySites bouwen we standaard met Next.js. We bouwen ook WordPress als een klant daar goede redenen voor heeft. Maar we zijn eerlijk over de consequenties voor snelheid, beveiliging en onderhoud. Vraag een gratis audit aan en ontdek waar de knelpunten in jouw huidige site zitten. Dat duurt een halfuur en geeft je concrete, bruikbare inzichten.