Core Web Vitals en pagespeed voor SEO

Een snelle website voelt beter.

Dat merk je meteen.

Pagina’s laden vlotter.
Knoppen reageren sneller.
Elementen springen minder irritant heen en weer.

Voor gebruikers maakt dat veel uit.

Maar ook voor SEO is performance belangrijk. Google gebruikt Core Web Vitals namelijk ook als ranking factor.

Dat betekent niet dat een snelle pagina automatisch bovenaan komt. En ook niet dat een perfecte PageSpeed-score slechte content ineens goed maakt.

Zo werkt het niet.

Core Web Vitals en pagespeed gaan vooral over de technische ervaring van een pagina. Hoe snel ziet iemand de belangrijkste content? Hoe snel reageert de pagina op een klik of tik? En blijft de layout stabiel tijdens het laden?

Dat zijn dingen die gebruikers direct voelen.

En precies daarom horen ze thuis binnen technische SEO.

Niet als losse score-obsessie.

Maar als onderdeel van een betere, snellere en betrouwbaardere website.

🧭 Waarom Core Web Vitals belangrijk zijn voor technische SEO

Core Web Vitals meten onderdelen van gebruikerservaring die technisch beïnvloedbaar zijn.

Laadt een pagina traag?
Reageert een knop langzaam?
Springt content ineens naar beneden?

Dan voelt de pagina minder prettig.

En vaak is dat geen puur designprobleem. Het zit regelmatig in techniek, templates, scripts, afbeeldingen, caching, fonts, hosting of de manier waarop content wordt ingeladen.

Daarom zijn Core Web Vitals belangrijk voor technische SEO.

Ze helpen je problemen concreet maken.

Niet:

“de website voelt traag.”

Maar:

“de belangrijkste content wordt pas na 4,2 seconden zichtbaar.”

Niet:

“de pagina reageert stroperig.”

Maar:

“interacties duren langer dan 500 milliseconden.”

Niet:

“de pagina springt.”

Maar:

“de CLS is te hoog door afbeeldingen zonder vaste afmetingen.”

Dat maakt verbeteren veel gerichter.

Daarbij is er ook een duidelijke link met SEO. Core Web Vitals zijn geen allesbepalende rankingfactor. Een snelle pagina zonder goede content wordt niet ineens een sterke SEO-pagina. Maar Google gebruikt Core Web Vitals wel binnen zijn ranking systems, en geeft breder aan dat geaggregeerde, geanonimiseerde interactiedata helpt beoordelen of zoekresultaten relevant zijn.

Performance is dus geen los technisch speeltje; het raakt hoe gebruikers een pagina ervaren en hoe sterk een resultaat uiteindelijk kan functioneren.

Een sterke pagina moet dus niet alleen inhoudelijk goed zijn.

Hij moet ook prettig werken.

Snel genoeg.
Stabiel genoeg.
Responsief genoeg.

⚡ Wat Core Web Vitals zijn

Core Web Vitals zijn drie metrics waarmee Google belangrijke onderdelen van gebruikerservaring meet.

Ze gaan over:

• laden
• interactie
• visuele stabiliteit

De huidige Core Web Vitals zijn:

LCP: Largest Contentful Paint
Meet hoe snel de belangrijkste content zichtbaar wordt. Een goede LCP is 2,5 seconden of sneller.

INP: Interaction to Next Paint
Meet hoe snel de pagina reageert op interacties. Een goede INP is 200 milliseconden of sneller.

CLS: Cumulative Layout Shift
Meet hoeveel de layout onverwacht verschuift. Een goede CLS is 0,1 of lager.

Belangrijk:

de beoordeling kijkt niet naar één perfecte test.

Core Web Vitals worden beoordeeld op het 75e percentiel van echte gebruikerservaringen, apart voor mobiel en desktop.

Dat betekent in gewone taal:

minstens 75% van de gemeten bezoeken moet goed genoeg presteren.

Niet alleen jouw snelle laptop op kantoor.
Niet alleen één test in een tool.
Maar echte gebruikers, met verschillende apparaten, verbindingen en omstandigheden.

