Contact
← Terug naar kennisbank PERFORMANCE

Trage WordPress site versnellen — 10 concrete stappen

"Mijn site is traag" is een symptoom, geen diagnose. Vóór je 4 cache-plugins door elkaar gooit, is het de vraag: waar zit de bottleneck? Dit stappenplan loopt door tien specifieke gebieden die samen 95% van trage WordPress-sites verklaren — met benchmarks, tools en concrete acties die echt verschil maken.

17 min lezen · Laatst gecheckt:

WordPress is gebouwd voor flexibiliteit, niet voor snelheid. Een verse installatie laadt in onder een seconde — voeg twintig plugins toe, een zwaar Elementor-thema en een gedeelde hosting-omgeving, en je zit zomaar op 6+ seconden. Het probleem: bezoekers wachten geen 6 seconden. Google ook niet. Sinds 2021 wegen Core Web Vitals mee in ranking; sinds maart 2024 is INP (Interaction to Next Paint) toegevoegd als officiële metric.

Dit artikel bespreekt de tien meest voorkomende oorzaken van trage WordPress-sites, in volgorde van impact. Geen generieke "verwijder ongebruikte plugins" lijst — wel concrete benchmarks, specifieke plugin-aanbevelingen en wat je echt moet meten.

Stap 0: Eerst meten, dan optimaliseren

Optimaliseren zonder eerst meten is gokken. Voor je iets verandert, run je deze tests:

  • PageSpeed Insights: Google's eigen tool, toont Core Web Vitals + Lighthouse score. Test zowel mobiel als desktop. Gebruik dit als primaire benchmark omdat het is wat Google gebruikt voor ranking
  • GTmetrix: gedetailleerd waterval-rapport met loading-volgorde, request-by-request analyse
  • WebPageTest: meest geavanceerd, kan testen vanaf specifieke locaties met specifieke devices/connecties

Wat je zoekt:

  • LCP (Largest Contentful Paint): hoe snel het grootste element zichtbaar is. Doel: onder 2.5s
  • INP (Interaction to Next Paint): responsiviteit op kliks/typen. Doel: onder 200ms
  • CLS (Cumulative Layout Shift): visuele stabiliteit. Doel: onder 0.1
  • TTFB (Time to First Byte): hoe snel de server begint te antwoorden. Doel: onder 600ms
  • Total Blocking Time: hoeveel het JavaScript de hoofdthread blokkeert. Doel: onder 200ms
Lighthouse score versus echte gebruikerservaring: de Lighthouse score (0-100) in PageSpeed Insights is een synthetische test. De Core Web Vitals onderaan het rapport komen uit echte bezoekersdata van Chrome (CrUX). Focus op die laatste — score 95 met slechte CrUX-data is niets waard.

Stap 1: Hosting — de fundering

Geen enkele plugin compenseert slechte hosting. Als je TTFB consistent boven 1 seconde zit op shared hosting met 50 andere sites, is upgraden de eerste stap.

Indicatieve TTFB-benchmarks per type hosting:

  • Goedkope shared hosting (€3-5/mnd): TTFB 800-2000ms — onacceptabel voor commerciële sites
  • Premium shared hosting (€10-20/mnd, NL hosters met SSD/LiteSpeed): TTFB 200-500ms
  • Managed WordPress hosting (Kinsta, WP Engine, Cloudways): TTFB 100-300ms
  • VPS met goede config: TTFB 50-200ms — voor wie controle wil en weet wat 'ie doet

Wat je zoekt in een hoster voor WordPress:

  • SSD/NVMe storage (geen HDD)
  • LiteSpeed of Nginx in plaats van plain Apache
  • HTTP/2 of HTTP/3 ondersteuning
  • OPcache aan
  • Redis of Memcached beschikbaar (voor object cache)
  • Recente PHP-versies (PHP 8.2+)

Stap 2: PHP-versie

PHP 8.2 is meetbaar 25-30% sneller dan PHP 7.4 op WordPress-workloads. PHP 8.3 zelfs nog iets sneller. Draai je nog op PHP 7.x, dan is dit één van de grootste single-action wins die je kunt doen.

Volledige instructies voor het upgrade-proces, compatibility-checks en rollback: PHP-versie veilig upgraden zonder je site te breken.

Stap 3: Caching strategie — page, object en browser

Caching is de grootste hefboom in performance. Drie lagen:

3.1 — Page cache (statische HTML genereren)

Standaard genereert WordPress elke pagina dynamisch — PHP draait, database wordt aangeroepen, alles wordt opgebouwd. Met page cache wordt het resultaat 1× gegenereerd en daarna als statische HTML geserveerd. Verschil: 800ms vs 50ms.

