WordPress website traag? Zo vind je de oorzaak

Een WordPress website traag krijgen is makkelijk. Je installeert een paginabouwer, een slider, een chatknop, een cookiebanner en twintig plugins, en ergens onderweg duurt elke pagina drie seconden langer. Niemand deed iets fout. Alles kwam er gewoon bij, en daarom merkt niemand het. In dit artikel lees je hoe je meet of je site echt traag is, wat de zeven bekendste oorzaken zijn en wat je zelf kunt doen. En ook wanneer sneller maken niet meer helpt.

Ik ben Yassine Seghrouchni van Your Tech Club in Amsterdam. We onderhouden bestaande WordPress-sites en bouwen nieuwe sites op maat. Dat betekent dat we beide kanten kennen: het geduldige oplappen, en het moment waarop opnieuw bouwen goedkoper is.

Hoe meet je of je WordPress-site echt traag is?

Meet je site met Google PageSpeed Insights of het rapport Core Web Vitals in Google Search Console, en kijk vooral naar mobiel. Google noemt een pagina goed als de grootste inhoud binnen 2,5 seconden staat, de pagina binnen 200 milliseconden reageert op een klik en er weinig verspringt. Je eigen laptop op kantoor is geen meetlat.

Die drie maten heten de Core Web Vitals:

• LCP (Largest Contentful Paint): hoe snel het grootste blok in beeld staat. Goed is binnen 2,5 seconden.
• INP (Interaction to Next Paint): hoe snel de pagina reageert als iemand klikt of typt. De grens ligt op 200 milliseconden.
• CLS (Cumulative Layout Shift): hoeveel de pagina verspringt tijdens het laden. Daar is 0,1 of minder de norm.

Google meet dat bij het 75e percentiel van de bezoeken, apart voor mobiel en desktop (web.dev, Web Vitals, bijgewerkt oktober 2024). Dus niet je snelste bezoek, maar een bezoek dat langzamer is dan driekwart van de rest. Vaak is dat iemand op een telefoon in de trein.

Een tip: meet niet alleen je homepage. Meet ook je drukst bezochte dienstpagina en je contactpagina, want daar beslist een bezoeker of hij iets doet. Snelheid is overigens maar één kant van gevonden worden; de andere kant lees je in vindbaar in Google en AI-zoekmachines.

Wat zijn de oorzaken van een trage WordPress-site?

De zeven bekendste oorzaken zijn te veel plugins, een zware paginabouwer of thema, grote afbeeldingen, te krappe hosting, geen caching, externe scripts zoals chat en tracking, en een verouderde server of volle database. Meestal is het een combinatie. Daarom helpt één snelheidsplugin zelden genoeg.

1. Te veel plugins. Elke plugin laadt zijn eigen code, en vaak op elke pagina, ook waar hij niets doet.
2. Een zware paginabouwer of thema. Paginabouwers maken het bouwen makkelijk, maar ze laden daarvoor wel veel extra code mee.
3. Grote afbeeldingen. Een foto van 5 MB die als miniatuur wordt getoond, blijft 5 MB groot.
4. Te krappe hosting. Een goedkoop pakket op een volle server betekent dat je wacht op je buren.
5. Geen caching. Zonder caching bouwt WordPress elke pagina bij elk bezoek opnieuw op uit de database.
6. Externe scripts. Chatknoppen, tracking, lettertypen en video's van andere diensten. Elk script vraagt bovendien een extra verbinding.
7. Verouderde server of volle database. Een oude PHP-versie, of een database vol oude revisies en restjes van verwijderde plugins.

Wat je bij oudere WordPress-sites vaak ziet, is een combinatie van de eerste twee: een paginabouwer plus een rij plugins die op elke pagina laden. Meet daarom eerst, voordat je iets weghaalt.

Hoe vind je welke plugin je WordPress-site vertraagt?

Dat vind je door in een kopie van je site plugins één voor één uit te zetten en na elke stap opnieuw te meten. Zie je een flinke sprong, dan heb je een verdachte. Doe dit nooit op je live site, want een uitgeschakelde plugin kan een formulier, een betaalstap of je hele menu laten verdwijnen.

De werkwijze is simpel, maar wel geduldwerk:

1. Maak een kopie van je site in een testomgeving. Veel hostingpartijen hebben daar een knop voor.
2. Meet de kopie drie keer en noteer het gemiddelde. Eén meting zegt weinig, want de uitkomst schommelt.
3. Zet één plugin uit, meet opnieuw en noteer het verschil.
4. Zet hem weer aan en ga door naar de volgende.

Na een uur weet je meestal welke twee of drie plugins het meeste kosten. Vervolgens is de vraag of je ze nodig hebt, of dat er een lichtere oplossing is. Soms blijkt een plugin alleen nodig voor één pagina. Dan laat je hem ook alleen daar laden.

Lukt dit niet zelf, of heb je geen testomgeving? Dan is dat meteen een teken dat je onderhoud beter geregeld kan worden.

