Laadsnelheid en SEO: beïnvloedt de snelheid van je site je Google-ranking?

Ja, maar bescheiden. Google zegt dat zijn rankingsystemen Core Web Vitals gebruiken, maar dat relevante content altijd eerst komt en goede scores geen topposities garanderen. De doelen zijn een Largest Contentful Paint (LCP) van 2,5 seconden of minder, een Interaction to Next Paint (INP) van 200 milliseconden of minder en een Cumulative Layout Shift (CLS) van 0,1 of minder, gemeten op het 75e percentiel van echte bezoeken.

Core Web Vitals: wat Google meet

Core Web Vitals zijn metrieken die de echte gebruikerservaring beschrijven. Er zijn er drie, en web.dev raadt aan ze te beoordelen op het 75e percentiel van paginalading, apart voor mobiel en desktop:

• LCP (Largest Contentful Paint): hoe lang het grootste zichtbare element nodig heeft om te laden. Goed: 2,5 s of minder. Verbetering nodig: tot 4 s. Slecht: meer dan 4 s.
• INP (Interaction to Next Paint): hoe snel de pagina op interacties reageert. Goed: 200 ms of minder. Verbetering nodig: tot 500 ms. Slecht: meer dan 500 ms.
• CLS (Cumulative Layout Shift): hoeveel de layout verspringt tijdens het laden. Goed: 0,1 of minder. Verbetering nodig: tot 0,25. Slecht: meer dan 0,25.

INP verving First Input Delay (FID) als Core Web Vital en werd stabiel in 2024. Oudere gidsen die FID vermelden, of een strengere LCP-doelstelling van 1,2 seconden geven, zijn achterhaald.

Hoe Google deze metrieken gebruikt

De uitrol van de pagina-ervaring door Google begon in juni 2021 op mobiel. Zijn documentatie stelt dat Core Web Vitals door zijn rankingsystemen gebruikt worden, maar ook dat Google altijd de meest relevante content wil tonen, zelfs als de pagina-ervaring matig is. Ze voegt eraan toe dat goede resultaten in Search Console of in tools van derden geen topposities garanderen.

In de praktijk telt de pagina-ervaring vooral wanneer meerdere pagina's even nuttig zijn. Snelheid speelt ook na de klik: een trage pagina verliest bezoekers, wat haar ranking ook is.

Waarom veel WordPress-sites het moeilijk hebben

De HTTP Archive Web Almanac 2025 meldt dat ongeveer 45% van de WordPress-sites op mobiel slaagt voor de Core Web Vitals, een van de laagste percentages onder de contentmanagementsystemen die vergeleken worden. Typische oorzaken zijn pagina's die bij elk verzoek op de server gegenereerd worden, veel plugins die elk JavaScript en CSS toevoegen, en zware thema's.

Cachingplugins helpen, maar kunnen het JavaScript dat plugins laden niet wegnemen. Dit is een gemiddelde over alle WordPress-sites, en een zorgvuldig gebouwde site kan slagen.

Wat de LCP echt verbetert

• Pagina's vooraf renderen als statische HTML, zodat de server per verzoek weinig te doen heeft.
• Een contentdeliverynetwerk (CDN), dat pagina's serveert vanaf een locatie dicht bij de bezoeker.
• Beeldoptimalisatie: moderne formaten zoals AVIF of WebP, juiste afmetingen, lazy loading onder de vouw en een geprioriteerde hoofdafbeelding.
• Lettertypes laden: font-display: swap en enkel de kritieke fonts preloaden.
• Minder render-blokkerende CSS en JavaScript, en het weglaten van scripts van derden die je niet nodig hebt.

Google raadt server-side rendering of pre-rendering aan, omdat een site daardoor sneller is voor gebruikers en crawlers en niet elke bot JavaScript kan uitvoeren. Googlebot voert JavaScript wel uit, dus een JavaScript-zware site kan toch geïndexeerd worden, maar vooraf gerenderde HTML is eenvoudiger en sneller.

CLS: de layout die verspringt

CLS meet onverwachte verschuivingen van content tijdens het laden, bijvoorbeeld wanneer een afbeelding zonder vaste afmetingen de tekst naar beneden duwt of een banner verschijnt boven wat je aan het lezen was.

Om het te verminderen geef je afbeeldingen expliciete width- en height-attributen, reserveer je ruimte voor content die later laadt zoals advertenties, embeds en cookiebanners, en vermijd je content in te voegen boven bestaande content na de eerste rendering.

INP: reactiviteit

INP kijkt hoe lang de pagina nodig heeft om te reageren op klikken, tikken en toetsaanslagen gedurende het hele bezoek. Lange JavaScript-taken zijn de gebruikelijke oorzaak: stuur minder JavaScript, splits zware code op en stel scripts uit die niet meteen nodig zijn.

Hoe meet je je Core Web Vitals

• Search Console, rapport Core Web Vitals: velddata gegroepeerd per paginatype, voor mobiel en desktop.
• PageSpeed Insights: toont velddata uit het Chrome User Experience Report wanneer die bestaan, plus een Lighthouse-labtest.
• Chrome DevTools, paneel Performance: een gedetailleerde opname van laden en interacties.

Velddata weerspiegelt echte bezoekers en is wat telt. Labtests zoals Lighthouse helpen om oorzaken te vinden, maar hun score is niet hetzelfde als de Core Web Vitals.

Wat we in de praktijk doen

We controleren elke site met Lighthouse en de hierboven vermelde Core Web Vitals-drempels voor de lancering, en bekijken de velddata in Search Console zodra echte bezoeken binnenkomen. Heeft je site het moeilijk om te ranken ondanks goede content, dan kan performance een factor zijn, maar controleer ook de content, de structuur en of zoekmachines en AI-tools je pagina's kunnen lezen.