Serhii LypiiEen WordPress website traag oplossen begint bijna nooit bij een plugin, terwijl het advies dat je overal leest precies dat is. Installeer WP Rocket, zet een CDN aan, gooi er een lazy-load tegenaan. Klaar, klant tevreden. Tot het twee weken later weer traag is en niemand meer weet waarom.
In mijn ervaring lossen die quick-fixes zelden de kern op. Ze leggen een laag over een dieper probleem. Eerst meten waar de vertraging zit, dan gericht ingrijpen: dat scheelt uren werk en levert snelheidswinst op die blijft staan.
Waarom de meeste snelheidsadviezen voor WordPress mislukken
De meeste blogs over traagheid beginnen bij oplossingen. “Tien tips voor een snellere site”. Cache aan, plaatjes klein, JavaScript laden uitgesteld. Dat klinkt logisch, maar het slaat de eerste stap over: weten wat er traag is.
Een site die 3,5 seconden laadt heeft een ander probleem dan een site die binnen 800 ms laadt maar lang bezig blijft. Bij de eerste zit de tijd in de server of in een onbruikbare plugin. Bij de tweede zit hij in scripts of in een te zwaar thema. Eén oplossing voor beide situaties bestaat niet.
Daar komt bij dat veel adviezen geschreven zijn door partijen die een plugin verkopen, een hostingpakket promoten, of nieuwsbrief-leads willen. Die hebben er belang bij dat jij denkt: “dit is de oplossing”. Een eerlijke diagnose duurt langer en levert minder klikken op.
WordPress website traag oplossen begint bij meten
Voordat ik iets aanraak op een site, draai ik drie tests. Samen vertellen ze of het probleem bij de server zit, bij de pagina, of bij de bezoeker-kant.
PageSpeed Insights geeft je de Core Web Vitals zoals Google ze ziet. LCP onder de 2,5 seconden is goed, tussen 2,5 en 4 seconden vraagt om actie, en boven de 4 seconden is slecht. INP heeft sinds maart 2024 FID vervangen als Core Web Vital en meet hoe snel je site reageert op interactie. Boven de 200 ms vraagt om actie, boven 500 ms is slecht.
GTmetrix of WebPageTest voegt waterfall-data toe. Daar zie je per request hoe lang hij duurde en in welke volgorde dingen laden. Niet alles is even belangrijk, maar als een derde-partij-script vooraan in de lijst staat te wachten op een trage DNS-lookup, weet je waar je hoofdpijn vandaan komt.
TTFB is de meest onderschatte metric. Time to First Byte: de tijd tussen je request en het eerste byte van het antwoord. Voor WordPress mik je op onder de 600 ms, ideaal onder de 300 ms. Een hoge TTFB betekent: de server denkt te lang na. Voor je iets aan plaatjes of scripts gaat optimaliseren is dat het eerste signaal.
Wat PageSpeed Insights, GTmetrix en Query Monitor je écht vertellen
PageSpeed Insights laat field data en lab data zien. Field data komt van echte bezoekers via Chrome User Experience Report. Lab data is een test in een gecontroleerde omgeving. Die twee verschillen vaak, en het is veelzeggend welke je bekijkt.
Als field data zegt dat je site goed presteert maar lab data slecht, dan zien echte bezoekers iets anders dan de test. Meestal omdat je publiek via een snel netwerk binnenkomt of omdat veel zaken gecached zijn. Andersom (lab goed, field slecht) wijst op een probleem dat alleen onder echte load optreedt.
Query Monitor is wat mij betreft de eerlijkste plugin om naar trage WordPress te kijken. Gratis, installeren, in admin de balk bovenaan openen. Hij toont per pagina welke queries draaiden, hoe lang ze duurden, en welke plugin ze veroorzaakte. Een plugin die op één paginahit honderd queries afvuurt is een rode vlag, ongeacht hoe goed hij is verkocht.
In Chrome DevTools (F12, Network-tab) zie je de waterfall in real-time. Sorteer op duur en je weet binnen één minuut wat de bottleneck is. Dat hoef je niet als developer te zijn om te lezen.
De vier hoofdverdachten: hosting, plugins, thema, database
Als de metingen binnen zijn, gaat de zoektocht naar de oorzaak. In bijna alle gevallen is het één van vier:
Hosting. Een trage gedeelde hosting kun je niet wegoptimaliseren. Als TTFB consistent boven de 800 ms zit, en een statische test-HTML op dezelfde server óók traag is, dan ligt het aan hosting. Punt.
Plugins. Per geïnstalleerde plugin draait code op elke pageload. Sommige plugins zijn licht, andere voegen tien queries per pagina toe. Vooral oude SEO-, statistiek-, back-up- of “tien-in-één” plugins zijn vaak schuldig. Query Monitor wijst ze aan.
Thema. Page builders zoals Elementor en Divi zijn twee tot drie keer trager dan een blok-thema of GeneratePress. Daar is geen plugin tegen opgewassen. Een licht thema is geen optie maar uitgangspunt.
Database. Een wp_options-tabel met meer dan 1 MB aan autoload-records is een database-gif. Dat overkomt je niet uit het niets: het komt van plugins die jarenlang transients en cache-data hebben weggeschreven en nooit opgeruimd. Een database-cleanup met WP-CLI of een tool als WP-Optimize is dan een effectievere actie dan welke cache-plugin ook.
Wat een cache-plugin wél en níét doet
Cache-plugins zijn zinvol. Voor de juiste situatie. Een blogartikel of een marketingpagina die voor iedereen hetzelfde is: caching werkt daar prima. Eenmaal opgebouwd, in dezelfde HTML serveren aan duizend bezoekers.
Wat caching níét repareert: een trage admin, een trage checkout in WooCommerce, een ingelogde-gebruikers-omgeving. Daar wordt elke pagina dynamisch opgebouwd. Cache slaat hem dan over. Als je site daar traag is, lost een cache-plugin niets op en kan hij zelfs verwarrend zijn.
WooCommerce-checkouts zijn een speciaal geval. Cart en checkout zijn nooit te cachen, dus daar telt de snelheid van PHP, database en server extra. Object cache (Redis of Memcached) helpt wel voor logged-in gebruikers en admin, maar lost de homepage van een gemiddelde bezoeker niet op.
Wanneer afterburner-werk zin heeft
WebP, AVIF, CDN, lazy load, code-minificatie: allemaal nuttig. Maar pas waardevol als het fundament klopt. Anders optimaliseer je een traag huis door de gordijnen te wassen.
Beelden vormen gemiddeld 67 procent van het paginagewicht. WebP of AVIF kan dat met 60 tot 80 procent verkleinen zonder dat je het ziet. Dat is een eenmalige investering met een blijvend effect.
Een CDN is zinvol als je veel media hebt, internationale bezoekers, of een trage origin-server. Voor een Terneuzense ondernemer met een goede Nederlandse hoster vaak overbodig. Hetzelfde voor lazy loading: standaard ingebouwd in WordPress sinds versie 5.5, maar in extreme gevallen kun je hem fijner instellen.
PHP 8.3 is ongeveer 15 procent sneller dan PHP 7.4 op typische WordPress workloads. Een upgrade van PHP-versie is een gratis snelheidswinst die niemand benoemt omdat het geen plugin verkoopt. Wel checken of je thema en plugins met de nieuwere versie compatibel zijn.
Wanneer hosting verhuizen de enige echte oplossing is
Soms is het antwoord: deze hosting is het probleem. Dat is geen prettige boodschap, maar het is wel de eerlijke. Een paar signalen:
TTFB blijft boven de 800 ms, ook met alle caching en optimalisatie aan. Een test-pagina zonder WordPress is ook traag. De hoster geeft geen toegang tot logfiles, PHP-versie, of object cache. Je hebt al twee tickets gestuurd zonder onderbouwde uitleg.
Wat dan? De keuze tussen shared, VPS, en managed hosting. Voor een gemiddelde MKB-site is shared bij een goede Nederlandse provider (zoals Antagonist, TransIP of Hostnet, om enkele te noemen) prima. Voor WooCommerce met serieuze omzet, of voor sites met tienduizenden bezoekers per maand, wordt managed (Kinsta, Pressidium, Combell managed) snel zinvol. VPS is voor wie genoeg technische kennis heeft om zelf te configureren.
Een hosting-verhuis is geen klein klusje, maar ook geen drama. Voor migratie, serverwerk en database hanteer ik 95 euro per uur. Een gemiddelde WordPress-verhuis zit tussen twee en zes uur, afhankelijk van de complexiteit (DNS, mail, SSL, eventueel WooCommerce-orders die niet stuk mogen). Dat principe geldt overigens net zo voor Joomla en Drupal: zelfde meetwerk, andere tools. Joomla heeft het System Plugin, Drupal de Devel-module, maar de diagnostische volgorde is identiek.
Verbeteren boven herbouwen is ook hier het uitgangspunt. Een trage site weer rap krijgen lukt bijna altijd zonder dat je opnieuw begint. Als je doorlopend onderhoud overweegt en wilt voorkomen dat het ooit nog zo ver komt: ik bied WordPress onderhoud zonder bureau-tarieven waarin meet-en-fix gewoon standaardwerk is. Voor de Core Web Vitals zelf is de officiële LCP-uitleg van web.dev een goed startpunt als je dieper wilt graven.
