Een trage website kost bezoekers, omzet en posities in Google. De goede boodschap: de meeste snelheidsproblemen hebben maar een handvol oorzaken, en die zijn stuk voor stuk op te lossen zonder je site opnieuw te bouwen. In dit artikel lees je eerst hoe je de oorzaak vindt, daarna de twaalf stappen die het meeste opleveren, van hosting tot afbeeldingen en scripts. We gebruiken de Core Web Vitals van Google als meetlat, zodat je na elke stap kunt zien of het geholpen heeft.
Google beoordeelt snelheid met drie Core Web Vitals, gemeten bij echte bezoekers op mobiel:
| Meetwaarde | Wat het meet | Goed | Slecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Hoe snel het grootste element boven de vouw zichtbaar is | ≤ 2,5 s | > 4,0 s |
| INP (Interaction to Next Paint) | Hoe snel de pagina reageert op klikken en typen | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Hoeveel de lay-out verspringt tijdens het laden | ≤ 0,1 | > 0,25 |
Een vierde waarde is geen officiële Core Web Vital maar wel de belangrijkste indicator voor je hosting: de TTFB (Time to First Byte), de tijd tot de server het eerste stukje van de pagina terugstuurt. Google adviseert onder 0,8 seconde. Zit je daarboven, dan kun je optimaliseren wat je wilt, maar begint elke pagina al met achterstand.
Begin met één meting die je bewaart, zodat je het effect van elke stap kunt zien. Gebruik PageSpeed Insights voor de Core Web Vitals en een watervaldiagram (GTmetrix of WebPageTest) om te zien welke bestanden de tijd opslokken. Hoe je die tools leest en wat de scores betekenen, staat in website snelheid testen met 6 tools. Let bij het lezen op drie dingen:
De stappen staan in de volgorde waarin ze doorgaans het meeste opleveren voor de minste moeite. De tabel onderaan vat ze samen.
Meet de TTFB van een kale pagina, bijvoorbeeld een lege testpagina zonder plugins of zware blokken. Blijft die boven de 0,8 seconde, dan is de server te traag of te vol: goedkope shared hosting deelt één machine met honderden sites. Oplossingen oplopend in prijs: overstappen op een snellere shared hoster met LiteSpeed of NGINX en servercache, een managed WordPress-pakket, of een VPS. In onze vergelijking van snelle hosting staan de providers met gemeten laadtijden naast elkaar. Overstappen is minder werk dan het klinkt; veel providers verhuizen je site gratis.
Veel sites draaien nog op een oude PHP-versie omdat niemand er ooit naar kijkt. PHP 8 verwerkt WordPress-pagina’s aanzienlijk sneller dan PHP 7 en is bovendien de enige versie die nog beveiligingsupdates krijgt. Je stelt de versie in via het controlepaneel van je hosting (DirectAdmin, Plesk of cPanel), meestal onder “PHP-instellingen” of “PHP selector”. Maak eerst een back-up en test daarna of alle plugins nog werken. Meer uitleg in wat is PHP?
Zonder cache bouwt WordPress elke pagina bij elk bezoek opnieuw op uit de database. Met paginacache wordt een kant-en-klare HTML-versie bewaard en direct geserveerd. Dit is meestal de grootste winst van alle stappen. Draait je hosting op LiteSpeed, gebruik dan de gratis plugin LiteSpeed Cache; anders is WP Rocket (betaald) of W3 Total Cache / WP Super Cache (gratis) een goede keuze. Zet ook browsercaching aan, zodat terugkerende bezoekers afbeeldingen en stijlbestanden niet opnieuw downloaden. Veel managed WordPress-hosters hebben servercache standaard aanstaan; vraag het na voordat je een tweede cachelaag toevoegt, want dubbele caching geeft rare fouten.
Afbeeldingen zijn op de meeste sites meer dan de helft van alle gedownloade bytes. Drie regels: upload nooit groter dan de afmeting waarop de afbeelding getoond wordt (een foto van 4.000 pixels breed in een kolom van 800 pixels is pure verspilling), comprimeer elke afbeelding, en lever hem als WebP of AVIF in plaats van JPG of PNG. Plugins als ShortPixel, Imagify, Smush of de ingebouwde optimalisatie van LiteSpeed Cache doen dit automatisch, ook voor bestaande afbeeldingen. Het stappenplan staat in afbeeldingen optimaliseren in WordPress.
Met lazy loading worden afbeeldingen pas gedownload als de bezoeker ernaartoe scrolt. WordPress doet dit sinds versie 5.5 standaard, maar maak één uitzondering: de hero-afbeelding of het logo bovenaan mag niet lazy laden, anders verslechtert juist je LCP. Geef dat eerste beeld het attribuut fetchpriority="high" en laat de rest lazy. Caching- en optimalisatieplugins hebben hier een instelling voor (“eerste X afbeeldingen uitsluiten”).
Elk stijlbestand en script dat in de kop van de pagina staat, blokkeert het tekenen van de pagina tot het binnen is. Laat je cacheplugin CSS en JavaScript minimaliseren, JavaScript uitgesteld laden (defer) en ongebruikte CSS verwijderen. Doe dit stap voor stap en controleer na elke wijziging of sliders, formulieren en menu’s nog werken; dit is de stap waar het vaakst iets breekt. Werkt iets niet meer, sluit dan dat ene script uit in plaats van de hele optimalisatie uit te zetten.
Twee lettertypen in drie gewichten zijn zes bestanden die geladen moeten zijn voordat tekst goed zichtbaar is. Gebruik maximaal twee lettertypen, host ze op je eigen server in plaats van via Google Fonts (sneller én geen gegevensuitwisseling met Google, wat ook voor de AVG prettig is), zet font-display: swap aan zodat tekst meteen in een systeemlettertype verschijnt, en preload het belangrijkste fontbestand. Thema’s en cacheplugins hebben hier steeds vaker een schakelaar voor.
Niet het aantal plugins telt, maar wat ze op elke pagina laden. Een pagebuilder, een sliderplugin, een social-share-balk en een beveiligingsplugin met live scanner kosten samen al gauw een seconde. Open het watervaldiagram, kijk welke plugin-mappen (/wp-content/plugins/naam/) de meeste bestanden laden, en vraag je per plugin af of je hem nodig hebt. Deactiveer ongebruikte plugins volledig, in plaats van ze alleen uit te schakelen in de instellingen. De Query Monitor-plugin laat per pagina zien welke plugins de meeste databasetijd kosten.
Chatwidgets, Google Tag Manager, Facebook-pixel, YouTube-embeds en reviewwidgets halen tientallen bestanden van andere servers op, waar jij geen invloed op hebt. Laad ze pas na de eerste interactie of na een paar seconden (“delay JavaScript” in WP Rocket, LiteSpeed Cache of Flying Scripts), vervang YouTube-embeds door een klikbare afbeelding die de video pas laadt na een klik, en verwijder trackers die niemand meer uitleest. Dit is doorgaans de grootste winst voor de INP-score.
Een CDN (content delivery network) zet kopieën van je afbeeldingen, scripts en stijlbestanden op servers over de hele wereld, zodat een bezoeker uit Spanje of de VS ze van dichtbij krijgt. Voor een site met alleen Nederlandse bezoekers en een Nederlandse server is de winst klein; voor internationale bezoekers of sites met veel afbeeldingen is hij groot. Cloudflare heeft een gratis instapplan, en sommige hostingpakketten leveren een CDN mee. Wat een CDN precies doet en wanneer je er een nodig hebt, lees je in wat is een CDN?
Revisies van elke pagina, verlopen transients, spamreacties en tabellen van plugins die je al jaren geleden hebt verwijderd: samen maken ze elke databasequery een beetje trager. Beperk het aantal revisies (bijvoorbeeld tot vijf per bericht), laat WP-Optimize of de databasefunctie van LiteSpeed Cache maandelijks opruimen, en verwijder achtergebleven tabellen van oude plugins. Maak altijd eerst een back-up.
Als na stap 1 tot en met 11 de LCP nog boven de 2,5 seconde zit, is de bouw van de site zelf het probleem. Multipurpose-thema’s met honderden opties en pagebuilders die voor elk blok een laag extra HTML en scripts toevoegen, zijn structureel traag. Lichte thema’s zoals GeneratePress, Kadence, Astra of Blocksy in combinatie met de standaard blokeditor van WordPress laden een pagina met een fractie van de bestanden. Dat is een groter project, maar wel de enige stap die een structureel trage site echt snel maakt.
| Stap | Verbetert vooral | Effect | Moeite |
|---|---|---|---|
| 1. Hosting controleren of overstappen | TTFB, LCP | Groot | Gemiddeld |
| 2. PHP 8 | TTFB | Gemiddeld | Klein |
| 3. Caching | TTFB, LCP | Groot | Klein |
| 4. Afbeeldingen comprimeren en WebP | LCP | Groot | Klein |
| 5. Lazy loading goed instellen | LCP | Gemiddeld | Klein |
| 6. CSS/JS opruimen | LCP, INP | Gemiddeld | Gemiddeld |
| 7. Webfonts beperken | LCP, CLS | Klein tot gemiddeld | Klein |
| 8. Plugins opruimen | INP, TTFB | Gemiddeld | Klein |
| 9. Externe scripts uitstellen | INP | Groot | Klein |
| 10. CDN | LCP (buitenland) | Klein tot groot | Klein |
| 11. Database opschonen | TTFB | Klein | Klein |
| 12. Thema of pagebuilder vervangen | Alles | Groot | Groot |
Drie signalen wijzen naar de hosting en niet naar je site. De TTFB blijft boven de 0,8 seconde, ook op een lege pagina met caching aan. De laadtijd wisselt sterk per moment van de dag, wat wijst op een overvolle gedeelde server. En de beheeromgeving van WordPress zelf, die niet gecachet wordt, voelt traag aan. In die gevallen is een snellere hoster de enige stap die helpt; welke providers in onze metingen het snelst zijn, staat in de vergelijking van snelle hosting, en waar je verder op let bij een overstap in hosting kiezen: wat is belangrijk?
Google noemt een LCP tot 2,5 seconde goed; in de praktijk mikken snelle sites op 1 tot 1,5 seconde. Belangrijker dan de totale laadtijd is dat de bezoeker binnen een seconde iets ziet en de pagina direct reageert op klikken.
Nee. De score van 0 tot 100 is een labtest op een gesimuleerde trage telefoon. Google rangschikt op de Core Web Vitals van echte bezoekers (de veldgegevens bovenaan het rapport). Een site kan een score van 60 hebben en toch alle drie de vitals halen, en andersom.
Voor bezoekers die niet ingelogd zijn vrijwel altijd, en vaak fors. Voor ingelogde gebruikers, webshops met winkelwagens en pagina’s met persoonlijke inhoud werkt paginacache beperkt; daar helpen objectcache (Redis of Memcached) en snellere hosting meer.
Alleen als de hosting de bottleneck was. Een site met afbeeldingen van 3 MB en twintig externe scripts blijft traag op elke server. Doorloop daarom eerst stap 2 tot en met 9; kost dat niets, dan weet je zeker dat een overstap zinvol is.
