Core Web Vitals: waarom snelheid je vindbaarheid maakt of kraakt

Een mooie website die traag laadt, verliest bezoekers voor ze iets gezien hebben. Google goot die ervaring in meetbare cijfers: de Core Web Vitals. Ze bepalen mee hoe je rankt en hoe gebruiksvriendelijk je site aanvoelt. Wie ze begrijpt, begrijpt ook waarom architectuur belangrijker is dan een laatste optimalisatieronde: een site die licht begint, scoort bijna vanzelf beter dan een site die je achteraf moet proberen recht te trekken.

Wat zijn de Core Web Vitals precies?

De Core Web Vitals zijn drie meetwaarden die samen benaderen hoe een echte bezoeker je site ervaart, niet hoe ze er in een ideaal labo uitziet.

• LCP (Largest Contentful Paint): hoe snel is de grootste inhoud (vaak een hero-beeld of titel) zichtbaar? Dit meet de gevoelde laadsnelheid.
• INP (Interaction to Next Paint): hoe snel reageert de pagina wanneer iemand klikt, tikt of typt? Dit meet de vlotheid.
• CLS (Cumulative Layout Shift): hoeveel verspringt de layout tijdens het laden? Dit meet visuele stabiliteit.

Welke drempelwaarden gelden als goed?

Google legt per meetwaarde duidelijke grenzen vast (bron: web.dev). Ze gelden voor het 75e percentiel van je bezoekers, dus voor de grote meerderheid moet je site eronder blijven.

Meetwaarde	Goed	Voor verbetering vatbaar	Slecht
LCP	tot 2,5 s	2,5 tot 4 s	meer dan 4 s
INP	tot 200 ms	200 tot 500 ms	meer dan 500 ms
CLS	tot 0,1	0,1 tot 0,25	meer dan 0,25

Het mikpunt is dus niet “zo snel mogelijk” in absolute zin, maar onder deze grenzen blijven voor zoveel mogelijk echte bezoekers, ook op een gemiddelde telefoon.

Waarom is JavaScript de grootste vijand?

De meeste trage sites hebben hetzelfde probleem: te veel JavaScript. De browser moet het downloaden, parsen en uitvoeren voor de pagina echt bruikbaar is. Dat duwt de LCP omhoog en maakt de INP traag, zeker op een toestel met minder rekenkracht.

Hoe minder JavaScript je verstuurt, hoe minder werk de browser heeft, en hoe beter je scores. Daarom is de hoeveelheid verzonden JavaScript zo bepalend, en daarom verliezen sites met veel plugins of een zware clientside-aanpak hier vaak punten.

Wat is het verschil tussen labdata en velddata?

Dit verwart veel mensen. Een Lighthouse-test in je browser is labdata: een meting in een gecontroleerde omgeving, handig om problemen op te sporen. De cijfers die Google voor de ranking gebruikt komen uit velddata, het Chrome User Experience Report (CrUX), gebaseerd op echte bezoekers met echte toestellen en verbindingen.

Een groene Lighthouse-score is dus geen garantie: als je echte bezoekers op trage telefoons zitten, kan je velddata tegenvallen. Stuur daarom op de velddata, niet op een labgetal.

De uitgangspositie van een content-first stack

Hier zit het structurele voordeel van Astro. Door pagina’s als statische HTML te leveren en standaard weinig JavaScript te versturen, vertrekt een Astro-site vanuit een betere uitgangspositie voor de Core Web Vitals. Je hoeft niet achteraf te vechten tegen plugin-scripts; je begint licht.

Onafhankelijke data ondersteunt dat. Volgens Search Engine Journal, op basis van het HTTP Archive en CrUX (data april 2026), haalt ongeveer 67% van de Astro-sites een goede Core Web Vitals-score, tegenover ongeveer 49% van de WordPress-sites. Belangrijke nuance: dat verschil weerspiegelt mede het type sites, en het voordeel kan afnemen naarmate een site complexer wordt. Het zegt iets over de standaard-uitgangspositie, niet dat elke site automatisch sneller wordt.

Dat is geen garantie op een perfecte score (beelden, fonts en third-party scripts spelen ook mee), maar wel het verschil tussen vechten tegen een zware basis en vertrekken vanuit een lichte. Hoe die aanpak technisch werkt, lees je in de islands-architectuur uitgelegd.

Hoe meet je je Core Web Vitals?

Je hoeft niets te gokken; de tools zijn gratis.

• PageSpeed Insights: plak een URL en je krijgt zowel lab- als velddata per pagina, met concrete aanbevelingen.
• Google Search Console: het rapport Core Web Vitals toont hoe je hele site het doet op basis van echte bezoekers, gegroepeerd per type pagina.
• Lighthouse (in de browser): handig tijdens het bouwen om regressies vroeg te vangen.

Begin bij Search Console voor het overzicht, en gebruik PageSpeed Insights om een specifieke trage pagina uit te pluizen.

Veelgemaakte fouten die je scores kraken

• Beelden zonder vaste afmetingen, waardoor de layout verspringt (slechte CLS).
• Een zwaar hero-beeld dat de LCP de hoogte injaagt; comprimeer het en lever moderne formaten.
• Render-blocking scripts van derden (chatwidgets, trackers) die vroeg laden.
• Te veel of te vroeg geladen JavaScript dat de INP traag maakt.
• Webfonts die laat inladen en tekst doen verspringen of verbergen.

SEO en GEO: twee keer dezelfde winst

Snelheid betaalt zich dubbel uit. Voor klassieke SEO zijn de Core Web Vitals een van de signalen voor gebruikerservaring, en snelle pagina’s worden vlotter gecrawld. Voor GEO, de zichtbaarheid in AI-antwoordmachines, telt dat content snel, semantisch en goed gestructureerd opgehaald kan worden. Schone, snelle HTML dient beide tegelijk. Of je nu voor Google of voor een AI-assistent optimaliseert, je bouwt aan dezelfde fundamenten.

Praktische checklist

• Geef beelden en embeds vaste afmetingen, zodat ze geen layout-shift veroorzaken.
• Laad alleen JavaScript waar interactie nodig is (de islands-aanpak).
• Stel zware, niet-kritieke scripts uit tot na het laden.
• Self-host je fonts en preload alleen wat boven de vouw nodig is.
• Comprimeer beelden en serveer moderne formaten.
• Meet met velddata, niet alleen met een labtest.

Conclusie

Core Web Vitals zijn geen aparte taak op je to-dolijst, ze zijn een gevolg van hoe je site gebouwd is. Begin je licht, met weinig JavaScript en stabiele HTML, dan win je zowel bij Google als bij AI-zoekmachines, en hoef je achteraf veel minder bij te sturen. Wil je zien hoe die aanpak in de praktijk werkt, lees dan waarom Astro snel is by design of hoe Astro zich verhoudt tot WordPress.