Wat kun je zelf vandaag doen tegen een trage WordPress-site?

Begin bij de dingen die weinig risico hebben: afbeeldingen verkleinen, ongebruikte plugins verwijderen, caching aanzetten en externe scripts kritisch bekijken. Maak eerst een back-up en test daarna je formulieren. Dat levert vaak al een merkbaar verschil op, zonder dat je iets aan je thema hoeft te veranderen.

Een praktische volgorde:

• Maak een back-up, los van je server. Snelheidsaanpassingen breken soms een formulier of een menu.
• Verwijder plugins die je niet gebruikt. Ook uitgeschakelde plugins horen weg.
• Verklein en comprimeer afbeeldingen, bij voorkeur naar WebP. Upload ze voortaan op het formaat waarop ze getoond worden.
• Zet caching aan via je hosting of één caching-plugin.
• Kijk naar externe scripts. Heb je die chatknop, die tweede analytics-tool en drie lettertypen echt nodig?
• Vraag je hosting naar de PHP-versie. Draai je nog op een versie die geen beveiligingsupdates meer krijgt, dan heb je naast snelheid ook een veiligheidsprobleem.

Wat ik níet zou doen: drie snelheidsplugins tegelijk installeren. Ze bijten elkaar, en je hebt er drie plugins bij. Precies het probleem waar je mee begon.

Mijn advies: meet voor en na elke stap met PageSpeed Insights, op mobiel, en noteer de uitkomst. Dan weet je welke stap echt iets opleverde en welke je had kunnen overslaan.

Wanneer helpt WordPress sneller maken niet meer?

Als de traagheid in de basis zit. Een site die gebouwd is op een zware paginabouwer met tientallen plugins, kun je oppoetsen, maar niet echt snel maken. Elke verbetering kost dan uren en houdt tot de volgende update. Op dat punt is opnieuw bouwen op een snellere basis vaak goedkoper dan blijven sleutelen.

Je herkent dat moment aan een paar dingen. Zo blijven de metingen rood, ook na caching en kleinere afbeeldingen. Elke plugin-update maakt het weer iets erger. Ook zegt je developer dat het thema "nou eenmaal zo werkt".

Dan helpt een andere opbouw dus meer dan nog een plugin. Een site met Next.js en een headless CMS kan pagina's vooraf klaarzetten, zodat een bezoeker niet wacht op een database. Hoe dat werkt, lees je in wat een headless CMS is. En of je overstapt of op WordPress blijft, bespreek ik in WordPress maatwerk of een maatwerk website. Alle routes naast elkaar, ook zonder maatwerk, staan bij de alternatieven voor WordPress.

Eerlijk is eerlijk: een maatwerk-site is niet vanzelf snel. Ook in Next.js kun je een trage site bouwen, met te grote afbeeldingen en tien externe scripts. Het verschil is dat je bij een goede bouw minder ballast meekrijgt.

Hoe snel is een site op een andere basis?

Een voorbeeld met echte cijfers. Voor een growth-hackingbureau bouwden we een platform met Next.js en Strapi, als opvolger van een site in Framer. In PageSpeed Insights scoorde de homepage op 13 oktober 2026 een 100 op desktop en een 99 op mobiel voor prestaties (de case). Dat was geen WordPress-site, maar het laat zien wat een lichte basis kan doen.

Zo'n score is een meting op één dag, op één pagina. Hij zegt niets over jouw site. Wil je het verschil voor je eigen site weten? Dan beginnen we met een nulmeting van je huidige WordPress-site. Pas als blijkt dat sneller maken niet meer genoeg helpt, praten we over je WordPress website vernieuwen.

Hoe houd je je WordPress-site snel?

Door snelheid te meten zoals je updates doet: vast, elke maand. Want elke nieuwe plugin, elk extra script en elke grote foto maakt je site een beetje trager. Wie maandelijks meet, ziet het op tijd. Wie het nooit meet, merkt het pas als aanvragen teruglopen.

Bij ons WordPress onderhoud letten daarom meerdere monitoringtools op bereikbaarheid, snelheid en afwijkingen. Een website-agent loopt versies en meldingen na, en een developer beslist wat er gebeurt. Updates gaan eerst naar een testomgeving, zodat een snelheidsprobleem daar opvalt en niet bij je bezoekers. Meer over die aanpak staat bij website-onderhoud met een SLA.

Is je WordPress website traag geworden direct na een update? Kijk dan eerst wat er veranderde, voordat je iets nieuws installeert. Vaak is het één plugin die een nieuwe functie meebracht, bijvoorbeeld een extra script op elke pagina. Zet die update in een testomgeving terug, meet opnieuw en beslis daarna pas.

Binnenkort kun je ook zelf een eerste meting doen met onze gratis WordPress-check. Je vult je URL in en ziet onder andere welke plugins je draait, welke updates achterlopen en hoe snel je site laadt.