Een trage WordPress-website los je op door eerst te meten waar de tijd zit: in de serverreactietijd (TTFB, de tijd tot de eerste byte van de pagina) of in alles wat daarna komt. Zit de TTFB steeds boven ongeveer een halve seconde, dan ligt de oorzaak op de server: geen werkende paginacache, verkeerde PHP-instellingen, een database die te veel werk doet of bots die de serverprocessen bezet houden. Is de TTFB laag en voelt de site toch traag, dan zit het in de site zelf: plugins, thema, afbeeldingen of externe scripts. Wordt een site traag na een update of een verhuizing naar een andere hoster, dan zijn de gebruikelijke schuldigen een cache die uitstaat, een andere PHP-versie of een configuratie die nog naar de oude server wijst.
Correcthosting in Beverwijk, hostingbedrijf sinds 2006 met zo'n 1000 mkb-klanten in heel Nederland, doet dit meetwerk zelf, en het meeste snelheidswerk gebeurt op de server, niet in WordPress. In september 2026 ging op 24 websites de serverreactietijd van ongeveer 1,2 seconde naar ongeveer 0,12 seconde door alleen de paginacache op de server aan te zetten. Snelheidsoptimalisatie kost vanaf € 99 eenmalig, exclusief btw, met een meting vooraf en achteraf; bij vragen krijg je Dennis Fransen zelf, 24/7 via WhatsApp of telefoon.
Hoe meet je in twee minuten of het aan de server of aan de site ligt?
Open je site in Chrome of Firefox, druk op F12 en kies het tabblad Netwerk. Laad de pagina opnieuw en klik op de bovenste regel, het HTML-document zelf. Onder "Timing" staat hoelang de browser wachtte op het eerste antwoord van de server: dat is de TTFB. Blijft die onder de halve seconde en duurt het toch seconden voordat de pagina staat, dan zit de tijd in wat daarna binnenkomt: scripts, stylesheets, afbeeldingen, lettertypen. Onderaan het tabblad staan het aantal verzoeken en de totale omvang.
Doe de meting drie keer.
- Uitgelogd én ingelogd. Ingelogde bezoekers krijgen geen pagina uit de cache. Is de site in een privévenster snel en als beheerder traag, dan werkt de cache en is de site eronder zwaar; even traag in beide gevallen betekent dat er geen cache in het spel is.
- Een kale pagina. Is een pagina met bijna niets erop, zoals de privacyverklaring, net zo traag als de homepage, dan zit de vertraging in wat op elke pagina meedraait: plugins, thema, server. Is alleen de homepage traag, dan zit het in sliders, feeds of ingesloten video's.
- Twee keer achter elkaar. De eerste keer bouwt de server de pagina op en zet hem in de cache; de tweede keer hoort hij eruit te komen. Is de tweede keer niet duidelijk sneller, dan cachet er niets.
Met een terminal kan dezelfde meting zonder browser:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" -H "Accept: text/html" https://jouwdomein.nl/
Die Accept-header is geen versiering: zonder die header leveren sommige caches een verse pagina in plaats van de kopie, en dan meet je de langzame route die je bezoekers nooit zien.
Welke vijf oorzaken zitten op de server?
In ons beheer is een hoge TTFB vrijwel altijd een van deze vijf.
Geen paginacache, of een cache die na de verhuizing uitstaat. Zonder paginacache start voor elke bezoeker PHP op, laden alle plugins en gaan er tientallen query's naar de database, terwijl het resultaat voor bijna iedereen identiek is. Met een cache op de server wordt de pagina één keer gebouwd en daarna als kopie geleverd; dat is het verschil uit de meting hierboven. Na een verhuizing gaat dit vaak stilzwijgend stuk: de cache-plugin was ingesteld op de cache van de oude server, en die bestaat op de nieuwe niet.
Een object cache die niets doet. Een object cache zoals Redis houdt databaseresultaten in het werkgeheugen. Klopt het adres van de Redis-server niet, dan valt WordPress zonder foutmelding terug op de database: geen melding, geen fout, gewoon een cache die niets doet. De koppelplugin hoort "verbonden" te melden en het aantal treffers in het statusscherm hoort te stijgen; controleer allebei.
wp-cron die bijna elke minuut afgaat. WordPress heeft geen eigen klok; geplande taken draaien mee met bezoekers: bij elk bezoek kijkt WordPress of er een taak wacht, en op een drukke site met veel plugins wacht er bijna altijd wel een. Bij een site in ons beheer was dat ongeveer twee keer per minuut, elke keer met een volledige WordPress-start. Zet wp-cron in wp-config.php uit met DISABLE_WP_CRON en laat een systeemcron hem om de paar minuten aanroepen.
Bots en scrapers die de PHP-processen vullen. Een server heeft een vast aantal PHP-processen; zijn die allemaal bezet, dan wacht de volgende bezoeker. Een scraper of AI-crawler die honderden dynamische verzoeken per vijf minuten doet op zoekpagina's en filter-URL's, die nooit uit de cache komen, houdt zo een hele server bezig. Blokkeren of afremmen gebeurt op de server, niet in WordPress.
Een te oude PHP-versie, of een andere dan vóór de verhuizing. Een nieuw account krijgt de standaardversie van die server, en die kan ouder zijn dan wat je had; kijk in WordPress onder Gereedschap, Sitediagnose, tab Info, bij Server. Wat een overstap omhoog oplevert en hoe je die veilig test, staat in WordPress veilig up-to-date houden; een verouderd thema kan op een nieuwe versie omvallen met een 500-fout.
Welke oorzaken zitten in de site zelf?
Is de serverreactietijd in orde, dan zit de vertraging in wat WordPress per pagina doet en in wat de browser daarna moet ophalen.
Plugins met zware query's. Installeer tijdelijk Query Monitor. Die laat per pagina zien hoeveel databasequery's er zijn gedaan, hoelang ze duurden en welke plugin ze veroorzaakte; sorteer in het paneel "Queries by Component" op tijd, dan staat de boosdoener bovenaan. Statistiekenplugins die bij elk bezoek schrijven en gerelateerde-berichten-plugins zien we hier vaak. Haal Query Monitor daarna weer weg, hij kost zelf ook tijd.
Thema's die alles laden. Veel thema's en pagebuilders laden op elke pagina hun volledige set stylesheets en scripts, ook voor onderdelen die je nergens gebruikt: tientallen bestanden uit dezelfde thema-map in het tabblad Netwerk. De meeste builders hebben een instelling om alleen te laden wat op de pagina staat.
Afbeeldingen in de verkeerde maat, of een opgeblazen pagina. Kijk in het tabblad Netwerk naar de kolom Grootte: staat er bij één plaatje meer dan een megabyte, dan wordt daar een origineel geleverd waar een tussenmaat had gemoeten; WordPress maakt die tussenmaten zelf aan, maar een thema of pagebuilder kiest soms toch het origineel. Kijk ook naar de omvang van het HTML-document zelf: een pagina van meerdere megabytes zonder zware afbeeldingen wijst op iets wat in de HTML wordt meegeleverd, zoals duizenden spam-reacties of trackbacks (een voorbeeld staat in WordPress-onderhoud uitbesteden).
Externe scripts. Vink in het tabblad Netwerk het filter voor verzoeken van derden aan: alles wat daar staat, laadt van een server waar jij niets aan kunt versnellen. Wat er in een half jaar bij is gekomen en niets meer oplevert, haal je weg; wat blijft, laadt uitgesteld.
Te veel redirects. Van http naar https, van zonder naar met www, van zonder naar met slash: elke stap is een extra rondreis voordat de pagina begint, en na een verhuizing komt er vaak een stap bij omdat de nieuwe server zijn eigen omleiding toevoegt. In het tabblad Netwerk zie je ze als regels met status 301 of 302 boven de uiteindelijke 200. Eén omleiding is normaal, drie op een rij niet.
Waarom is een site na een verhuizing ineens traag?
Een verhuizing verandert meer dan alleen de server, en elke verandering kan een snelle site traag maken.
De DNS wijst nog deels naar de oude server. Oude DNS-antwoorden blijven na het omzetten een tijd geldig, en in die uren komt een deel van de bezoekers nog op de oude server terecht, die inmiddels misschien is afgeknepen. Een vergeten AAAA-record is een aparte valkuil: bezoekers via IPv6 komen dan blijvend op de oude server terwijl alle anderen al op de nieuwe zitten.
De cache is niet meeverhuisd. Serverbrede cache is een instelling van de server, niet van de site: op de oude hoster stond hij aan zonder dat je het wist, op de nieuwe staat hij uit. Vraag je nieuwe hoster welke cache er voor jouw site actief is.
De PHP-versie is anders. Een account op een nieuwe server krijgt de standaardversie van die server: ouder betekent trager, nieuwer kan een verouderd thema laten omvallen.
De configuratie wijst nog naar de oude server. Een site in ons beheer had na de verhuizing nog het oude serverpad in de configuratie staan; de thema-CSS gaf daardoor een 404 en de site kwam kaal binnen, terwijl de homepage zelf een keurige 200 gaf. Controleer na een verhuizing de instelling upload_path (die hoort leeg te zijn) en vervang het oude serverpad in de database; de juiste volgorde staat in website verhuizen zonder downtime.
Waarom lijkt een site na een update traag, terwijl hij het niet is?
Na een update van WordPress, een plugin of het thema lijkt een site vaak een dag traag of kapot terwijl er niets mis is.
De browser houdt oude bestanden vast. De stylesheets en scripts zijn veranderd, maar je browser gebruikt nog de versies die hij eerder opsloeg: een pagina die scheef staat, knoppen die niet reageren, of traagheid omdat oude en nieuwe onderdelen door elkaar laden. Test in een privévenster of op een ander apparaat; hoe dat zit, staat in browsercache legen: website lijkt nog oud.
De cache is leeg. Een update maakt de paginacache terecht leeg, want de pagina's zijn veranderd. De eerste bezoeker van elke pagina krijgt daarna de langzame opbouw, alle volgende weer de kopie. Meet dus de tweede keer, niet de eerste.
Updates zijn vaker de oplossing dan de oorzaak: een 500-fout door een bug in een oudere WordPress-versie verdwijnt met de update, niet met wachten. Wie updates uitstelt omdat het na de vorige zo traag leek, ruilt een dag browsercache in voor maanden aan echte problemen.
Wat doe je zelf, en wanneer bel je iemand?
Zelf kun je alles hierboven meten en een flink deel oplossen: TTFB uitgelogd en ingelogd vergelijken, cache-plugin en PHP-versie nakijken, met Query Monitor de zware plugin vinden, afbeeldingen verkleinen, externe scripts opruimen. Verander één ding per keer en meet na elke stap.
Bel iemand zodra de oorzaak op de server zit en jij daar niet bij kunt: paginacache op serverniveau, Redis, PHP-instellingen, het aantal PHP-processen, een systeemcron voor wp-cron en het blokkeren van scrapers zijn werk van de hoster.
Bij Correcthosting werkt dat zo: meten vooraf, het werk vooral op de server (caching, PHP-instellingen, database), daarna opnieuw meten. Dat kost vanaf € 99 eenmalig, exclusief btw. Levert het niets op, dan hoor je dat ook. Omdat het meeste werk op de server gebeurt, draait de site daarvoor bij voorkeur bij ons; verhuizen is gratis en gebeurt zonder downtime, en de aanpak staat op snelheidsoptimalisatie. Heb je een webshop, lees dan ook trage WooCommerce-shop versnellen; daar spelen winkelwagen en checkout een eigen rol.