Daarom kunnen Core Web Vitals soms confronterend zijn.

Een website kan intern snel voelen, maar voor echte mobiele gebruikers toch traag zijn.

🚀 Pagespeed versus Core Web Vitals

Pagespeed is de brede term.

Core Web Vitals zijn specifieker.

Pagespeed gaat over hoe snel een website of pagina voelt. Daaronder vallen veel signalen, zoals serverrespons, bestandsgrootte, afbeeldingen, caching, scripts, fonts en rendergedrag.

Core Web Vitals maken een deel daarvan meetbaar.

Ze beantwoorden drie concrete vragen:

• wanneer ziet de gebruiker de belangrijkste content?
• hoe snel reageert de pagina op interactie?
• blijft de layout stabiel?

Een pagina kan dus een redelijk snelle eerste indruk geven, maar alsnog een slechte Core Web Vital hebben.

Bijvoorbeeld:

De pagina toont snel tekst, maar de grote hero-afbeelding komt veel later. Dan kan LCP slecht zijn.

Of de pagina ziet er snel geladen uit, maar klikken op menu, filters of knoppen voelt traag. Dan kan INP slecht zijn.

Of de pagina lijkt te laden, maar banners, advertenties of fonts duwen content telkens opzij. Dan kan CLS slecht zijn.

Pagespeed is dus het grotere onderwerp.

Core Web Vitals zijn de belangrijkste meetpunten binnen dat onderwerp.

📊 LCP, INP en CLS uitgelegd

Core Web Vitals worden pas nuttig als je begrijpt wat elke metric betekent.

Niet alleen de naam.

Maar ook wat je moet onderzoeken wanneer een metric slecht scoort.

🖼️ LCP: Largest Contentful Paint

LCP staat voor Largest Contentful Paint.

Deze metric meet hoe lang het duurt voordat het grootste zichtbare contentelement in beeld is geladen.

Vaak is dat:

• een hero-afbeelding
• een grote kop
• een banner
• een productafbeelding
• een groot tekstblok
• een video-preview
• een belangrijk contentblok boven de vouw

LCP-score beoordelen

Goed: 2,5 seconden of sneller
Verbetering nodig: meer dan 2,5 tot en met 4 seconden
Slecht: meer dan 4 seconden

LCP gaat dus niet over wanneer alles op de pagina klaar is.

Het gaat om het moment waarop de belangrijkste content waarschijnlijk zichtbaar is voor de gebruiker.

Dat maakt LCP heel relevant voor SEO-landingspagina’s, categoriepagina’s, productpagina’s en kennisbankartikelen. Juist op die pagina’s wil je dat de gebruiker snel ziet: ik zit goed.

Veelvoorkomende oorzaken van slechte LCP zijn:

• te grote hero-afbeeldingen
• afbeeldingen in verkeerde formaten
• trage serverrespons
• geen of slechte caching
• render-blocking CSS
• render-blocking JavaScript
• zware fonts
• te late lazy loading van belangrijke afbeeldingen
• veel third-party scripts bovenin de pagina
• zware pagebuilders of thema’s

Een klassieke fout is een grote afbeelding bovenaan de pagina die pas laat wordt geladen.

Vooral als die afbeelding ook nog eens te zwaar is.

Dan voelt de pagina traag, zelfs als de rest technisch best netjes is.

🖱️ INP: Interaction to Next Paint

INP staat voor Interaction to Next Paint.

Deze metric meet hoe snel een pagina reageert op gebruikersinteracties.

Denk aan:

• klikken
• tikken
• typen
• openen van menu’s
• gebruiken van filters
• klikken op tabs
• interactie met formulieren
• knoppen in een checkout
• accordion-elementen
• interactieve kaarten of widgets

INP-score beoordelen

Goed: 200 milliseconden of sneller
Verbetering nodig: meer dan 200 tot en met 500 milliseconden
Slecht: meer dan 500 milliseconden

INP kijkt dus niet alleen naar de eerste interactie.

Dat was vroeger meer het idee achter FID, First Input Delay. INP is breder, omdat het interacties over de hele levensduur van de pagina meeneemt.

