Een klant die op zijn telefoon zoekt naar een elektricien, wacht niet graag. Als je site traag laadt, tikt hij terug en kiest hij het volgende resultaat. Snelheid is dus geen technisch detail, het is het verschil tussen een telefoontje en een gemiste klant.
Google meet die snelheid met drie cijfers, samen de Core Web Vitals. Ze klinken technisch, maar wat ze meten is heel herkenbaar: hoe snel zie je iets, hoe snel reageert de pagina en springt alles niet heen en weer. In dit artikel leggen we ze uit, met de drempelwaarden die Google zelf hanteert.
Wat zijn Core Web Vitals?
Core Web Vitals zijn drie meetwaarden die Google gebruikt om de ervaring van bezoekers op een webpagina te beoordelen. Ze komen van het Web Vitals-initiatief van Google, beschreven op web.dev. Elk cijfer meet iets anders:
- LCP (Largest Contentful Paint): laden.
- INP (Interaction to Next Paint): reageren.
- CLS (Cumulative Layout Shift): stabiliteit.
De drempelwaarden
Google deelt elke meetwaarde in drie groepen in: goed, verbetering nodig en slecht. De grenzen staan in het artikel Defining the Core Web Vitals metrics thresholds op web.dev:
| Meetwaarde | Goed | Verbetering nodig | Slecht |
|---|---|---|---|
| LCP | 2,5 seconden of minder | tussen 2,5 en 4 seconden | meer dan 4 seconden |
| INP | 200 milliseconden of minder | tussen 200 en 500 milliseconden | meer dan 500 milliseconden |
| CLS | 0,1 of minder | tussen 0,1 en 0,25 | meer dan 0,25 |
Belangrijk is hoe Google meet. Volgens web.dev kijk je naar het 75e percentiel van de paginabezoeken, apart voor mobiel en desktop. Simpel gezegd: drie van de vier bezoeken moeten de grens halen. Een site die op jouw snelle wifi goed laadt, kan voor een klant met een oudere telefoon en slecht bereik dus nog steeds te traag zijn.
LCP: hoe snel zie je iets?
LCP meet hoe lang het duurt voordat het grootste zichtbare stuk inhoud op het scherm staat. Meestal is dat een grote foto bovenaan de pagina, of een blok tekst. Volgens web.dev moet dat binnen 2,5 seconden na het begin van het laden gebeuren.
Waardoor is LCP traag?
- Te grote foto’s. Een foto rechtstreeks van je telefoon kan vele megabytes zijn. Op een website heb je maar een fractie nodig.
- Een trage server. Goedkope hosting die veel sites tegelijk draait, reageert soms traag.
- Te veel software die eerst moet laden. Lettertypen, scripts, sliders, chatknoppen, cookiebanners. Alles wat eerst moet laden, houdt de rest op.
- Een slider of video bovenaan. Mooi in het ontwerp, maar vaak de grootste vertraging.
Wat helpt?
- Verklein foto’s tot het formaat dat echt nodig is, en gebruik moderne formaten zoals WebP of AVIF.
- Zet de belangrijkste foto bovenaan niet achter een slider of animatie.
- Kies hosting die snel reageert, het liefst met een netwerk van servers dicht bij je bezoekers (een CDN).
- Laad alleen de scripts die je echt gebruikt.
INP: hoe snel reageert de pagina?
INP meet hoe lang het duurt voordat de pagina zichtbaar reageert als iemand iets doet: op een knop tikken, een menu openen, een veld in een formulier invullen. Volgens web.dev is 200 milliseconden of minder goed. Dat is een vijfde van een seconde. Alles daarboven voelt als een pagina die even hapert.
INP verving in 2024 de oudere meetwaarde FID, die alleen naar de eerste klik keek. INP kijkt naar alle interacties tijdens het bezoek.
Waardoor is INP traag?
Vrijwel altijd door JavaScript: code die in de browser draait en de pagina bezighoudt. Denk aan zware thema’s, paginabouwers, veel plugins, trackingscripts, chatwidgets en advertenties. Terwijl de browser met die code bezig is, kan hij niet reageren op jouw tik.
Wat helpt?
- Minder scripts. Elke plugin of widget die je niet echt nodig hebt, eruit.
- Geen zware paginabouwer voor een eenvoudige site.
- Trackingscripts kritisch bekijken. Heb je ze echt allemaal nodig?
CLS: springt de pagina?
Je kent het: je wilt op een knop tikken, er laadt nog een foto of banner boven, de pagina schuift op en je tikt op iets anders. Dat is wat CLS meet. Volgens web.dev is een score van 0,1 of minder goed.
Waardoor verspringt een pagina?
- Foto’s zonder vaste afmetingen. De browser weet niet hoeveel ruimte hij moet vrijhouden, dus schuift alles op als de foto binnenkomt.
- Banners en meldingen die bovenaan verschijnen, zoals een cookiebalk die de pagina naar beneden duwt.
- Lettertypen die laat laden en de tekst ineens een andere grootte geven.
- Advertenties of ingesloten blokken zonder vaste ruimte.
Wat helpt?
- Geef foto’s en video’s vaste breedte en hoogte in de code.
- Laat cookiemeldingen over de pagina heen verschijnen in plaats van de inhoud weg te duwen.
- Reserveer ruimte voor alles wat later laadt.
Hoe meet je het zelf?
PageSpeed Insights
Ga naar PageSpeed Insights van Google en vul het adres van je site in. Je krijgt twee soorten cijfers:
- Gegevens van echte gebruikers. Heeft je site genoeg bezoekers, dan zie je hier hoe snel de site werkelijk was voor mensen die hem bezochten. Dit zijn de cijfers die tellen.
- Een labtest. Een gesimuleerde meting op dat moment. Handig om problemen te vinden, maar niet hetzelfde als echte bezoekers.
Kijk vooral naar het tabblad voor mobiel. Daar zitten de meeste van je klanten.
Google Search Console
Heb je Search Console gekoppeld aan je site, dan vind je daar een rapport over Core Web Vitals. Het laat zien welke groepen pagina’s goed scoren en welke niet. Kleine sites met weinig bezoekers hebben soms te weinig gegevens; dan blijft het rapport leeg.
Test op je eigen telefoon
Open je site op je telefoon, op 4G, buiten je eigen wifi. Hoe voelt het? Zie je snel iets? Springt er iets? Kun je meteen bellen? Dat zegt soms meer dan elk cijfer.
Hoe belangrijk is snelheid voor Google?
Google raadt in de documentatie over Core Web Vitals sterk aan om goede scores te halen, en schrijft dat ze samen met andere aspecten van de pagina-ervaring aansluiten bij wat de rankingsystemen willen belonen. Hoe zwaar ze meewegen, zegt Google niet. Wees dus realistisch: een snelle site met slechte inhoud komt niet bovenaan, en een iets tragere site met de beste inhoud kan prima scoren. Snelheid is geen wondermiddel.
Het grootste voordeel zit bij de bezoeker zelf. Een site die snel laadt, rustig blijft staan en meteen reageert, is prettiger. Dat merk je aan het aantal mensen dat belt of een formulier invult, niet alleen aan je positie in Google.
Waarom sommige sites traag zijn
Veel trage sites van kleine bedrijven hebben dezelfde oorzaak: ze zijn gebouwd met een systeem dat veel meer kan dan nodig is. Een zwaar thema, een paginabouwer en tien plugins voor een site van acht pagina’s. Elk onderdeel voegt code toe die geladen moet worden.
Een eenvoudige site hoeft niet zo gebouwd te worden. Een statische site, waarbij de pagina’s van tevoren worden klaargezet en direct worden geserveerd, heeft geen database en geen plugins die bij elk bezoek moeten draaien. Meer over die afweging lees je in WordPress of niet.
Wil je overstappen naar een snellere site, let dan op dat je je bestaande vindbaarheid niet kwijtraakt. Hoe dat werkt, lees je in overstappen zonder posities te verliezen.
Snelle checklist
- Zijn je foto’s verkleind en in een modern formaat?
- Staat er bovenaan geen zware slider of video?
- Heb je alleen de scripts en plugins die je echt gebruikt?
- Hebben foto’s vaste afmetingen?
- Duwt je cookiemelding de pagina niet weg?
- Is je hosting snel en dicht bij je bezoekers?
- Heb je de mobiele score in PageSpeed Insights bekeken?
Hoe De Jong Websites dit regelt
Wij bouwen geen sites op WordPress en gebruiken geen plugins. Elke site is een snelle statische site, gebouwd met Astro en gehost op Cloudflare, met SSL en bescherming tegen aanvallen. We bewaken je site elke minuut en maken dagelijks een back-up. Lees meer over hosting en onderhoud of bekijk de prijs.