Trage website oplossen: de volgorde die werkt

Kort antwoord

Los een trage website op in deze volgorde: meet eerst met PageSpeed Insights op mobiel en noteer je LCP, INP, CLS en TTFB. Comprimeer daarna je afbeeldingen naar WebP van maximaal 200 kB en 1600 tot 2000 pixels breed — daar zit op de meeste MKB-sites veruit de meeste winst. Verwijder ongebruikte plugins volledig, 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.

De streefwaarden waar je op mikt: LCP onder 2,5 seconden, INP onder 200 milliseconden, CLS onder 0,1 en TTFB onder 800 milliseconden. Haal je die, dan is je site snel genoeg. Jagen op een score van 100 kost meer uren dan de eerste veertig punten en je bezoeker merkt er niets van.

Stap 1: meten, wat betekent traag

"Traag" is een gevoel. Voor je iets aanraakt wil je cijfers, anders weet je straks niet of je ingreep iets deed — en zet je per ongeluk een verbetering terug die wél hielp.

Ga naar 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 — níet je afbeeldingen. Dat onderscheid bespaart je een middag aan verkeerd werk.

Meet meerdere pagina's, niet alleen je homepage

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. Een formulierplugin die alleen op je contactpagina zichtbaar is, laadt zijn scripts soms overal.

Let ook op het verschil tussen labdata (de simulatie die PageSpeed uitvoert) en velddata uit echte bezoeken van Chrome-gebruikers. Sites met weinig verkeer hebben simpelweg geen velddata; dan werk je met de simulatie en is de trend belangrijker dan de absolute score.

De vijf oorzaken van traagheid

In de praktijk komt traagheid bij WordPress bijna altijd uit deze vijf hoeken, ongeveer in deze volgorde van impact:

1. Afbeeldingen. Op de meeste MKB-sites 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.
2. 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 in je TTFB.
3. 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 waar ze niets doen.
4. Thema en pagebuilder. Een multipurpose-thema met een pagebuilder erbovenop levert diepe HTML-structuren en stapels stylesheets op. Dit is de moeilijkst op te lossen categorie, omdat het in de fundering zit.
5. 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.

Vier van de vijf hebben niets met WordPress te maken. Dezelfde fouten maken een site op Webflow, Squarespace of een maatwerkbouw net zo traag. Het systeem is zelden de boosdoener; de opbouw is dat wel.

Stap 2: wat je in één middag zelf doet

Maak eerst een back-up. Werk daarna deze lijst van boven naar beneden af en meet na elke stap opnieuw.

• Afbeeldingen verkleinen. Schaal terug naar maximaal 1600 tot 2000 pixels breed voor grote beelden, sla 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 en blijven je back-ups opblazen.
• 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 — anders vertraag je het beeld waar je op wordt afgerekend.
• 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, ook voor conversie.
• 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 — en dan ga je door naar stap 3.

Stap 3: hosting en PHP

Hosting is de post waarop het hardst wordt bezuinigd 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 kunt controleren zónder te verhuizen:

• 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 die alleen maar in de weg zit.
• 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. Brengt dat je TTFB van 1,4 seconden naar 400 ms, dan is het de goedkoopste snelheidswinst die er bestaat — want het werkt op élke pagina tegelijk, zonder dat je iets aan je site hoeft te veranderen. Wat de rest van een WordPress-site jaarlijks kost, heb ik uitgerekend in wat een WordPress-website écht kost.

Stap 4: plugins opruimen zonder brokken

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:

1. 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.
2. Deactiveer die verdachte plugins één voor één en klik daarna je belangrijkste pagina's na.
3. Meet na elke deactivatie opnieuw met PageSpeed Insights. Zo zie je welke plugin de echte kostenpost is in plaats van wie de schuld krijgt.
4. Verwijder wat je niet nodig hebt volledig, inclusief eventuele restdata.
5. 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 te veel meedraait.

Wat je beter niet doet

• Drie optimalisatieplugins stapelen. Ze overschrijven elkaars werk 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 score van 75 op mobiel met een LCP van 2,1 seconden is een prima site.
• Een CDN als eerste stap. Zit je publiek in Nederland en je server ook, dan levert een CDN weinig op zolang je afbeeldingen nog 3 MB wegen.
• Sleutelen zonder nulmeting. Zonder cijfers vooraf weet je achteraf niets.
• Denken dat snelheid je probleem oplost. Een snelle site zonder duidelijke route naar een aanvraag 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 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 adressen houden, 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, en hoe lang zo'n traject loopt lees je in hoe lang duurt een website laten maken.

Wat snelheid doet voor Google en AI

Snelheid is geen ranking-truc. Google gebruikt de Core Web Vitals als onderdeel van de beoordeling van pagina-ervaring, maar relevantie weegt zwaarder: een trage pagina met het beste antwoord verslaat nog steeds een snelle pagina met een slecht antwoord. Wat snelheid wél doet, is het verschil maken tussen twee pagina's die inhoudelijk aan elkaar gewaagd zijn.

Voor AI-zoekmachines ligt het net iets anders. Crawlers die content ophalen voor ChatGPT of andere assistenten hebben geduldgrenzen. Laadt je pagina traag, of staat de inhoud pas na het uitvoeren van JavaScript in beeld, dan is de kans groter dat er een halve pagina wordt gelezen — of helemaal niets. Dat is een harder probleem dan twee posities zakken in Google, want je verdwijnt dan volledig uit het antwoord. Hoe je dat kant op orde brengt, staat in GEO voor MKB.

Checklist in het kort

• Meet op mobiel met PageSpeed Insights en noteer LCP, INP, CLS en TTFB van vier pagina's.
• Streefwaarden: LCP onder 2,5 s, INP onder 200 ms, CLS onder 0,1, TTFB onder 800 ms.
• Begin bij de afbeeldingen: WebP, 1600 tot 2000 pixels breed, onder 200 kB.
• Verwijder ongebruikte plugins volledig en gebruik één caching-plugin, geen drie.
• Zet lazy loading uit voor het eerste beeld boven de vouw.
• Controleer je PHP-versie (8.1 of hoger) en overweeg hosting van €15 tot €40 per maand bij een hoge TTFB.
• Ruim plugins op in staging, één per keer, en meet na elke stap.
• Boven de 25 plugins, 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, dan kijk ik naar de cijfers en zeg ik eerlijk of opknappen genoeg is.

Veelgestelde vragen

Waarom is mijn WordPress-site zo traag?

Meestal 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 valt, de Interaction to Next Paint onder 200 milliseconden blijft 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 een trage website 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 euro en werkt op een bestaande fundering, terwijl een nieuwe B2B-website vanaf 1.950 euro begint en een redesign met behoud van URL's vanaf 795 euro.

Maakt een trage 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 goed meegenomen te worden.

Bronnen

• PageSpeed Insights — Google
• Core Web Vitals — Google (web.dev)
• Largest Contentful Paint (LCP) — Google (web.dev)
• WordPress Support: Optimization — WordPress.org