Dat maakt INP vaak lastiger op te lossen dan LCP.

Bij LCP kun je vaak vrij concreet kijken naar het grootste element boven de vouw. Bij INP moet je vaker onderzoeken wat JavaScript doet, welke scripts de main thread blokkeren en welke interacties echt traag voelen.

Veelvoorkomende oorzaken van slechte INP zijn:

• te veel JavaScript
• zware scripts van derden
• tag managers vol pixels en marketingtools
• zware event handlers
• filters of zoekfuncties die veel werk tegelijk doen
• complexe front-end frameworks
• sliders, pop-ups of interactieve componenten
• pagebuilders die veel scripts laden
• lange taken op de main thread

Een slechte INP merk je vaak pas als je iets doet.

De pagina lijkt geladen.

Maar zodra je klikt, gebeurt er net te laat iets.

Dat voelt stroperig.

📐 CLS: Cumulative Layout Shift

CLS staat voor Cumulative Layout Shift.

Deze metric meet hoeveel de layout onverwacht verschuift.

Bijvoorbeeld:

Je wilt op een knop klikken.

Net op dat moment laadt er bovenin een banner.

De knop schuift naar beneden.

Je klikt mis.

Dat is CLS in de praktijk.

CLS-score beoordelen

Goed: 0,1 of lager
Verbetering nodig: meer dan 0,1 tot en met 0,25
Slecht: meer dan 0,25

CLS heeft geen tijdseenheid.

Het is geen seconde of milliseconde, maar een score voor visuele stabiliteit.

Veelvoorkomende oorzaken van slechte CLS zijn:

• afbeeldingen zonder vaste breedte en hoogte
• video’s of embeds zonder gereserveerde ruimte
• advertenties die later inspringen
• cookie banners die content verschuiven
• fonts die verspringen tijdens het laden
• dynamische content boven bestaande content
• notificatiebalken die bovenin worden toegevoegd
• carousels of sliders met wisselende hoogtes

CLS is vaak relatief goed te verbeteren als je de oorzaak vindt.

Reserveer ruimte voor afbeeldingen, embeds en banners. Voorkom dat nieuwe elementen boven bestaande content worden ingeladen. En zorg dat fonts geen grote visuele sprongen veroorzaken.

🧪 Field data en lab data: waarom scores kunnen verschillen

Een van de grootste verwarringen bij Core Web Vitals is het verschil tussen field data en lab data.

Je ziet in PageSpeed Insights vaak beide.

En ze kunnen elkaar tegenspreken.

Dat is normaal.

Field data

Field data is data van echte gebruikers.

Dus mensen die je website echt hebben bezocht, op echte apparaten, met echte verbindingen. In PageSpeed Insights komt deze data uit de Chrome User Experience Report-dataset, ook wel CrUX.

Field data is belangrijk omdat het laat zien hoe je website in de praktijk presteert.

Niet alleen in een testomgeving.

Deze data kijkt naar een periode van de afgelopen 28 dagen.

Daardoor reageren verbeteringen niet altijd direct.

Pas je vandaag iets aan?

Dan kan het even duren voordat field data duidelijk verbetert.

Lab data

Lab data komt uit een gecontroleerde test.

PageSpeed Insights gebruikt hiervoor Lighthouse.

Een tool test de pagina onder gesimuleerde omstandigheden en geeft daarna metingen, audits en verbeterpunten.

Lab data is handig om problemen te debuggen.

Je ziet bijvoorbeeld:

• welk element waarschijnlijk de LCP veroorzaakt
• welke scripts veel blokkeren
• welke afbeeldingen te groot zijn
• welke resources render-blocking zijn
• waar ongebruikte CSS of JavaScript zit
• welke optimalisaties mogelijk zijn

Maar lab data is geen volledige weergave van echte gebruikerservaring.

Een echte gebruiker kan op een oudere telefoon zitten.
Of op mobiel internet.
Of met een volle browser.
Of in een ander land.
Of met interacties die Lighthouse niet automatisch uitvoert.

Daarom gebruik je beide soorten data anders.