Drie aanbevolen plugins, in volgorde:

  • LiteSpeed Cache: gratis, beste optie als je hosting LiteSpeed draait. Nederlandse hosters die het ondersteunen: Hostnet, Versio, Antagonist en anderen. Combineert page cache, object cache, image optimization in één
  • WP Rocket: betaald (~€59/jaar), werkt op elke hosting, makkelijkste setup. Beste keuze voor non-LiteSpeed hosting. Combineert ook lazy loading, critical CSS en database cleanup
  • W3 Total Cache: gratis maar complex. Veel knoppen, makkelijk verkeerd te configureren. Alleen voor wie weet wat 'ie doet

Vermijd: WP Super Cache (verouderd), WP Fastest Cache (basaal), Hummingbird (te veel features die conflicteren).

3.2 — Object cache (database queries cachen)

Object cache slaat MySQL-query resultaten op in een snelle in-memory store (Redis of Memcached). Vooral voor logged-in users en WooCommerce-shops een grote win — daar werkt page cache niet (elke gebruiker heeft eigen content), maar object cache wel.

Vereist:

  • Redis of Memcached beschikbaar op je server
  • Plugin: "Redis Object Cache" (gratis) of "Object Cache Pro" (betaald, geavanceerder)

Niet alle shared hostings ondersteunen Redis — vraag je hoster. Op managed WordPress hosting is het meestal standaard beschikbaar.

3.3 — Browser cache (visitors hergebruiken)

Browsers cachen statische assets (CSS, JS, afbeeldingen) lokaal. Vertel ze hoe lang. Via .htaccess in webroot:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Cache plugins zoals LiteSpeed en WP Rocket configureren dit automatisch. Zie ook het .htaccess artikel voor algemene context.

Stap 4: Beeldoptimalisatie — vaak 60% van pagina-gewicht

Beelden zijn de grootste loading-bottleneck op de meeste WordPress-sites. Vier acties:

4.1 — Comprimeer en converteer naar WebP

WebP is ~30% kleiner dan JPEG bij dezelfde kwaliteit, en wordt door 95%+ van browsers ondersteund. Plugins:

  • ShortPixel: betaald (~$5-10/mnd voor de meeste sites), beste compressie
  • Smush: gratis basisversie, betaald voor WebP
  • Imagify: WP Rocket-compatibel, vergelijkbaar met ShortPixel
  • Litespeed Image Optimization: gratis als je LiteSpeed draait

Test verschillende compressie-niveaus. Visueel verschil tussen "lossy 80" en "lossy 90" is meestal nul, kleinerer wel met ~30%.

4.2 — Specificeer dimensies om CLS te voorkomen

Ontbrekende width/height attributen op <img> tags veroorzaken layout shifts wanneer afbeeldingen laden. Sinds WordPress 5.5 worden deze automatisch toegevoegd voor afbeeldingen via de Media Library — maar custom themes en oude content missen ze vaak.

Check je HTML output. Elke <img> moet hebben:

<img src="..." width="800" height="600" alt="...">

4.3 — Native lazy loading

Sinds WordPress 5.5 wordt loading="lazy" standaard toegevoegd aan afbeeldingen die onder de fold staan. Dit zorgt ervoor dat ze pas laden wanneer de bezoeker er bijna is. Geen plugin nodig.

Belangrijke uitzondering: voeg expliciet loading="eager" en fetchpriority="high" toe aan je hero-afbeelding (de eerste, grote afbeelding). Anders wordt zelfs die lazy-loaded en stort je LCP in.

4.4 — srcset voor responsive images

WordPress genereert standaard meerdere groottes (thumbnail, medium, large, full). Met srcset serveert het de juiste grootte per device. Mobile gebruikers laden niet de 2400px versie als hun scherm 800px is.

Native ondersteund door WordPress; check dat je theme de afbeeldingen niet hardcoded vast op één grootte zet.

Stap 5: Database optimalisatie

Een verwaarloosde WordPress-database wordt traag — vooral de wp_options en wp_postmeta tabellen. Drie acties:

5.1 — Verwijder transients

Transients zijn tijdelijke cache-entries in de database. Als de cleanup niet werkt (bv. omdat WP-Cron stuck is), stapelen ze op tot duizenden rijen. Dat vertraagt élke pagina-laad.

Via WP-CLI:

wp transient delete --all
wp transient delete-expired

Of via plugin: "Transients Manager" voor handmatige inspectie.

5.2 — Audit autoload

Sommige wp_options-rijen worden bij élke pagina-laad geladen (autoload=yes). Mooi als het kleine instellingen zijn — ramp als plugins er per ongeluk megabytes aan data in stoppen.

Check de top 20 grootste autoloaded rijen:

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;

