Sinds 2021 gebruikt Google de laadsnelheid van pagina's officieel als ranking-factor via Core Web Vitals. Dit is niet langer een optionele best practice, het is een meetbaar ranking-signaal dat rechtstreeks je positie in de zoekresultaten beïnvloedt.
Core Web Vitals: wat Google echt meet
Core Web Vitals zijn een set metrieken die Google standaardiseerde om de echte gebruikerservaring van een website te meten. Er zijn er drie belangrijke:
- ,LCP (Largest Contentful Paint), tijd tot het grootste zichtbare element op de pagina geladen is. Doel: < 1,2s. Aanvaardbaar: 1,2-2,5s. Slecht: > 2,5s.
- ,CLS (Cumulative Layout Shift), meet onverwachte visuele verschuivingen tijdens het laden. Doel: < 0,1. Aanvaardbaar: 0,1-0,25. Slecht: > 0,25.
- ,INP (Interaction to Next Paint), reactiviteit op gebruikersinteracties. Doel: < 200ms. Aanvaardbaar: 200-500ms. Slecht: > 500ms.
Hoe Google deze metrieken gebruikt voor ranking
Google verzamelt performancedata via het Chrome User Experience Report (CrUX), echte navigatiedata van miljoenen Chrome-gebruikers. Dat zijn geen labtests: het zijn metingen uit het echte veld. Ervaren je bezoekers een trage LCP, dan weet Google dat.
Die data beïnvloedt de ranking via het Page Experience-signaal. Bij zoekopdrachten waar meerdere pagina's content van gelijkwaardige kwaliteit hebben, wordt de pagina met de betere gebruikerservaring bevoordeeld. Op concurrentiële zoekwoorden kan dat verschil meerdere posities betekenen, en elke extra positie op pagina één staat voor een aanzienlijke kloof in verkeer.
Waarom de meeste WordPress-sites zakken voor deze test
WordPress staat structureel in het nadeel op Core Web Vitals. Het kernprobleem is de dynamische server-side rendering: elke pagina wordt on the fly gegenereerd bij de aanvraag, wat een onvermijdelijke latentie van 200 tot 800ms toevoegt voor de browser de eerste byte ontvangt (TTFB).
Cachingplugins (WP Rocket, W3 Total Cache) verbeteren die vertraging door statische pagina's vooraf te genereren, maar ze voegen hun eigen complexiteit toe en kunnen de blokkerende JavaScript-problemen van slecht geoptimaliseerde plugins niet oplossen. Een WordPress-site met 15+ actieve plugins heeft bijna systematisch een LCP boven 2 seconden.
Wat we vonden bij de audit van 50 Belgische websites
Over de laatste 50 sites die we auditeerden voor Belgische bedrijven: 82% van de gescande WordPress-sites had een LCP met label "Verbetering nodig" of "Slecht". 91% van de goed geconfigureerde Next.js-sites had een "Goede" LCP. De correlatie tussen technologie en performance is rechtstreeks.
De SEO-winst die we maten na migratie van WordPress naar Next.js: een mediane stijging van het organische verkeer van +47% binnen 90 dagen na de migratie, met uitschieters tot +180%. Technische performance vertaalt zich rechtstreeks in zichtbaarheid.
De optimalisaties die de LCP echt bewegen
- ,Static Site Generation, pagina's vooraf renderen als statische HTML schakelt de servergeneratietijd volledig uit.
- ,Edge CDN, pagina's serveren vanaf de server het dichtst bij de gebruiker (Vercel Edge Network: 100+ aanwezigheidspunten wereldwijd).
- ,Beeldoptimalisatie, AVIF/WebP-formaten, lazy loading, adaptieve formaten. next/image regelt dit automatisch.
- ,Lettertypes laden, font-display: swap gebruiken en kritieke fonts preloaden voorkomt FOIT (Flash of Invisible Text).
- ,Render-blokkerende CSS elimineren, kritieke CSS inline zetten, de rest uitstellen.
- ,JavaScript verminderen, agressieve code splitting, verwijderen van niet-essentiële externe scripts.
CLS: het onzichtbare probleem
CLS (Cumulative Layout Shift) is de meest onderschatte metriek. Ze meet hoeveel de pagina-inhoud "springt" tijdens het laden, wanneer beelden zonder vaste afmetingen verschijnen en tekst naar beneden duwen, of wanneer een advertentie zich tussen paragrafen wringt.
Een hoge CLS komt vooral voor op sites met advertenties, slecht beheerde cookiebanners, of beelden zonder expliciete width- en height-attributen. Om ze te elimineren: geef altijd de beeldafmetingen op, reserveer ruimte voor asynchroon geladen elementen, en vermijd content boven de vouw in te voegen na de eerste lading.
Hoe meet je je Core Web Vitals nu
- ,Google Search Console, tabblad "Pagina-ervaring": echte velddata per pagina, opgesplitst per mobiel/desktop.
- ,PageSpeed Insights, combineert CrUX-velddata en een Lighthouse-labaudit.
- ,Chrome DevTools, tabblad Performance: precieze opname van de volledige laad-waterfall.
- ,web.dev/measure, uitgebreide audit met geprioriteerde aanbevelingen.
Wat we in de praktijk doen
Elke site die we opleveren doorloopt een systematische Lighthouse-audit voor de lancering. Onze minimumdoelen: LCP < 1,2s, CLS < 0,05, INP < 200ms, Lighthouse Performance ≥ 95. Dat zijn geen marketingcijfers, ze zijn meetbaar en verifieerbaar in Google Search Console 30 dagen na de lancering.
Heeft je site het moeilijk om te ranken ondanks goede content, dan is technische performance wellicht de ontbrekende schakel. Een audit duurt minder dan een uur. Neem contact op om er een in te plannen.