Field data gebruik je om echte gebruikerservaring te beoordelen.
Lab data gebruik je om oorzaken te vinden en verbeteringen te testen.

🔍 Core Web Vitals analyseren met PageSpeed Insights

PageSpeed Insights is vaak de eerste tool die mensen gebruiken voor Core Web Vitals.

Dat is logisch.

Je vult een URL in op:

https://pagespeed.web.dev/

En je krijgt direct een rapport.

Maar je moet het rapport wel goed lezen.

Anders ga je al snel sturen op het verkeerde getal.

Stap 1: test een representatieve URL

Begin niet alleen met de homepage.

De homepage is belangrijk, maar vaak niet representatief voor de hele website.

Test juist verschillende paginatypes.

Bijvoorbeeld:

• homepage
• categoriepagina
• productpagina
• dienstenpagina
• blogartikel
• kennisbankartikel
• belangrijke landingspagina
• formulierpagina
• checkoutpagina
• hubpagina

Waarom?

Omdat Core Web Vitals vaak templateproblemen zijn.

Een webshop kan een snelle homepage hebben, maar trage productpagina’s. Een kennisbank kan prima artikelen hebben, maar een zware modulepagina. Een dienstensite kan een nette homepage hebben, maar trage landingspagina’s door zware visuals en scripts.

Meet dus per template.

Niet alleen per losse URL.

Stap 2: kijk eerst naar de Core Web Vitals Assessment

Bovenin PageSpeed Insights zie je of de URL of origin slaagt voor de Core Web Vitals-beoordeling.

Dat is belangrijker dan meteen naar de Lighthouse-score springen.

De Core Web Vitals Assessment kijkt naar echte gebruikersdata, als er genoeg data beschikbaar is.

Voor een voldoende beoordeling moeten de belangrijkste metrics goed zijn:

• LCP goed
• INP goed
• CLS goed

En dat op het 75e percentiel.

Als één van de drie onvoldoende is, haalt de pagina of origin de Core Web Vitals Assessment meestal niet.

Dat maakt de analyse meteen concreet.

Je hoeft niet te denken:

“PageSpeed is slecht.”

Je kunt zeggen:

“Deze template faalt vooral op LCP.”

Of:

“Deze origin scoort goed op LCP en CLS, maar niet op INP.”

Dat is veel bruikbaarder.

Stap 3: let op URL-data versus origin-data

PageSpeed Insights kan data tonen op twee niveaus:

• URL-niveau
• origin-niveau

URL-niveau gaat over de specifieke pagina die je test.

Origin-niveau gaat over het hele domein of subdomein.

Bijvoorbeeld:

URL:

https://www.example.com/schoenen/

Origin:

https://www.example.com

Soms heeft een specifieke URL niet genoeg data.

Dan toont PageSpeed Insights vooral origin-data.

Dat is niet fout, maar je moet het wel goed interpreteren.

Als je een kleine pagina test met weinig verkeer, kan de tool dus geen betrouwbare URL-data hebben. Dan zegt het rapport meer over de website als geheel dan over die ene pagina.

Andersom kan een origin gemiddeld goed scoren, terwijl een belangrijk template slecht presteert.

Daarom moet je altijd kijken:

gaat deze data over deze URL?

Of over het hele domein?

Stap 4: bekijk mobiel en desktop apart

Core Web Vitals worden apart beoordeeld voor mobiel en desktop.

Dat verschil is belangrijk.

Mobiel scoort vaak slechter.

Niet omdat mobiel minder belangrijk is.

Juist omdat mobiele gebruikers vaker tragere apparaten en verbindingen hebben.

Een pagina kan op desktop groen zijn en op mobiel rood.

Dan is het niet genoeg om te zeggen:

“De pagina is snel.”

Je moet specifieker zijn:

“Desktop is goed, maar mobiel heeft een LCP-probleem.”

Of:

“Mobiel en desktop zijn allebei goed op CLS, maar mobiel heeft een INP-probleem.”

Voor SEO en gebruikerservaring is mobiel vaak extra belangrijk.

Dus begin bij mobiel wanneer je moet prioriteren.

Stap 5: lees de distributiebalken

PageSpeed Insights toont niet alleen één waarde.