Vind je option_value groter dan ~100KB? Dat is verdacht. Vaak gaat het om plugin-data die geen autoload zou moeten zijn. Verwijder of verander handmatig naar autoload='no'.

5.3 — Cleanup oude revisies, drafts, spam

Posts, pages, products bouwen een geschiedenis op aan revisies. Dat heeft soms 10× zoveel rijen in wp_posts als nodig. Limit revisies via wp-config.php:

define('WP_POST_REVISIONS', 5);

En cleanup historisch via:

# WP-CLI
wp post delete $(wp post list --post_type='revision' --format=ids) --force

# Of via plugin: "WP-Optimize" of "Advanced Database Cleaner"

Stap 6: Plugin audit — minder is meer

Niet het aantal plugins is het probleem, maar de kwaliteit. Eén slecht geschreven plugin kan meer kwaad doen dan twintig goeie. Zoek de boosdoeners:

Plugin: "Query Monitor". Toont per pagina-laad welke plugins de meeste queries en tijd verbruiken. Activeer tijdelijk op staging, klik door je site, kijk welke plugins het zwaarst zijn.

Veelvoorkomende slow performers:

  • WPBakery / Visual Composer: voegt veel render-overhead toe
  • Elementor: niet snel maar wel optimaliseerbaar; vermijd Pro Forms en gebruik Fluent Forms in plaats
  • WooCommerce + zware plugins: cart fragments via AJAX kunnen drastisch vertragen
  • Slider Revolution: zwaar tenzij specifiek geoptimaliseerd
  • Jetpack: gigantisch — gebruik alleen als je 80%+ van features gebruikt
  • Backup-plugins die in werkurenuren backuppen: schedule voor 2:00 AM, niet tijdens piek-verkeer
  • Twee SEO-plugins tegelijk: Yoast + Rank Math + AIOSEO is een ramp; kies er één

Voor elk gevonden zware plugin: kun je het zonder? Een lichter alternatief? Native WordPress-functionaliteit?

Stap 7: Theme optimalisatie

Het theme bepaalt veel performance. "Premium themes" met 100+ features (ThemeForest bestsellers) zijn vaak grote bottle-necks. Twee aanpakken:

7.1 — Render-blocking JavaScript en CSS

Browsers wachten met renderen tot CSS en JS in de <head> geladen zijn. Hoe meer dat is, hoe later je site verschijnt.

Acties via cache plugin:

  • Defer non-critical JS: voegt defer toe aan scripts
  • Inline critical CSS: extract de CSS voor above-the-fold content, inline in HTML, defer de rest
  • Combine CSS/JS: minder requests (alleen relevant voor HTTP/1.1; HTTP/2 minder belangrijk)

WP Rocket en LiteSpeed Cache hebben beide critical CSS-generatie ingebouwd. Test grondig — verkeerde combinatie breekt sliders en formulieren.

7.2 — Page builder bloat

Elementor en Bricks Builder voegen vaak 50-100KB extra CSS/JS toe per pagina, zelfs als de pagina niets bijzonders heeft. Acties:

  • Elementor: in Settings → Performance → schakel uit wat je niet gebruikt (Lightbox, Eicons, etc.)
  • Bricks Builder: lichter, maar zorg dat je z'n CSS-cache aan hebt
  • Overweeg Gutenberg: native, lichtgewicht. Als je site eenvoudige content heeft is dit de snelste optie

Stap 8: CDN — global content delivery

CDN (Content Delivery Network) serveert je statische bestanden vanaf een server dichterbij de bezoeker. Resultaat: snellere LCP, vooral voor internationale bezoekers.

Drie aanbevelingen:

  • Cloudflare: gratis tier is voor de meeste sites genoeg. Plus security-laag (WAF). Setup: domein NS-records naar Cloudflare verwijzen, daarna alle assets automatisch via CDN
  • BunnyCDN: betaald (~$1/mnd basic), zeer betaalbaar, snellere edge-servers dan free-tier Cloudflare
  • KeyCDN: alternatief voor BunnyCDN, vergelijkbare prijsstelling

Voor lokale Nederlandse sites met alleen NL bezoekers: een CDN is mooi maar geen game-changer. Voor sites met internationale bezoekers, of die alleen al voor Cloudflare's WAF willen — direct doen.

Stap 9: Resource hints (preload, preconnect)

