Pak een trage WordPress-site in deze volgorde aan: meet met PageSpeed Insights op mobiel en streef naar een LCP onder 2,5 seconden, INP onder 200 ms en CLS onder 0,1. Comprimeer daarna je afbeeldingen naar WebP van maximaal 200 kB, verwijder ongebruikte plugins, zet één caching-plugin aan, controleer of je op PHP 8.1 of hoger draait en upgrade pas als laatste je hosting.
Pak een trage WordPress-site in deze volgorde aan: meet met PageSpeed Insights op mobiel (doel: LCP onder 2,5 seconden, INP onder 200 ms, CLS onder 0,1), comprimeer je afbeeldingen naar WebP van maximaal 200 kB, verwijder ongebruikte plugins, zet één caching-plugin aan, controleer of je op PHP 8.1 of hoger draait en upgrade pas daarna je hosting. Een CDN en minify-instellingen komen als laatste, niet als eerste.
Even eerlijk vooraf
Een trage WordPress-site heeft bijna nooit één oorzaak. Het is een stapel: shared hosting van vier euro per maand, achttien plugins waarvan er zeven op elke pagina meedraaien, foto's die rechtstreeks uit de camera geüpload zijn, en een pagebuilder die eerst een halve bibliotheek aan CSS en JavaScript ophaalt voordat er iets op het scherm verschijnt.
Het grootste deel van de winst zit in drie of vier ingrepen die je zelf kunt doen, in een middag, voor nul euro. Daar staat tegenover: draait je site op een zware pagebuilder met dertig plugins, dan krijg je hem wel sneller, maar nooit meer écht licht. Dat is geen falen van jouw kant, dat is hoe die opbouw werkt.
Wat hieronder staat is de volgorde die ik aanhoud. Eerst meten, dan de goedkope winst, dan de server, en pas daarna de vraag of blijven sleutelen nog verstandig is.
Eerst meten: wat betekent "traag" hier?
"Traag" is een gevoel. Voor je iets aanraakt wil je cijfers, anders weet je straks niet of je ingreep iets deed. Gebruik PageSpeed Insights (pagespeed.web.dev), plak je URL erin en kijk naar het mobiele tabblad. Mobiel is strenger dan desktop en het is waar je bezoekers zitten.
De drie waarden waar Google op stuurt, de Core Web Vitals, hebben harde grenzen:
- LCP (Largest Contentful Paint) — hoe snel het grootste element in beeld staat. Goed is 2,5 seconden of sneller. Tussen 2,5 en 4 seconden is "verbetering nodig", boven 4 seconden slecht.
- INP (Interaction to Next Paint) — hoe snel de pagina reageert op een klik of tik. Goed is onder 200 ms.
- CLS (Cumulative Layout Shift) — hoeveel de pagina verspringt tijdens het laden. Goed is onder 0,1.
Kijk daarnaast naar de TTFB (Time to First Byte): de tijd voordat de server het eerste stukje antwoord stuurt. Google hanteert 800 ms als richtlijn voor "goed". Zit je daar structureel boven, dan is je probleem de server of het aantal database-queries per pagina, niet je afbeeldingen.
Meet minstens vier pagina's: je homepage, één dienstpagina, een blogartikel en je contactpagina. Die verschillen vaak flink, omdat er per pagina andere plugins meedraaien. Schrijf de waarden op vóór je begint. En let op het verschil tussen labdata (de simulatie die PageSpeed uitvoert) en velddata uit echte bezoeken — sites met weinig verkeer hebben simpelweg geen velddata, dan werk je met de simulatie.
Jagen op een score van 100 is zonde van je tijd. Een score van 75 op mobiel met een LCP van 2,1 seconden is een prima site. Wil je een bredere check dan alleen snelheid, dan kun je je pagina ook door de site-scanner halen; die kijkt ook naar structuur en techniek.
Waar de tijd blijft: vijf oorzaken
In de praktijk komt traagheid bij WordPress bijna altijd uit deze vijf hoeken, ongeveer in deze volgorde van impact:
- Afbeeldingen. Op de meeste MKB-sites zijn afbeeldingen veruit de zwaarste post. Een foto van 2 tot 4 MB rechtstreeks uit de camera of van een fotograaf is doodnormaal, terwijl dezelfde foto als WebP van 150 kB er op een scherm identiek uitziet.
- De server. Goedkope shared hosting deelt processorkracht met honderden andere sites. Een oude PHP-versie, geen server-side caching en een overvolle database maken dat merkbaar.
- Te veel plugins, of één zware. Het aantal telt minder dan wat ze doen. Twintig lichte plugins kunnen sneller zijn dan vijf die elk hun eigen CSS en JavaScript op élke pagina laden — ook op pagina's waar ze niets doen.
- Thema en pagebuilder. Een multipurpose-thema met een pagebuilder erbovenop levert diepe HTML-structuren en stapels stylesheets op. Dat is de moeilijkst op te lossen categorie.
- Externe scripts. Google Fonts, een chatwidget, een cookiebanner, tracking, een reviewwidget, een ingesloten YouTube-video. Elk daarvan haalt een externe server aan voordat jouw pagina af is.
Merk op dat vier van de vijf niets met "WordPress" te maken hebben. Dezelfde fouten maken een site op elk ander systeem net zo traag.
Wat je in één middag zelf kunt doen
Maak eerst een back-up. Werk daarna deze lijst van boven naar beneden af en meet na elke stap opnieuw.
- Afbeeldingen verkleinen. Schaal ze terug naar maximaal 1600 tot 2000 pixels breed voor grote beelden, sla ze op als WebP en mik op onder 200 kB voor een groot beeld en onder 100 kB voor de rest. Een compressieplugin doet dit in bulk voor je bestaande bibliotheek.
- Ongebruikte plugins verwijderen. Niet deactiveren — verwijderen. Gedeactiveerde plugins laten hun database-tabellen staan.
- Eén caching-plugin instellen. Eén, niet drie. Zet paginacaching aan en laat de agressieve opties eerst uit.
- Lazy loading controleren. WordPress laadt afbeeldingen sinds versie 5.5 standaard lazy. Zet lazy loading wél uit voor je eerste beeld boven de vouw, want dat is meestal precies je LCP-element.
- Lettertypen beperken. Twee families, maximaal drie gewichten, lokaal gehost in plaats van via een externe fontservice.
- Slider eruit. Sliders zijn zwaar en vrijwel niemand klikt door naar dia drie. Eén sterke afbeelding met een duidelijke knop doet het beter.
- Ingesloten video's vervangen. Zet een statische thumbnail neer die de video pas laadt na een klik. Dat scheelt vaak een megabyte aan scripts.
In veel gevallen zit je hierna al binnen de LCP-grens van 2,5 seconden. Zo niet, dan ligt het aan de server of aan de opbouw van je thema.
Hosting: waar het meestal blijft hangen
Hosting is de post waarop het hardst bezuinigd wordt en waar je het meest van merkt. De marktprijzen liggen ruwweg zo: eenvoudige shared hosting €3 tot €8 per maand, degelijke Nederlandse hosting €8 tot €15, managed WordPress-hosting €15 tot €40. Het verschil zit in gedeelde processorkracht, server-side caching, en of iemand voor je meekijkt.
Drie dingen die je zonder verhuizen kunt controleren:
- PHP-versie. Ga in WordPress naar Gereedschap → Sitediagnose. Draai je nog op PHP 7.x, vraag je host dan om 8.1 of hoger. Nieuwere PHP-versies verwerken dezelfde pagina merkbaar sneller. Test dit eerst op een staging-omgeving: verouderde plugins kunnen struikelen over PHP 8.
- Server-side caching. Veel hosts bieden dit aan in het controlepaneel. Staat het aan, dan kun je de paginacaching in je plugin vaak uitzetten en scheelt dat een laag.
- Serverlocatie. Zitten je klanten in Nederland en staat je server in de Verenigde Staten, dan betaal je bij elk bezoek reistijd. Verhuizen naar een Nederlandse of Duitse locatie helpt dan meer dan welke plugin ook.
De rekensom is simpel: €15 per maand extra is €180 per jaar. Als dat je TTFB van 1,4 seconden naar 400 ms brengt, is dat de goedkoopste snelheidswinst die er is. Wat de rest van een WordPress-site jaarlijks kost, heb ik uitgerekend in wat een WordPress-website écht kost.
Plugins opruimen zonder je site te slopen
Doe dit nooit rechtstreeks op je live site. Vraag je host om een staging-omgeving (bij managed hosting zit die er meestal bij) of maak eerst een volledige back-up die je met één klik kunt terugzetten.
De werkwijze:
- Maak een lijst van alle actieve plugins en zet er per stuk bij wat hij doet en waar je dat terugziet op de site.
- Alles waar je geen antwoord op weet, is verdacht. Deactiveer die één voor één en klik daarna je belangrijkste pagina's na.
- Meet na elke deactivatie opnieuw met PageSpeed Insights. Zo zie je welke plugin de echte kostenpost is.
- Verwijder wat je niet nodig hebt volledig, inclusief eventuele restdata.
- Vervang de zware blijvers. Een formulierplugin die op elke pagina zijn scripts laadt, kun je vaak vervangen door een lichtere of instellen dat hij alleen op de contactpagina laadt.
Wil je precies zien wat er per pagina gebeurt, dan geeft de gratis plugin Query Monitor je het aantal database-queries, de traagste queries en welke plugin welke scripts inlaadt. Boven de honderd queries op een gewone pagina is een signaal dat er iets te veel meedraait.
Wat je beter niet doet
- Drie optimalisatieplugins stapelen. Ze gaan elkaars werk overschrijven en je site wordt er onvoorspelbaar van. Kies er één.
- Alle minify-, combine- en defer-schakelaars in één keer aanzetten. Dit is de nummer één manier om je layout te breken. Eén optie tegelijk, daarna doorklikken en controleren.
- Jagen op 100/100. De laatste tien punten kosten meer uren dan de eerste veertig en je bezoeker merkt er niets van.
- Een CDN als eerste stap. Zit je publiek in Nederland en je server in Nederland, dan levert een CDN weinig op zolang je afbeeldingen nog 3 MB wegen.
- Sleutelen zonder nulmeting. Zonder cijfers vooraf weet je achteraf niet wat werkte, en zet je verbeteringen terug die wel degelijk hielpen.
- Denken dat snelheid je probleem oplost. Een snelle site die geen duidelijke route naar een aanvraag heeft, levert nog steeds niets op. Daarover schreef ik waarom een mooie website geen klanten oplevert.
Wanneer opknappen niet meer loont
Op een gegeven moment ben je meer geld kwijt aan reparatie dan aan nieuwbouw. Een optimalisatieronde door een freelancer kost ruwweg vier tot acht uur. Bij een freelance-uurtarief van €60 tot €95 kom je op €250 tot €750; is je site zwaar en verouderd, dan loopt dat op naar €600 tot €1.500 — en dan hangt het resultaat nog steeds aan de bestaande fundering.
Deze signalen wijzen richting opnieuw bouwen:
- Je thema krijgt al meer dan een jaar geen updates meer.
- Je durft plugins niet meer te updaten, omdat er dan iets breekt.
- Je hebt meer dan 25 actieve plugins en niemand weet nog waarom.
- De site is vijf jaar of ouder en is sindsdien alleen maar aangebouwd.
- Je content zit vast in een pagebuilder waar je zonder die plugin niets meer van terugziet.
Bij Klyo begint een volledige B2B-website bij €1.950 en is hij in ongeveer twee weken live. Wil je je huidige inhoud en posities behouden, dan is een redesign met dezelfde URL's en 301-redirects vanaf €795 vaak de verstandigere route. Wat je precies krijgt voor welk bedrag, staat naast elkaar in goedkope of dure website: wat is het verschil.
Snelheid telt overigens niet alleen voor Google. Crawlers van AI-zoekmachines hebben ook geduldgrenzen en een site die traag reageert of half laadt, is lastiger te lezen. Hoe je dat kant op orde brengt, staat in GEO-optimalisatie.
Conclusie
- Meet eerst op mobiel met PageSpeed Insights en noteer LCP, INP, CLS en TTFB van vier pagina's.
- Streefwaarden: LCP onder 2,5 seconden, INP onder 200 ms, CLS onder 0,1, TTFB onder 800 ms.
- Begin bij de afbeeldingen: WebP, maximaal 1600 tot 2000 pixels breed, onder 200 kB. Daar zit meestal de meeste winst.
- Verwijder ongebruikte plugins volledig en gebruik één caching-plugin, geen drie.
- Controleer je PHP-versie (8.1 of hoger) en overweeg hosting van €15 tot €40 per maand als je TTFB hoog blijft.
- Doe plugin-opruiming op staging, één plugin per keer, en meet na elke stap.
- Zit je boven de 25 plugins, op een verouderd thema of een pagebuilder waar je niet uit komt, dan is nieuwbouw vanaf €1.950 of een redesign vanaf €795 goedkoper dan blijven repareren.
Weet je na het meten niet welke van de twee routes voor jouw site logisch is? Stuur je URL door via het gratis voorbeeld, dan kijk ik naar de cijfers en zeg ik eerlijk of opknappen genoeg is.
Veelgestelde vragen
Waarom is mijn WordPress-site zo traag?
In de meeste gevallen door een combinatie van te zware afbeeldingen, goedkope shared hosting, te veel of te zware plugins en een pagebuilder die veel extra CSS en JavaScript laadt. Afbeeldingen zijn op de meeste MKB-sites de zwaarste post: een foto rechtstreeks uit de camera weegt al snel 2 tot 4 MB, terwijl dezelfde foto als WebP van 150 kB er identiek uitziet.
Wat is een goede laadtijd voor een website?
Google hanteert als grens dat de Largest Contentful Paint binnen 2,5 seconden moet vallen, de Interaction to Next Paint onder 200 milliseconden moet blijven en de Cumulative Layout Shift onder 0,1. Voor de servertijd (Time to First Byte) geldt 800 milliseconden als richtlijn. Meet altijd op mobiel, want dat is strenger dan desktop.
Helpt een caching-plugin om WordPress sneller te maken?
Ja, maar alleen als eerste laag en met één plugin tegelijk. Meerdere optimalisatieplugins naast elkaar overschrijven elkaars werk en breken vaak de layout. Zet paginacaching aan, laat agressieve opties zoals combineren en uitstellen van scripts eerst uit en schakel die daarna één voor één in, met een controle na elke stap.
Wanneer kun je beter een nieuwe website laten bouwen dan optimaliseren?
Als je thema geen updates meer krijgt, je plugins niet meer durft te updaten, je boven de 25 actieve plugins zit of je content vastzit in een pagebuilder. Een optimalisatieronde kost al snel €250 tot €1.500 en werkt op een bestaande fundering, terwijl een nieuwe B2B-website vanaf €1.950 begint en een redesign met behoud van URL's vanaf €795.
Maakt een langzame website uit voor vindbaarheid in Google en AI?
Voor Google zijn de Core Web Vitals onderdeel van de beoordeling van pagina-ervaring, waarbij relevantie zwaarder weegt dan snelheid alleen. Voor crawlers van AI-zoekmachines geldt dat een site die traag of half laadt lastiger volledig te lezen is. Snelheid is dus geen ranking-truc, maar wel een voorwaarde om überhaupt goed meegenomen te worden.
Bronnen
- Core Web Vitals and Google Search results — Google Search Central
- Web Vitals — web.dev (Google)
- PageSpeed Insights — Google
- WordPress Documentation — WordPress.org
Eerst weten waar het aan ligt
Stuur je URL door en je krijgt een nuchtere analyse: welke drie ingrepen bij jouw site het meeste opleveren, en of opknappen of opnieuw bouwen goedkoper uitpakt. Reactie binnen één werkdag.
Plan een gesprek