Je ziet ook verdeling in:

• goed
• verbetering nodig
• slecht

Die verdeling is nuttig.

Stel dat LCP op het 75e percentiel 2,7 seconden is.

Dan zit je net boven de grens.

Dat is een ander probleem dan een LCP van 6,8 seconden.

Bij 2,7 seconden heb je misschien gerichte optimalisaties nodig. Bij 6,8 seconden is er waarschijnlijk iets structureel mis.

De distributie laat ook zien hoeveel gebruikers echt slechte ervaring hebben.

Dat helpt bij prioriteren.

Niet alleen:

wat is de score?

Maar:

hoe groot is het probleem?

Stap 6: gebruik lab data om oorzaken te vinden

Na de field data kijk je naar de lab data.

Daar zie je de Lighthouse-analyse.

Let op:

de Performance-score is handig, maar niet heilig.

Een score van 90 of hoger is groen.
Een score tussen 50 en 89 vraagt verbetering.
Een score onder 50 is slecht.

Maar die score is een samenvatting.

De echte waarde zit in de onderliggende metrics en aanbevelingen.

Kijk vooral naar:

• Largest Contentful Paint
• Total Blocking Time
• Cumulative Layout Shift
• Speed Index
• First Contentful Paint
• render-blocking resources
• ongebruikte CSS
• ongebruikte JavaScript
• afbeeldingoptimalisaties
• server response time
• font loading
• third-party scripts

Belangrijk bij INP:

Lighthouse kan INP niet altijd volledig meten zoals echte gebruikersdata dat doet, omdat INP interacties van echte gebruikers nodig heeft. In labrapporten kijk je daarom vaak naar Total Blocking Time als proxy. Als TBT hoog is, kan dat een aanwijzing zijn dat JavaScript ook in het echte gebruik interactieproblemen veroorzaakt.

Stap 7: koppel elk probleem aan de juiste metric

Niet elk advies in PageSpeed Insights is even belangrijk.

Koppel verbeterpunten aan de metric die slecht scoort.

Is LCP slecht?

Kijk dan eerst naar:

• LCP-element
• hero-afbeelding
• server response time
• render-blocking CSS
• critical CSS
• image preload
• lazy loading van boven-de-vouw-afbeeldingen
• caching
• fonts

Is INP slecht?

Kijk dan eerst naar:

• JavaScript
• long tasks
• Total Blocking Time
• third-party scripts
• tag manager
• zware interacties
• filters
• formulieren
• menu’s
• sliders
• front-end framework

Is CLS slecht?

Kijk dan eerst naar:

• afbeeldingen zonder afmetingen
• embeds zonder vaste ruimte
• advertenties
• banners
• cookiebalken
• fonts
• dynamische content boven bestaande content

Zo voorkom je dat je willekeurig optimaliseert.

Een afbeelding comprimeren kan nuttig zijn.

Maar als je grootste probleem INP is door zware JavaScript, los je daar de kern niet mee op.

🧭 Andere manieren om Core Web Vitals en pagespeed te meten

PageSpeed Insights is sterk voor losse URL’s.

Maar voor een goede technische analyse wil je vaak breder kijken.

Zeker bij grotere websites, webshops, platforms of sites met meerdere templates.

Google Search Console

In Google Search Console vind je het Core Web Vitals-rapport.

Dat rapport is handig om patronen te zien.

Bijvoorbeeld:

• welke URL-groepen scoren slecht?
• gaat het om mobiel of desktop?
• welke metric veroorzaakt het probleem?
• raakt het één template of meerdere templates?
• verbetert de situatie na technische aanpassingen?

Search Console is minder geschikt om één specifieke oorzaak diep te debuggen.

Maar het is sterk om te zien waar de problemen op schaal zitten.

Lighthouse

Lighthouse kun je gebruiken voor labtests.

Bijvoorbeeld via Chrome DevTools of via PageSpeed Insights.

Lighthouse helpt vooral bij debugging.

Je ziet technische signalen, audits en opportunities. Denk aan render-blocking resources, ongebruikte CSS, ongebruikte JavaScript, afbeeldingoptimalisaties en performanceproblemen in een gecontroleerde test.

