De belangrijkste conclusie: een lage PageSpeed Insights-score op WordPress komt bijna altijd door dezelfde paar oorzaken — niet-geoptimaliseerde afbeeldingen, render-blokkerende scripts en geen cache. Los ze in die volgorde op, test na elke wijziging opnieuw, en de meeste sites gaan zo van rood naar groen zonder hosting-upgrade of thema-herbouw.
Waarom WordPress-sites slecht scoren op PageSpeed Insights
WordPress maakt het makkelijk om plugins, pagebuilders en scripts van derden toe te voegen — elk brengt eigen CSS, JavaScript en soms externe requests mee. Een standaardinstallatie met een pagebuilder, een paar marketingplugins en niet-geoptimaliseerde media kan gemakkelijk 3-4MB aan bestanden versturen voor één pagina.
PageSpeed Insights voert twee aparte analyses uit op elke URL die je test:
- Labdata: een gesimuleerde Lighthouse-audit, direct uitgevoerd op Google's servers onder vaste netwerk- en apparaatcondities. Nuttig om specifieke problemen op te sporen, maar het is een momentopname, geen echt gebruikersgedrag.
- Velddata: echte metingen van daadwerkelijke Chrome-gebruikers die je site in de afgelopen 28 dagen bezochten, afkomstig uit het Chrome User Experience Report (CrUX). Deze verschijnen alleen als je site genoeg Chrome-verkeer heeft.
Een site kan 95 scoren in het lab en toch "poor" (slecht) scoren in de velddata — meestal omdat echte gebruikers langzamere verbindingen of oudere apparaten hebben dan de labsimulatie aanneemt. Beide cijfers zijn belangrijk, maar het Core Web Vitals-rapport in Search Console gebruikt velddata — dat is dus het cijfer dat gekoppeld is aan zoekrangschikkingssignalen.
De volgorde die de score echt verandert
Werk deze punten in volgorde af — elk heeft doorgaans een groter effect dan het volgende, dus door de volgorde om te draaien verspil je tijd aan kleinere winsten eerst.
1. Fix eerst je afbeeldingen
Op een gemiddelde WordPress-pagina maken afbeeldingen 50-80% van het totale paginagewicht uit. Dit is vrijwel altijd de meest impactvolle fix, en meestal wat een rode Largest Contentful Paint (LCP)-score veroorzaakt, omdat het LCP-element op de meeste pagina's een hero-afbeelding, uitgelichte afbeelding of productfoto boven de vouw is.
Drie dingen om te controleren bij elke afbeelding boven de vouw:
- Formaat — is het nog steeds ruwe JPEG of PNG? WebP is bij gelijke kwaliteit ongeveer 25-35% kleiner, en AVIF verkleint het bestand ten opzichte van JPEG vaak met de helft.
- Afmetingen — wordt een 4000px brede foto in een container van 800px geperst? De browser downloadt alsnog het volledige bestand voordat het wordt verkleind.
- Laadprioriteit — staat de LCP-afbeelding per ongeluk gemarkeerd als
loading="lazy"? Dit is een van de meest voorkomende fouten die we zien: een "snelheid"-plugin past lazy loading toe op alle afbeeldingen op de pagina, inclusief de afbeelding die de browser als eerste nodig heeft.
We behandelen dit uitgebreider in onze Core Web Vitals-afbeeldingschecklist en WebP-conversiegids. Erdo Image Optimizer regelt de formaatconversie en lazy-loading-correctie automatisch, via de eigen GD- of Imagick-bibliotheek van je server — zonder externe API of maandelijkse quota.
2. Elimineer render-blokkerende CSS en JavaScript
Elke <script> en <link rel="stylesheet"> in je <head> zonder async, defer of een media query blokkeert het renderen van de pagina totdat het is gedownload en (bij scripts) uitgevoerd. Pagebuilders en multifunctionele thema's zijn hier vaak de boosdoener en laden vaak een complete icoonbibliotheek of animatie-framework, zelfs op pagina's die deze niet gebruiken.
De oplossing is niet altijd "plugin verwijderen" — vaak volstaat het om niet-kritieke scripts uit te stellen en de kleine hoeveelheid CSS die nodig is voor het eerste scherm inline te plaatsen. De meeste cache- en performance-plugins hebben hier een instelling voor; test zorgvuldig na het inschakelen, want agressief uitstellen kan soms een script breken dat afhankelijk is van de laadvolgorde.
3. Zet server- en browsercache aan
Een pagina die bij elk verzoek opnieuw moet worden opgebouwd door PHP en MySQL voegt honderden milliseconden toe aan de Time to First Byte (TTFB), wat alles daarna vertraagt, inclusief LCP. Paginacache (een vooraf gebouwd statisch HTML-bestand serveren aan terugkerende bezoekers) en objectcache (herhaalde databasequery's vermijden) zijn beide de moeite waard, en de meeste cache-plugins configureren beide met redelijke standaardinstellingen.
Deze stap telt mee, maar is zelden de grootste factor voor de score — een goed gecachte pagina met een niet-gecomprimeerde hero-afbeelding van 2MB faalt nog steeds op LCP.
4. Controleer het aantal en de kwaliteit van plugins
Het aantal plugins zelf is niet inherent een performanceprobleem — een goed geprogrammeerde plugin die zijn bestanden alleen laadt waar nodig kost heel weinig. Het echte probleem zijn plugins die site-breed CSS/JS laden, ongeacht of de huidige pagina ze gebruikt. Tien lichte, goed afgebakende plugins zijn minder problematisch dan twee slecht geprogrammeerde.
Een praktische audit: open Chrome DevTools → tabblad Network, herlaad een trage pagina en sorteer op grootte. Alles wat onverwacht groot is, is het onderzoeken waard — herleid het tot de plugin of het themaonderdeel dat het laadt.
Snelle referentie: Core Web Vitals-drempels
| Metriek | Goed | Verbetering nodig | Slecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Onder 2,5s | 2,5s – 4s | Boven 4s |
| INP (Interaction to Next Paint) | Onder 200ms | 200ms – 500ms | Boven 500ms |
| CLS (Cumulative Layout Shift) | Onder 0,1 | 0,1 – 0,25 | Boven 0,25 |
Dit zijn de door Google gepubliceerde drempelwaarden, gemeten op het 75e percentiel van echte bezoeken — wat betekent dat drie op de vier bezoekers in het bereik "Goed" moeten vallen wil de metriek slagen.
Een uitgewerkt voorbeeld
Bij een recente audit van een WooCommerce-winkel met een vrij typische opzet (pagebuilder, 3 marketingplugins, niet-geoptimaliseerde productfotografie) zag de vergelijking voor en na het aanpakken van afbeeldingen en render-blokkerende scripts er zo uit:
| Wijziging | LCP ervoor | LCP erna |
|---|---|---|
| Hero- en productafbeeldingen naar WebP converteren | 4,8s | 3,6s |
| Te grote afbeeldingsafmetingen corrigeren | 3,6s | 2,9s |
loading="lazy" van de hero-afbeelding verwijderen |
2,9s | 2,1s |
Geen van deze drie wijzigingen raakte hosting, cache-configuratie of themacode — ze brachten LCP van "slecht" naar "goed" puur door de afbeeldingen aan te pakken. Dat komt overeen met wat we bij de meeste WordPress-audits zien: afbeeldingen zijn de eerste plek om te controleren, niet de laatste.
De fout die je beter kunt vermijden
Een veelvoorkomende reflex wanneer PageSpeed Insights rood aangeeft, is om plugins één voor één uit te schakelen, in de hoop "de" boosdoener te vinden. Dit is traag en vaak niet doorslaggevend, omdat het echte knelpunt vaak helemaal geen plugin is, maar één te grote afbeelding. Bekijk eerst het gedeelte "Diagnose" van het PageSpeed Insights-rapport — dat noemt het werkelijke LCP-element en somt de specifieke bronnen op die het renderen blokkeren, wat een veel sneller startpunt is dan trial-and-error uitschakelen.
Tot slot
Een rode PageSpeed Insights-score op WordPress voelt alsof je een hosting-upgrade of complete thema-herbouw nodig hebt, maar in de praktijk is de oplossing bijna altijd beperkter: breng afbeeldingen naar een modern formaat op de juiste grootte, stop met het blokkeren van renderen met onnodige scripts, cache wat gecachet kan worden, en snoei plugins die bestanden laden die ze niet nodig hebben. Werk deze vier punten in volgorde af en test na elk opnieuw — meestal weet je al na de eerste of tweede stap welke fix het echte werk doet.
Blijken afbeeldingen je grootste probleem te zijn (dat is meestal zo), dan automatiseert Erdo Image Optimizer de hierboven beschreven formaatconversie, afmetingswaarschuwingen en lazy-loading-audit, waardoor het een eenmalige instelling wordt in plaats van een terugkerende handmatige controle.