Core Web Vitals uitgelegd:
waarom website snelheid ertoe doet.
Google meet hoe snel je website laadt, hoe snel hij reageert en hoe stabiel hij eruitziet. Die scores beinvloeden je ranking. Dit is wat ze betekenen en hoe je ze verbetert.
Wat zijn Core Web Vitals?
Core Web Vitals zijn drie meetbare prestatie-indicatoren die Google gebruikt om de gebruikerservaring van je website te beoordelen. Sinds 2021 zijn ze een officiële rankingfactor: bij gelijke relevantie geeft Google de voorkeur aan websites met betere Core Web Vitals scores. Het zijn geen vage richtlijnen maar harde meetwaarden die je kunt testen, meten en verbeteren.
De drie metrics meten elk een ander aspect van de gebruikerservaring:
LCP — Largest Contentful Paint
Wat het meet: hoe lang het duurt voordat het grootste zichtbare element op je pagina geladen is. Dat is meestal de hero afbeelding, een video thumbnail of een groot tekstblok. LCP meet wat de bezoeker ervaart als “de pagina is geladen.”
Grenswaarden:
- Goed: onder 2.5 seconden
- Moet beter: 2.5 tot 4.0 seconden
- Slecht: boven 4.0 seconden
Wat het beinvloedt: server responstijd (TTFB), afbeelding formaat en compressie, render-blocking CSS en JavaScript, font loading strategie. Een trage server of een hero afbeelding van 3 MB is de meest voorkomende oorzaak van een slechte LCP.
INP — Interaction to Next Paint
Wat het meet: hoe snel je website reageert op interactie. Een klik op een knop, een tik op een menu, het invullen van een formulierveld. INP meet de tijd tussen de interactie en het moment dat de browser de visuele update toont. Het verving FID (First Input Delay) in maart 2024 en is strenger: FID mat alleen de eerste interactie, INP meet alle interacties gedurende het hele bezoek.
Grenswaarden:
- Goed: onder 200 milliseconden
- Moet beter: 200 tot 500 milliseconden
- Slecht: boven 500 milliseconden
Wat het beinvloedt: JavaScript uitvoering op de main thread, third-party scripts (analytics, chat widgets, social media embeds), complexe DOM manipulatie, event handlers die te veel werk doen. Elke tracker, elke widget en elke animatie die JavaScript draait, maakt je INP potentieel slechter.
CLS — Cumulative Layout Shift
Wat het meet: hoe stabiel de layout van je pagina is tijdens het laden. Als je een artikel begint te lezen en de tekst ineens naar beneden springt omdat er een banner boven verschijnt, is dat een layout shift. CLS telt al die verschuivingen op tot een score.
Grenswaarden:
- Goed: onder 0.1
- Moet beter: 0.1 tot 0.25
- Slecht: boven 0.25
Wat het beinvloedt: afbeeldingen zonder width/height attributen, fonts die laat laden en tekst laten verspringen (FOUT — Flash of Unstyled Text), dynamisch ingevoegde content (advertenties, cookie banners, chat widgets), CSS dat niet efficient geladen wordt.
Waarom Core Web Vitals je ranking beinvloeden
Google’s logica is simpel: ze willen gebruikers naar websites sturen die een goede ervaring bieden. Een website die 6 seconden laadt, niet reageert op klikken en waarbij de layout verspringt is een slechte ervaring. Google wil die websites niet bovenaan hun zoekresultaten tonen, ongeacht hoe goed de content is.
De impact in cijfers
Core Web Vitals zijn niet de belangrijkste rankingfactor. Content relevantie, backlinks en zoekintentie wegen zwaarder. Maar bij gelijke relevantie geven Core Web Vitals de doorslag. En in competitieve markten waar meerdere websites vergelijkbare content hebben, maakt dat verschil het verschil tussen pagina 1 en pagina 2.
De indirecte impact is minstens zo groot. Onderzoek van Google toont dat:
- 53% van de mobiele bezoekers een pagina verlaat als die langer dan 3 seconden laadt
- Elke extra seconde laadtijd het bouncepercentage met 32% verhoogt
- Websites die van “slecht” naar “goed” gaan op Core Web Vitals gemiddeld 24% minder abandonments zien
Die bouncepercentages zijn zelf ook weer een signaal voor Google. Een hoog bouncepercentage vertelt Google dat bezoekers niet vinden wat ze zoeken of dat de ervaring zo slecht is dat ze weggaan. Beide zijn slecht voor je ranking.
De impact op conversie
Snelheid beinvloedt niet alleen je ranking maar ook wat bezoekers doen als ze op je website zijn. Een webshop die in 1 seconde laadt converteert beter dan dezelfde webshop die in 4 seconden laadt. Niet een beetje beter. Significant beter. Vodafone verbeterde hun LCP met 31% en zag 8% meer verkoop. NDTV verbeterde hun LCP met 55% en zag 50% minder bouncepercentage.
Voor een MKB webshop met €100.000 omzet per jaar kan het verschil tussen een website met goede en slechte Core Web Vitals duizenden euro’s aan gemiste omzet per jaar betekenen. Niet door het product, niet door de prijs, maar door laadtijd.
Wat zijn jouw Core Web Vitals?
Onze scanner checkt je website op meer dan 90 punten, waaronder performance, server configuratie en beveiligingsheaders. Scan je website en zie direct waar het beter kan.
De 6 grootste oorzaken van trage websites
De meeste trage websites zijn niet traag door een slechte internetverbinding of een langzame computer van de bezoeker. Ze zijn traag door keuzes die gemaakt zijn bij de bouw en het beheer. Dit zijn de meest voorkomende oorzaken die wij dagelijks tegenkomen.
1. Pagebuilders: de onzichtbare ballast
Elementor, WPBakery, Divi en andere pagebuilders zijn populair omdat ze het bouwen van websites makkelijker maken. Maar die flexibiliteit heeft een prijs. Een Elementor pagina genereert gemiddeld 3 tot 5 keer zoveel HTML als handgeschreven code. Een simpele sectie met een heading, een paragraaf en een knop wordt in Elementor een boom van 15 tot 20 geneste div elementen met inline styles. Dat is meer HTML voor de browser om te parsen, meer CSS om toe te passen en meer DOM nodes om in het geheugen te houden.
Daar bovenop laden pagebuilders hun eigen CSS en JavaScript frameworks op elke pagina, ongeacht of je die features gebruikt. Elementor laadt standaard 200-400 KB aan eigen CSS en JS. Een custom geschreven pagina die hetzelfde doet komt uit op 20-50 KB. Dat is niet een subtiel verschil. Dat is een factor 5 tot 10 aan onnodige ballast.
We hebben het verschil uitgebreid vergeleken in ons artikel over Elementor vs custom themes. Het probleem gaat verder dan snelheid — lees waarom de implementatie het verschil maakt.
2. Te veel plugins
Elke WordPress plugin laadt potentieel CSS en JavaScript op elke pagina van je website, ook op pagina’s waar de plugin niet wordt gebruikt. Een contactformulier plugin laadt zijn CSS op je homepage. Een slider plugin laadt zijn JavaScript op je blog. Een security plugin scant elke request. Tien plugins is normaal. Twintig is veel. Dertig tot veertig is wat we regelmatig tegenkomen. Elk van die plugins voegt milliseconden toe aan je laadtijd en complexity aan je codebase.
3. Ongeoptimaliseerde afbeeldingen
De meest voorkomende oorzaak van een slechte LCP. Een hero afbeelding die recht uit de camera op de website staat: 4.000 pixels breed, JPEG kwaliteit 100%, 3 MB groot. Terwijl de bezoeker op een mobiel scherm van 400 pixels breed kijkt. Die 3 MB wordt gedownload, en de browser schaalt hem naar 400 pixels. Dat is alsof je een vrachtwagen stuurt om een envelop te bezorgen.
Moderne websites serveren afbeeldingen in WebP of AVIF formaat (30-50% kleiner dan JPEG), in de juiste afmeting voor het scherm (responsive images met srcset), lazy loaded voor afbeeldingen onder de fold (die pas laden als je naar beneden scrollt) en met expliciete width en height attributen (voorkomt CLS).
4. Third-party scripts
Google Analytics, Facebook Pixel, Google Tag Manager, Hotjar, Intercom, cookie consent tools, chat widgets, social media embeds. Elke third-party script is een extra netwerk request naar een externe server, extra JavaScript dat geparsed en uitgevoerd moet worden, en vaak extra tracking cookies die geschreven worden. Een gemiddelde website met Google Analytics, een cookie banner en een chat widget laadt 300-500 KB aan third-party JavaScript. Dat is meer dan de meeste hele websites zouden moeten wegen.
En die scripts draaien op de main thread van de browser, dezelfde thread die verantwoordelijk is voor het renderen van je pagina en het afhandelen van gebruikersinteractie. Dat is waarom third-party scripts je INP score verwoesten: elke klik moet wachten tot het JavaScript van die trackers klaar is.
5. Trage server responstijd (TTFB)
Time To First Byte: de tijd tussen het verzoek van de browser en het eerste byte van de server response. Als je server er 800 milliseconden over doet om te antwoorden, kan je LCP nooit onder de 2.5 seconden komen, hoeveel je ook optimaliseert aan de frontend. TTFB is een serverzijde probleem: shared hosting met overbelaste servers, geen server-side caching, ongeoptimaliseerde database queries, verouderde PHP versies.
Een goed geconfigureerde server met LiteSpeed caching en Redis haalt een TTFB van 100-200 milliseconden. Shared hosting zonder caching zit vaak op 600-1200 milliseconden. Dat verschil van een halve tot hele seconde is de basis waarop alles erna wordt gebouwd.
6. Render-blocking resources
CSS en JavaScript bestanden die geladen moeten zijn voordat de browser de pagina kan tonen. Elke stylesheet en elk script in de head van je HTML is potentieel render-blocking. De browser stopt met renderen, download het bestand, parseert het en gaat dan pas verder. Bij 10 stylesheets en 15 scripts (niet ongebruikelijk bij websites met veel plugins) kan dat seconden aan vertraging opleveren.
De oplossing is critical CSS inline in de head plaatsen (alleen de CSS die nodig is voor wat de bezoeker als eerste ziet), de rest asynchroon laden en JavaScript deferen of asynchroon laden. Bij handgeschreven code is dat eenvoudig te implementeren. Bij pagebuilder websites met tientallen plugin stylesheets is het een nachtmerrie.
Custom code vs pagebuilder:
de impact op snelheid.
Wat het verschil in code aanpak betekent voor je Core Web Vitals.
Custom code
- 20-50 KB CSS en JS per pagina
- Schone HTML: alleen de elementen die nodig zijn
- Critical CSS inline, rest asynchroon
- Afbeeldingen in WebP/AVIF met srcset en lazy loading
- Lighthouse score 95-100
- TTFB onder 200ms met server-side caching
- Volledige controle over elke kilobyte
Pagebuilder
- 200-400 KB aan framework CSS en JS, op elke pagina
- 15-20 geneste div's per sectie, inline styles, data attributen
- Alles in de head, render-blocking
- Basis img tags, vaak zonder responsive formaten
- Lighthouse score 40-65 (met dezelfde content)
- Afhankelijk van hosting, vaak 400-800ms+
- Geen controle over framework overhead
Dezelfde content. Dezelfde server. Maar een factor 3-5 verschil in laadtijd door hoe de code is geschreven.
Core Web Vitals verbeteren: wat werkt echt
Er zijn honderden artikelen met “tips om je website te versnellen.” De meeste raden plugins aan die het probleem maskeren in plaats van oplossen. Dit is wat daadwerkelijk werkt, in volgorde van impact.
Server-side: de basis moet goed zijn
Geen enkele frontend optimalisatie compenseert voor een trage server. Begin hier:
- Goede hosting — Managed hosting met LiteSpeed webserver en Redis object caching. Geen shared hosting met Apache en geen caching. Dit alleen al kan je TTFB halveren. Onze managed hosting draait standaard op LiteSpeed met Redis.
- Actuele PHP versie — PHP 8.3 is tot 40% sneller dan PHP 7.4 voor WordPress. PHP 8.2 en ouder ontvangen geen beveiligingspatches meer. Upgrade is gratis en de snelheidswinst is direct meetbaar.
- Database optimalisatie — WordPress databases groeien. Revisies, transients, vervallen opties, spam comments. Regelmatig opschonen houdt je queries snel.
- Server-side page caching — LiteSpeed Cache, Varnish of vergelijkbaar. Statische pagina’s worden geserved vanuit het cachegeheugen zonder dat WordPress en PHP hoeven op te starten. Het verschil: 800ms wordt 80ms.
Afbeeldingen: de grootste quick win
- WebP of AVIF formaat — 30-50% kleiner dan JPEG bij dezelfde visuele kwaliteit. Wordt ondersteund door alle moderne browsers.
- Responsive images met srcset — Serveer een 400px breed afbeelding op mobiel, 800px op tablet, 1200px op desktop. Niet een 3000px afbeelding die de browser zelf moet schalen.
- Lazy loading — Afbeeldingen onder de fold laden pas als de bezoeker naar beneden scrollt. De hero afbeelding en alles zichtbaar in het eerste scherm (above the fold) laden direct.
- Expliciete width en height — Voorkomt layout shifts (CLS). De browser reserveert de ruimte voordat de afbeelding geladen is.
- Preload de LCP afbeelding — De afbeelding die je LCP bepaalt (meestal de hero) kun je preloaden met een link rel=“preload” tag. De browser begint dan eerder met downloaden.
Code: minder is sneller
- Verwijder ongebruikte plugins — Elke plugin die je niet actief gebruikt, deactiveer en verwijder. Niet alleen deactiveren: sommige plugins laden nog steeds bestanden als ze gedeactiveerd zijn.
- Minimaliseer third-party scripts — Heb je echt Google Analytics nodig? Of is cookievrije self-hosted analytics (zoals Matomo) een beter alternatief dat geen cookiebanner vereist en geen extra JavaScript laadt? Heb je echt een chat widget nodig of is een telefoon en e-mailadres voldoende?
- Critical CSS — De CSS die nodig is voor het eerste scherm (above the fold) inline in de head plaatsen. De rest asynchroon laden. Dit elimineert render-blocking stylesheets.
- JavaScript deferred laden — Scripts die niet nodig zijn voor de eerste render, laad ze met defer of async. Dat ontblokkeert het renderen en verbetert zowel LCP als INP.
- Font loading strategie — Self-host je fonts (geen Google Fonts CDN), gebruik font-display: swap en preload je primaire font. Voorkomt layout shifts door late font loading en elimineert een externe dependency.
Hoe meet je het?
Er zijn twee soorten metingen: lab data en field data. Beide zijn belangrijk.
- Google Lighthouse — Lab test in je browser (Chrome DevTools > Lighthouse). Simuleert een gemiddeld mobiel apparaat op een gemiddelde verbinding. Geeft een score van 0-100 en specifieke verbeterpunten. Goed voor ontwikkeling en diagnose.
- PageSpeed Insights — Combineert lab data (Lighthouse) met field data (echte gebruikers via Chrome User Experience Report). De field data toont hoe echte bezoekers je website ervaren. Dit is wat Google daadwerkelijk gebruikt voor ranking.
- Google Search Console — Core Web Vitals rapport dat toont hoeveel van je pagina’s “goed”, “moet beter” of “slecht” scoren op basis van field data. Geeft je een overzicht van je hele website, niet alleen individuele pagina’s.
- WebPageTest.org — Gedetailleerde waterfall analyse die precies laat zien welke resources wanneer laden. Onmisbaar voor het diagnosticeren van specifieke bottlenecks.
Meet regelmatig. Core Web Vitals veranderen als je content toevoegt, plugins update of je server configuratie wijzigt. Een maandelijkse check houdt je scherp.
Waarom de meeste websites slecht scoren
Als je de Core Web Vitals van willekeurige Nederlandse bedrijfswebsites test, scoor het merendeel “slecht” of “moet beter” op minimaal een van de drie metrics. Dat is geen toeval. Het is het gevolg van hoe de meeste websites gebouwd worden.
Het standaard recept
De meeste webdesign bureaus bouwen websites op dezelfde manier: een premium WordPress theme van de plank (Astra, GeneratePress, of een Themeforest theme), Elementor of WPBakery als pagebuilder, 15 tot 25 plugins voor functionaliteit, Google Analytics en een Facebook Pixel voor tracking, Google Fonts via het CDN, en shared hosting bij een goedkope provider. Het resultaat is een website die er prima uitziet maar Lighthouse scores haalt van 40 tot 65 op mobiel.
Dat is geen slechte intentie. Het is een economisch model. Een website bouwen met pagebuilders kost minder uren dan handgeschreven code. Minder uren betekent een lagere prijs. Een lagere prijs betekent meer klanten. Maar de website betaalt de prijs: elke dag, bij elke bezoeker, in elke zoekopdracht.
Het verschil van handgeschreven code
Een custom geschreven WordPress website met een op maat gebouwd theme laadt fundamenteel anders. Geen pagebuilder overhead. Geen 25 plugins die elk hun eigen CSS en JavaScript laden. Geen framework van 400 KB dat op elke pagina meekomt. In plaats daarvan: alleen de code die nodig is voor die specifieke pagina, niet meer en niet minder.
Het resultaat is meetbaar. Onze websites scoren consistent boven de 95 op Google Lighthouse, met laadtijden onder 1 seconde. Niet omdat we magische trucs toepassen, maar omdat we code schrijven in plaats van bij elkaar te klikken. Minder code betekent minder te laden. Minder te laden betekent sneller. Het is geen rocket science.
Veelgestelde vragen over Core Web Vitals.
Website te traag?
Wij bouwen websites met handgeschreven code die consistent boven de 95 scoren op Lighthouse. Geen pagebuilders, geen bloat, geen compromissen op snelheid.