Gebruik Lighthouse dus vooral om te onderzoeken:

waar komt het probleem waarschijnlijk vandaan?

Niet als enige waarheid over echte gebruikerservaring.

Chrome DevTools

Chrome DevTools is handig voor diepere technische analyse.

Vooral wanneer je wilt zien wat er tijdens het laden of interactie gebeurt.

Denk aan:

• network requests
• laadtijd van bestanden
• JavaScript-taken
• main thread blocking
• layout shifts
• renderinggedrag
• performance recordings

Dit is vooral nuttig voor developers of technische SEO-specialisten die samen met developers willen onderzoeken waar de vertraging precies ontstaat.

CrUX

CrUX staat voor Chrome User Experience Report.

Dat is echte gebruikersdata van Chrome-gebruikers, geaggregeerd en geanonimiseerd.

PageSpeed Insights gebruikt CrUX-data wanneer er genoeg data beschikbaar is. Je kunt CrUX ook op andere manieren gebruiken, bijvoorbeeld via dashboards, BigQuery of API’s, vooral als je meer structureel met performance-data werkt.

CrUX is waardevol omdat het laat zien hoe echte gebruikers je site ervaren.

Niet hoe één testmachine je pagina ervaart.

Screaming Frog met PageSpeed Insights API

Voor audits op schaal is Screaming Frog in combinatie met de PageSpeed Insights API heel sterk.

Je crawlt dan meerdere URL’s en haalt performance- en Core Web Vitals-data mee in je crawl. Daardoor kun je niet alleen één URL bekijken, maar patronen vinden over veel pagina’s tegelijk.

Dat is vooral handig voor:

• webshops
• grote kennisbanken
• websites met veel templates
• migratiecontroles
• technische SEO-audits
• vergelijking tussen paginatypes
• prioriteren van performanceproblemen

Je kunt bijvoorbeeld zien of productpagina’s structureel slechter scoren dan categoriepagina’s.

Of dat alle blogartikelen dezelfde CLS-oorzaak hebben.

Of dat een specifiek template veel render-blocking resources heeft.

Dat maakt performance-analyse veel praktischer.

Niet één losse PageSpeed-test.

Maar een beeld op schaal.

Real User Monitoring

Voor grotere of belangrijkere websites kan Real User Monitoring interessant zijn.

Daarmee meet je zelf performance bij echte gebruikers.

Je krijgt dan meer detail dan alleen de standaard CrUX-data. Bijvoorbeeld per template, device, land, browser, interactie of gebruikersgroep.

RUM is niet altijd nodig.

Maar voor sites met veel verkeer, complexe interacties of grote commerciële waarde kan het heel nuttig zijn.

Dan zie je niet alleen dát er een probleem is.

Je ziet ook waar, bij wie en in welke situatie.

🧱 Waardoor slechte Core Web Vitals vaak ontstaan

Slechte Core Web Vitals ontstaan meestal niet door één klein ding.

Vaak is het een combinatie.

Een zwaar template.
Een grote afbeelding.
Een trage server.
Een pagebuilder.
Een stapel scripts.
Een cookie banner.
Een tag manager vol pixels.

Toch kun je oorzaken vaak per metric groeperen.

LCP-problemen zitten vaak bovenaan de pagina

LCP gaat meestal mis in het eerste zichtbare deel van de pagina.

Denk aan:

• hero-afbeeldingen
• sliders
• grote banners
• zware video’s
• fonts
• server response time
• render-blocking CSS
• JavaScript die rendering vertraagt

Een veelvoorkomende fout is een grote afbeelding boven de vouw die niet goed is geoptimaliseerd. Bijvoorbeeld een afbeelding van 3000 pixels breed die op mobiel veel kleiner wordt getoond, maar wel volledig wordt geladen.

Ook lazy loading kan fout gaan.

Lazy loading is nuttig voor afbeeldingen lager op de pagina, maar je wilt het belangrijkste boven-de-vouw-beeld meestal niet te laat laden. Als het LCP-element zelf lazy loaded is, kan dat je LCP juist verslechteren.