Vertel de browser welke resources je sowieso gaat nodig hebben. Vier hints:

  • <link rel="preload">: laad deze nu, ik heb 'm dadelijk nodig (voor critical fonts, hero images)
  • <link rel="preconnect">: zet vast een verbinding op naar deze server (voor third-party CDN's)
  • <link rel="dns-prefetch">: lichtgewicht versie van preconnect
  • <link rel="prefetch">: laad deze in de achtergrond, gebruiker gaat 'm waarschijnlijk gebruiken

Voorbeeld: jouw font hosting zelf, en je hebt een hero-afbeelding:

<link rel="preload" href="fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="hero.webp" as="image" fetchpriority="high">

WP Rocket en LiteSpeed Cache hebben deze hints ingebouwd; check dat ze correct staan voor je actieve theme.

Stap 10: Server-niveau optimalisaties

Voor wie SSH-toegang heeft, of een hoster met goede defaults:

10.1 — Gzip/Brotli compressie

Compressie van HTML/CSS/JS verkleint over-the-wire payloads met 60-80%. Gzip is universeel, Brotli is nieuwer en ~15% beter.

# In .htaccess voor Gzip
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript
    AddOutputFilterByType DEFLATE application/json image/svg+xml
</IfModule>

Brotli vereist mod_brotli op de server. Check met je hoster.

10.2 — HTTP/2 of HTTP/3

HTTP/2 multiplexed meerdere requests over één connectie — drastische verbetering voor sites met veel resources. HTTP/3 nog beter (gebruikt UDP/QUIC). Beide vereist HTTPS.

Test welke versie je site gebruikt:

curl -I --http2 https://jouwsite.nl

10.3 — OPcache

OPcache cachet gecompileerde PHP-bytecode in geheugen. Verschil: 50ms vs 5ms per PHP-request. Standaard aan op moderne PHP, maar check via phpinfo() dat 'ie geactiveerd is met genoeg memory (minimaal 128MB).

Wat realistisch te verwachten

Indicatieve resultaten na deze stappen, voor een gemiddelde WordPress-site:

  • Voor optimalisatie: TTFB 1500ms, LCP 4.5s, Lighthouse 35
  • Na hosting + PHP + caching: TTFB 400ms, LCP 2.2s, Lighthouse 75
  • Na image optimization + database cleanup: TTFB 350ms, LCP 1.8s, Lighthouse 88
  • Na alles inclusief CDN + critical CSS: TTFB 200ms, LCP 1.4s, Lighthouse 95+

Een eindscore van 95+ is haalbaar voor de meeste sites zonder grote architectonische wijzigingen.

Veelvoorkomende valkuilen

Twee cache-plugins tegelijk

Zelden werkt dit. Cache lagen kunnen elkaar tegenwerken. Kies één: LiteSpeed (als je hosting het ondersteunt) of WP Rocket (als niet).

Te aggressief minify

Minify combineert CSS en JS. Ziet er mooi uit in benchmarks, breekt soms forms, sliders, en JavaScript-componenten. Test grondig na elke change. Begin met conservatieve instellingen, verstrak geleidelijk.

Lighthouse score najagen ten koste van echt verkeer

Lighthouse meet één pagelaad in een ideale omgeving. Echte gebruikers hebben slechtere mobile connecties, oudere devices, real-world condities. Focus op CrUX-data (echte gebruikers) in PageSpeed Insights, niet op Lighthouse-cijfers.

WooCommerce cart fragments

WooCommerce maakt elke X seconden een AJAX-call om de winkelwagen-icoon te updaten. Op trafic-zware sites is dit een rampscenario. Disable via:

add_action('wp_enqueue_scripts', function() {
    wp_dequeue_script('wc-cart-fragments');
}, 11);

Hoster die "WordPress hosting" zegt zonder caching

"WordPress hosting" is marketing-term. Vraag specifiek: server-niveau cache (LiteSpeed/Nginx fastcgi), Object cache (Redis), HTTP/2, recente PHP. Heeft de hoster dat niet, dan is het gewoon shared hosting met een WP-installer.

Wanneer schakel je hulp in?

  • Site is nog steeds traag na alle 10 stappen — er zit ergens een dieperliggend issue
  • Lighthouse 90+ haal je niet boven 50 op een specifieke pagina
  • WooCommerce performance onder 100 producten / dagelijkse verkeer is acceptabel, maar bij grote catalogi heb je gespecialiseerde optimalisatie nodig
  • Je site is op managed hosting (Kinsta etc.) maar nog steeds traag — dan is het waarschijnlijk theme of plugins
  • Critical CSS extractie levert kapotte renders op
  • Database is groter dan 1GB — dan is professionele optimalisatie de moeite waard
  • Je hebt geen SSH-toegang en sommige stappen vereisen het

Performance-optimalisatie is een vakgebied met diepte. De stappen hier brengen je van "rood" naar "groen" in 95% van de gevallen. Voor de laatste 5% — high-traffic e-commerce, complex caching, server-niveau tuning — zoek iemand die het dagelijks doet.