WordPress website traag? Zo spoor je de oorzaak op Slow WordPress website? How to find the cause
Het onderwerp wordpress website traag oorzaken is belangrijk. In dit artikel
Een trage website kost je bezoekers. Google’s eigen onderzoek toont dat 53% van mobiele bezoekers afhaakt als een pagina langer dan 3 seconden laadt. Bovendien is laadsnelheid een directe ranking-factor: een trage site is dubbel nadelig.
Maar “mijn website is traag” is een symptoom, geen diagnose. De oorzaak kan liggen bij je hosting, afbeeldingen, plugins, thema, of een combinatie. In dit artikel lopen we systematisch door alle mogelijke boosdoeners.
Lees ook: De 12 meest voorkomende WordPress foutmeldingen (en hoe je ze oplost)
1. Eerst meten, dan verbeteren
Voordat je iets optimaliseert, moet je weten wat precies traag is. Gebruik deze tools voor concrete meetwaarden:
| Tool | Wat het meet | Gratis? |
|---|---|---|
| Google PageSpeed Insights | Core Web Vitals (LCP, FID, CLS) | Ja |
| GTmetrix | Laadtijd, paginagrootte, verzoeken | Ja (beperkt) |
| WebPageTest | Waterfall analyse, TTFB per regio | Ja |
| Chrome DevTools > Network | Individuele bestandstijden | Ja |
Tip
Hulp nodig? Bekijk onze website hulp den haag pagina.
Test altijd in een incognito venster. Browser-extensies en cache vertekenen je resultaten. Test ook op een mobiel profiel. Google rankt op basis van mobiele prestaties.
De belangrijkste meetwaarde is je Time to First Byte (TTFB): de tijd tussen het verzoek en het eerste byte dat terugkomt. Is je TTFB hoger dan 600ms? Dan ligt het probleem bij je hosting of PHP, niet bij je frontend.
2. Hosting: de fundering
De snelste website op een trage server blijft traag. Veel goedkope shared hosting pakt honderden sites op één server. Je deelt CPU, geheugen en schijf-I/O met iedereen.
| Shared hosting | Managed WordPress | VPS | |
|---|---|---|---|
| TTFB | 400-1200ms | 100-300ms | 150-400ms |
| PHP workers | 2-4 | 4-16 | Configureerbaar |
| Server caching | Nee | Ja (Varnish/Nginx) | Zelf instellen |
| PHP versie | Soms verouderd | Altijd actueel | Zelf beheren |
Wist je dat?
De sprong van PHP 7.4 naar PHP 8.2 levert gemiddeld 15-25% snelheidswinst op voor WordPress. Controleer je PHP-versie via je hostingpanel.
3. Afbeeldingen optimaliseren
Afbeeldingen zijn bijna altijd de grootste bottleneck. Een ongeoptimaliseerde foto van 4MB als header-afbeelding is geen uitzondering. we zien het wekelijks.
Schaal af naar de juiste afmetingen
Een afbeelding van 4000×3000 pixels die op 800px breed wordt getoond? Dan stuur je 80% onnodige data. Schaal af voordat je uploadt.
Converteer naar WebP
WebP is 25-35% kleiner dan JPEG bij dezelfde kwaliteit. WordPress 5.8+ ondersteunt WebP native. Gebruik een plugin als ShortPixel of Imagify voor automatische conversie.
Lazy loading activeren
WordPress voegt automatisch loading="lazy" toe aan afbeeldingen. Controleer of je thema dit niet overschrijft. De eerste afbeelding (above the fold) moet juist eager laden.
4. Plugin-bloat opruimen
Elke plugin voegt PHP-uitvoertijd, CSS-bestanden en JavaScript toe. We zien regelmatig sites met 30+ plugins waarvan er 10 hetzelfde doen.
Let op
Deactiveer plugins niet zomaar op een live site. Test altijd eerst op een staging-omgeving. Sommige plugins schrijven data weg die je verliest bij deactivatie.
Installeer de Query Monitor plugin om te zien welke plugins de meeste queries en laadtijd veroorzaken. Sorteer op “time” en je ziet direct de boosdoeners.
5. Caching instellen
WordPress genereert elke pagina opnieuw via PHP en MySQL. tenzij je caching gebruikt. Er zijn drie niveaus:
| Type | Wat het doet | Voorbeeld |
|---|---|---|
| Page cache | Slaat hele HTML-pagina op | WP Super Cache, W3 Total Cache |
| Object cache | Cachet database-queries in RAM | Redis, Memcached |
| Browser cache | Browser hergebruikt bestanden | Expires headers in .htaccess |
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>6. Database opschonen
Na maanden of jaren gebruik slibt je database dicht met post-revisies, transients, spam-comments en verweesde metadata. Dit vertraagt elke query.
// Maximaal 5 revisies per post bewaren
define('WP_POST_REVISIONS', 5);
// Prullenbak na 7 dagen legen (standaard 30)
define('EMPTY_TRASH_DAYS', 7);Voor een eenmalige opschoonactie kun je WP-Optimize gebruiken, of handmatig via phpMyAdmin oude revisies verwijderen:
DELETE FROM wp_posts WHERE post_type = 'revision'
AND post_date < DATE_SUB(NOW(), INTERVAL 30 DAY);Snelheids-checklist
- TTFB onder 600ms (liefst onder 200ms)
- Afbeeldingen in WebP formaat, geschaald naar weergavegrootte
- Lazy loading actief op alle afbeeldingen behalve de eerste
- Page caching actief (WP Super Cache, LiteSpeed Cache, of via hosting)
- Browser caching headers ingesteld (minimaal 1 maand voor statische bestanden)
- Ongebruikte plugins gedeactiveerd en verwijderd
- PHP 8.0 of hoger
- Database geoptimaliseerd (revisies beperkt, transients opgeschoond)
- Geen render-blocking CSS/JS in de <head>
- GZIP of Brotli compressie actief op de server
Belangrijkste takeaway
Begin altijd bij TTFB en hosting. Als je server traag reageert, heeft frontend-optimalisatie weinig zin. Werk van buiten naar binnen: hosting → caching → afbeeldingen → code.
Gerelateerde artikelen
In this article
A slow website costs you visitors. Google's own research shows that 53% of mobile visitors leave if a page takes more than 3 seconds to load. On top of that, page speed is a direct ranking factor: a slow site hurts you twice.
But "my website is slow" is a symptom, not a diagnosis. The cause could be your hosting, images, plugins, theme, or a combination. In this article we systematically walk through all the usual suspects.
1. Measure first, optimize later
Before you optimize anything, you need to know what exactly is slow. Use these tools for concrete metrics:
| Tool | What it measures | Free? |
|---|---|---|
| Google PageSpeed Insights | Core Web Vitals (LCP, FID, CLS) | Yes |
| GTmetrix | Load time, page size, requests | Yes (limited) |
| WebPageTest | Waterfall analysis, TTFB per region | Yes |
| Chrome DevTools > Network | Individual file load times | Yes |
Tip
Always test in an incognito window. Browser extensions and cache distort your results. Also test on a mobile profile, as Google ranks based on mobile performance.
The most important metric is your Time to First Byte (TTFB): the time between the request and the first byte coming back. Is your TTFB higher than 600ms? Then the problem is your hosting or PHP, not your frontend.
2. Hosting: the foundation
The fastest website on a slow server stays slow. Many cheap shared hosts pack hundreds of sites on one server. You share CPU, memory and disk I/O with everyone.
| Shared hosting | Managed WordPress | VPS | |
|---|---|---|---|
| TTFB | 400-1200ms | 100-300ms | 150-400ms |
| PHP workers | 2-4 | 4-16 | Configurable |
| Server caching | No | Yes (Varnish/Nginx) | Set up yourself |
| PHP version | Sometimes outdated | Always current | Self-managed |
Did you know?
The jump from PHP 7.4 to PHP 8.2 delivers on average 15-25% speed improvement for WordPress. Check your PHP version via your hosting panel.
3. Optimizing images
Images are almost always the biggest bottleneck. An unoptimized 4MB photo as a header image is no exception: we see it weekly.
Scale down to the right dimensions
A 4000x3000 pixel image displayed at 800px wide? You're sending 80% unnecessary data. Scale down before uploading.
Convert to WebP
WebP is 25-35% smaller than JPEG at the same quality. WordPress 5.8+ supports WebP natively. Use a plugin like ShortPixel or Imagify for automatic conversion.
Enable lazy loading
WordPress automatically adds loading="lazy" to images. Check that your theme doesn't override this. The first image (above the fold) should load eagerly instead.
4. Cleaning up plugin bloat
Every plugin adds PHP execution time, CSS files and JavaScript. We regularly see sites with 30+ plugins where 10 do the same thing.
Warning
Don't just deactivate plugins on a live site. Always test on a staging environment first. Some plugins write data that you'll lose on deactivation.
Install the Query Monitor plugin to see which plugins cause the most queries and load time. Sort by "time" and you'll immediately see the culprits.
5. Setting up caching
WordPress regenerates every page via PHP and MySQL, unless you use caching. There are three levels:
| Type | What it does | Example |
|---|---|---|
| Page cache | Stores entire HTML pages | WP Super Cache, W3 Total Cache |
| Object cache | Caches database queries in RAM | Redis, Memcached |
| Browser cache | Browser reuses files | Expires headers in .htaccess |
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>6. Cleaning the database
After months or years of use, your database clogs up with post revisions, transients, spam comments and orphaned metadata. This slows down every query.
// Keep a maximum of 5 revisions per post
define('WP_POST_REVISIONS', 5);
// Empty trash after 7 days (default is 30)
define('EMPTY_TRASH_DAYS', 7);For a one-time cleanup you can use WP-Optimize, or manually delete old revisions via phpMyAdmin:
DELETE FROM wp_posts WHERE post_type = 'revision'
AND post_date < DATE_SUB(NOW(), INTERVAL 30 DAY);Speed checklist
- TTFB under 600ms (preferably under 200ms)
- Images in WebP format, scaled to display size
- Lazy loading active on all images except the first
- Page caching active (WP Super Cache, LiteSpeed Cache, or via hosting)
- Browser caching headers set (minimum 1 month for static files)
- Unused plugins deactivated and removed
- PHP 8.0 or higher
- Database optimized (revisions limited, transients cleaned)
- No render-blocking CSS/JS in the <head>
- GZIP or Brotli compression active on the server
Key takeaway
Always start with TTFB and hosting. If your server responds slowly, frontend optimization won't help much. Work from the outside in: hosting, caching, images, code.