INP-problemen zitten vaak in JavaScript

INP gaat vaak mis door te veel werk op de main thread.

In gewone taal:

de browser is druk.

Daardoor reageert de pagina laat op een klik, tik of toetsaanslag.

Veelvoorkomende oorzaken:

• zware JavaScript-bundles
• ongebruikte JavaScript
• veel third-party scripts
• trackingpixels
• chatwidgets
• A/B-testtools
• complexe filters
• zware menu’s
• sliders
• formulieren met veel validatie
• pagebuilders
• front-end frameworks zonder optimalisatie

Vooral webshops en platforms kunnen hier last van hebben.

Filters, sorteringen, winkelwagens, accountmenu’s en trackingtools maken de pagina interactief, maar ook zwaarder.

CLS-problemen zitten vaak in ontbrekende ruimte

CLS gaat vaak mis doordat de browser niet weet hoeveel ruimte iets nodig heeft.

Een afbeelding laadt later in.
Een advertentie verschijnt boven content.
Een font wordt vervangen.
Een banner duwt de pagina omlaag.

Veelvoorkomende oorzaken:

• afbeeldingen zonder width en height
• video’s zonder vaste verhouding
• embeds zonder gereserveerde ruimte
• advertenties zonder placeholder
• cookie banners die content verplaatsen
• dynamische notificatiebalken
• fonts met grote verschillen tussen fallback en eindfont
• content die later boven bestaande content wordt ingevoegd

CLS voelt voor gebruikers snel irritant.

Niet omdat de pagina traag is.

Maar omdat hij onvoorspelbaar is.

🛠️ Core Web Vitals verbeteren: waar begin je?

Core Web Vitals verbeteren begint niet met lukraak optimaliseren.

Begin met diagnose.

Anders ben je snel bezig met dingen die weinig effect hebben.

1. Bepaal welke templates slecht scoren

Kijk eerst naar paginatypes.

Bijvoorbeeld:

• productpagina’s
• categoriepagina’s
• blogartikelen
• landingspagina’s
• checkoutpagina’s
• kennisbankartikelen

Als één productpagina slecht scoort, is dat vervelend.

Maar als alle productpagina’s slecht scoren, is dat een templateprobleem.

En templateproblemen hebben prioriteit.

Want één oplossing kan dan honderden of duizenden URL’s verbeteren.

2. Bepaal welke metric het probleem is

Zeg niet alleen:

“de site is traag.”

Maak het concreet.

Is het LCP?
Is het INP?
Is het CLS?

Elke metric vraagt om andere oplossingen.

Bij LCP kijk je vaak naar server, rendering en belangrijkste content.

Bij INP kijk je vaak naar JavaScript en interacties.

Bij CLS kijk je vaak naar layout, afmetingen en dynamische elementen.

3. Zoek de grootste oorzaak

PageSpeed Insights geeft vaak veel aanbevelingen.

Maar niet elke aanbeveling is even belangrijk.

Kijk naar de grootste impact.

Voorbeelden:

Slechte LCP op productpagina’s?
Begin bij productafbeeldingen, hero-blokken, caching en serverrespons.

Slechte INP op de hele site?
Begin bij JavaScript, third-party scripts en tag manager.

Slechte CLS op blogartikelen?
Begin bij afbeeldingen, embeds, banners en fonts.

4. Verbeter eerst wat veel URL’s raakt

Optimaliseer niet alleen één URL omdat die toevallig in PageSpeed Insights staat.

Kijk wat structureel effect heeft.

Bijvoorbeeld:

• afbeeldingsformaten in het CMS
• lazy loading-regels
• cachingconfiguratie
• font loading
• JavaScript-bundles
• tag manager-opruiming
• template-aanpassingen
• vaste afmetingen voor media
• critical CSS

Een templateverbetering is vaak waardevoller dan één losse pagina sneller maken.

5. Test opnieuw, maar verwacht field data niet direct

Na een aanpassing kun je lab data direct opnieuw testen.

Field data loopt achter.

Omdat echte gebruikersdata over een periode wordt verzameld, zie je verbeteringen vaak pas later terug in PageSpeed Insights en Search Console.

Dat betekent niet dat de fix niet werkt.

Maar je moet onderscheid maken tussen:

is de technische oorzaak opgelost?

en:

is dit al zichtbaar in echte gebruikersdata?

Dat tweede kost tijd.

📉 Waarom een perfecte PageSpeed-score niet altijd het doel is

Veel mensen willen 100/100 in PageSpeed Insights.

Dat is begrijpelijk.

Een groen rapport voelt goed.

Maar een perfecte score is niet altijd het beste doel.

Soms kost de laatste stap van 94 naar 100 veel tijd en levert die weinig extra gebruikerswaarde op. Dan kun je beter werken aan content, conversie, interne links, technische indexatie of een template dat veel slechter scoort.

Het doel is niet:

een perfecte score.

Het doel is:

een snelle, stabiele en prettig bruikbare pagina.

Dat betekent:

• belangrijke content snel zichtbaar
• interacties snel genoeg
• layout stabiel
• geen structurele frustratie voor gebruikers
• geen zware technische rommel
• geen templates die consistent slecht presteren

Een score helpt je meten.

Maar de score is niet de gebruiker.

Kijk daarom altijd naar de combinatie van data, ervaring en impact.

🧰 Hoe houd je pagespeed goed op lange termijn?

Pagespeed is geen eenmalige taak.

Een website wordt vaak vanzelf zwaarder.

Niet omdat iemand dat bewust wil.

Maar omdat er steeds iets bijkomt.

Een nieuwe trackingpixel.
Een extra chatwidget.
Een zwaardere hero-afbeelding.
Een A/B-testtool.
Een nieuw font.
Een plugin.
Een embed.
Een campagnebanner.
Een extra script via tag manager.

Alles lijkt klein.

Tot het samen groot wordt.

Daarom moet performance onderdeel zijn van je proces.

Bijvoorbeeld:

• check nieuwe templates vóór livegang
• comprimeer afbeeldingen standaard
• gebruik moderne afbeeldingsformaten
• bewaak scripts in Google Tag Manager
• verwijder ongebruikte plugins en tags
• test belangrijke pagina’s periodiek
• monitor Core Web Vitals in Search Console
• controleer performance na redesigns en migraties
• maak afspraken met developers over performancebudgetten
• test niet alleen homepage, maar ook belangrijke templates

Voor grotere websites kan Real User Monitoring nuttig zijn.

Dan meet je Core Web Vitals zelf bij echte gebruikers en krijg je meer detail dan alleen de CrUX-data in PageSpeed Insights.

Dat is vooral handig bij websites met veel verkeer, veel templates of complexe interacties.

🧠 Hoe je Core Web Vitals slim prioriteert

Niet elk performanceprobleem heeft dezelfde prioriteit.

Kijk naar drie dingen:

impact, schaal en haalbaarheid.

Impact:

hoe groot is het probleem voor gebruikers?

Schaal:

hoeveel URL’s of templates worden geraakt?

Haalbaarheid:

hoe snel en realistisch is de oplossing?

Een slechte LCP op alle productpagina’s is vaak belangrijker dan een kleine CLS-afwijking op één oud blogartikel.

Een zware tag manager op de hele site kan belangrijker zijn dan één te grote afbeelding.

En een fout in een template is vaak belangrijker dan een losse pagina die toevallig slecht scoort.

Een praktische prioriteit kan zijn:

1. los problemen op belangrijke templates op
2. pak slechte mobiele scores eerst aan
3. focus op de metric die de Core Web Vitals Assessment laat falen
4. verbeter structurele oorzaken
5. voorkom dat nieuwe releases de scores weer verslechteren

Core Web Vitals zijn dus niet alleen een technisch rapport.

Ze zijn een manier om performancebeslissingen beter te maken.

👉 Volgende stap

Nu je weet hoe prestaties en gebruikerservaring technisch gemeten worden, gaan we door naar een specifiek onderdeel dat vaak grote invloed heeft op laadtijd:

Technische SEO voor afbeeldingen.

❓ Vragen beantwoord in dit artikel