Website sneller maken: Core Web Vitals (LCP, INP, CLS) uitgelegd, met stappenplan

Je maakt een website sneller door eerst met echte bezoekersdata te meten welke van de drie Core Web Vitals niet goed scoort, en dan gericht die oorzaak aan te pakken. Meestal zijn dat te zware afbeeldingen, trage hosting zonder caching, te veel scripts van derden en een zwaar thema of pagebuilder.

De doelen zijn helder: de hoofdinhoud staat binnen 2,5 seconden op het scherm (LCP), de pagina reageert binnen 200 milliseconden op een klik of tik (INP) en er verspringt bijna niets tijdens het laden (CLS van hoogstens 0,1). Google legt die grenzen vast op web.dev (opent in een nieuw venster).

Voor een kmo in Vlaanderen of een mkb-bedrijf in Nederland gaat het niet om een mooie score, maar om bezoekers die niet afhaken op hun gsm of mobiel. In dit artikel lees je wat elke meetwaarde betekent, hoe je correct meet en welke stappen het meeste opleveren, in de juiste volgorde.

#Wat zijn Core Web Vitals? LCP, INP en CLS in gewone taal

Core Web Vitals zijn de drie snelheids- en gebruiksscores die Google gebruikt om de ervaring op een pagina te meten: laden, reageren en stabiliteit. Elke meetwaarde heeft drie zones.

Twee details maken het verschil. Ten eerste telt het 75e percentiel: minstens drie op de vier bezoeken moeten binnen de grens vallen, apart voor mobiel en desktop. Een snelle test op je eigen laptop zegt dus weinig.

Ten tweede is INP sinds 12 maart 2024 de officiële opvolger van FID (First Input Delay), zo kondigde Google aan (opent in een nieuw venster). FID keek alleen naar de eerste klik. INP kijkt naar de traagste interacties tijdens het hele bezoek, zoals een filter in je webshop of een menu dat opent. Veel oudere artikels over snelheid noemen nog FID; die raad is achterhaald.

#Telt websitesnelheid mee voor Google?

Ja, maar minder dan veel mensen denken. Google schrijft letterlijk dat Core Web Vitals worden gebruikt door de rankingsystemen (opent in een nieuw venster), en tegelijk dat Google altijd de meest relevante inhoud toont, ook als de pagina-ervaring minder goed is.

Wat dat in de praktijk betekent:

• Snelheid vervangt geen goede inhoud. Een trage pagina met het beste antwoord kan een snelle pagina met een zwak antwoord verslaan.
• Bij gelijkwaardige inhoud helpt snelheid wel. En een trage site verliest bezoekers nog voor ze iets lezen.
• Een perfecte 100 is geen doel. Google zegt zelf dat een perfecte score najagen puur voor SEO niet de beste besteding van je tijd is. Zorg dat je in de groene zone zit en investeer daarna in inhoud.

Het grootste effect zit vaak niet in Google, maar in conversie: formulieren die sneller reageren, productpagina's die meteen tonen wat je verkoopt. Wil je inschatten wat traagheid jou kost, reken het dan na met de omzetverlies-calculator. Meer over de andere rankingfactoren lees je in hoe je je website hoger in Google krijgt.

#Websitesnelheid meten: velddata versus labdata

Meet altijd eerst met velddata, dus data van echte bezoekers, en gebruik labdata daarna om de oorzaak te vinden. Dat onderscheid is de grootste bron van verwarring bij PageSpeed Insights (opent in een nieuw venster).

• Velddata (CrUX): het Chrome User Experience Report verzamelt metingen van echte Chrome-gebruikers over de afgelopen 28 dagen. Dit zijn de cijfers die Google gebruikt. Heeft een pagina te weinig bezoekers, dan valt PageSpeed Insights terug op het gemiddelde van je hele domein, of toont het geen velddata.
• Labdata (Lighthouse): één gesimuleerde test op een gemiddelde telefoon met een vertraagde mobiele verbinding. De score van 0 tot 100 bovenaan komt hieruit. Handig om problemen op te sporen, maar het is niet wat je bezoekers ervaren.

Je kan dus een Lighthouse-score van 60 hebben en toch slagen voor de Core Web Vitals, of omgekeerd. Kijk eerst naar het blok "Ontdek wat je echte gebruikers ervaren".

Zo pak je het meten praktisch aan:

1. Open het rapport Core Web Vitals in Google Search Console. Dat groepeert je trage URL's per probleem, zodat je ziet of het om één sjabloon gaat (bijvoorbeeld alle productpagina's).
2. Test per type pagina één voorbeeld: startpagina, dienstpagina, blogartikel, product- of categoriepagina, contactpagina.
3. Test altijd mobiel. Daar zit bijna altijd het probleem.
4. Noteer per pagina LCP, INP en CLS in een eenvoudig overzicht, zodat je na elke aanpassing kan vergelijken.

Onze gratis website-diagnose combineert de velddata en de Lighthouse-test voor mobiel en desktop en vertaalt de oorzaken in gewone taal. Met vergelijk met je concurrent zie je bovendien of je sneller of trager bent dan wie in Google naast je staat.

#Stappenplan: zo maak je je website sneller

Werk van grote naar kleine winst, en meet na elke stap. Deze volgorde levert bij de meeste kmo- en mkb-sites het meeste op.

1. Meet de uitgangssituatie met velddata en noteer welke meetwaarde faalt, op welk type pagina.
2. Maak afbeeldingen licht: verklein ze tot de maat waarop ze getoond worden, comprimeer ze en gebruik WebP of AVIF.
3. Laad het hoofdbeeld meteen: geen lazy loading op de grote foto bovenaan, wel op alles lager op de pagina.
4. Versnel de server: schakel paginacaching in, kies hosting dicht bij je bezoekers en kijk je Time to First Byte na.
5. Ruim scripts van derden op: chatwidgets, heatmaps, oude trackingpixels, sociale feeds. Alles wat je niet actief gebruikt, gaat eruit.
6. Verwijder ongebruikte plugins en pagebuilder-modules, en laad CSS en JavaScript alleen op pagina's die ze nodig hebben.
7. Geef elke afbeelding, video en embed een vaste maat, zodat niets verspringt.
8. Laad lettertypes slim: zo weinig mogelijk varianten, zelf gehost en vooraf geladen.
9. Test interacties: menu, filters, formulieren, winkelmandje. Zoek naar klikken die merkbaar haperen.
10. Meet opnieuw en bewaak: controleer na vier weken de velddata en test na elke grote update.

In de volgende secties lees je per meetwaarde wat er achter die stappen zit.

#LCP verbeteren: je hoofdinhoud sneller op het scherm

LCP verbeter je door het grootste element, meestal een hero-afbeelding of een grote titel, zo vroeg mogelijk te laten laden en tonen. Google splitst LCP in vier deeltijden (opent in een nieuw venster), en elk deel heeft een eigen oplossing.

Veelvoorkomende boosdoeners op kmo-sites:

• Sliders en carrousels bovenaan. Ze laden meerdere grote beelden en veel JavaScript. Eén sterke afbeelding werkt bijna altijd beter.
• Achtergrondvideo's als hero. Gebruik een licht posterbeeld en start de video pas later, of laat hem weg op mobiel.
• Foto's rechtstreeks van de camera of stockbeelden van enkele megabytes, geschaald met CSS.
• Lazy loading op het hoofdbeeld. Google zegt uitdrukkelijk: laad je LCP-beeld nooit lazy.
• Trage gedeelde hosting zonder paginacache, waardoor elke pagina opnieuw uit de database wordt opgebouwd.

#INP verbeteren: sneller reageren op klikken en tikken

INP verbeter je door de hoofdthread van de browser vrij te houden, zodat hij meteen kan reageren wanneer iemand klikt, tikt of typt. Een trage INP voelt als een knop die "even niets doet".

Volgens de INP-handleiding van Google (opent in een nieuw venster) bestaat elke interactie uit drie delen: de wachttijd voor je code start, de verwerking zelf, en de tijd tot het scherm is bijgewerkt. Lange taken van meer dan 50 milliseconden blokkeren alle drie.

Waar het op kmo- en mkb-sites meestal misloopt:

• Scripts van derden die op elke pagina meedraaien: chat, tag managers met tientallen tags, heatmaps, advertentiepixels, reviewwidgets.
• Zware pagebuilders en thema's die veel JavaScript laden voor effecten die niemand opmerkt.
• Een erg grote pagina-opbouw (DOM), bijvoorbeeld categoriepagina's met honderden producten en verborgen mega-menu's.
• Filters en zoekvelden die bij elke toetsaanslag de hele lijst opnieuw opbouwen.

Wat helpt: scripts uitstellen tot ze nodig zijn, lange taken opsplitsen, minder elementen per pagina, en elke tool van derden kritisch bekijken. Vraag je voor elke widget af of hij aantoonbaar omzet of leads oplevert.

#CLS verbeteren: niets mag meer verspringen

CLS verbeter je door vooraf ruimte te reserveren voor alles wat later laadt. Je kent het effect: je wil op een knop tikken en op het laatste moment schuift de pagina, zodat je iets anders aanraakt.

De meest voorkomende oorzaken (opent in een nieuw venster) en hun oplossing:

• Afbeeldingen en video's zonder breedte en hoogte. Geef ze width en height mee of een vaste beeldverhouding in CSS.
• Advertenties, embeds en widgets (YouTube, Google Maps, reviews) die pas later hun grootte bepalen. Reserveer een vak met vaste hoogte.
• Webfonts die groter of kleiner zijn dan het reservelettertype. Kies een reservelettertype met vergelijkbare maten en laad het webfont vooraf.
• Balken en meldingen die bovenaan invliegen, zoals een actiebalk of een melding voor gratis verzending. Toon ze als overlay of reserveer hun plek vanaf het begin.

CLS is vaak de makkelijkste winst: het zijn meestal enkele regels HTML of CSS in het sjabloon, en dan is het probleem op alle pagina's tegelijk opgelost.

#WordPress, pagebuilders en plugins: de gebruikelijke boosdoeners

WordPress kan snel zijn, maar een gemiddelde WordPress-site draagt veel ballast mee door het thema, de pagebuilder en de plugins. Het platform zelf is zelden het probleem, de opeenstapeling eromheen wel.

Controleer bij een WordPress-site:

• Hoeveel plugins zijn actief, en welke gebruik je echt?
• Laadt een formulier- of sliderplugin zijn bestanden op elke pagina, ook waar hij niet gebruikt wordt?
• Is er paginacaching (via de host of een plugin) en objectcaching voor webshops?
• Draait de server op een ondersteunde PHP-versie?
• Worden afbeeldingen bij het uploaden automatisch verkleind en omgezet naar WebP of AVIF?
• Laadt het thema lettertypes of iconensets die je niet gebruikt?

Blijft de site na al die stappen traag, dan zit de oorzaak vaak in de basis: een multifunctioneel thema of pagebuilder die alles voor iedereen wil kunnen. Dan is de vraag of blijven optimaliseren nog loont. Een eerlijke afweging vind je in WordPress of een website op maat.

#Hosting, CDN en caching voor bezoekers in België en Nederland

Hosting bepaalt je Time to First Byte, en die telt mee in elke LCP-meting. Een snelle server dicht bij je bezoekers is de basis waarop alle andere optimalisaties bouwen.

• Locatie: zijn je klanten vooral in Vlaanderen en Nederland, dan helpt een server in West-Europa. Hosting binnen de EU maakt bovendien de AVG-afweging over waar persoonsgegevens staan eenvoudiger.
• Caching: een pagina die vooraf is opgebouwd, is altijd sneller dan een pagina die bij elk bezoek opnieuw uit de database komt.
• CDN (content delivery network): een netwerk van servers dat afbeeldingen en bestanden vanaf de dichtstbijzijnde locatie levert. Handig als je ook bezoekers verder weg hebt of veel beeldmateriaal.
• HTTP/2 of HTTP/3 en compressie (Brotli of gzip) horen standaard aan te staan. Vraag het na bij je host.

Bij Brisk bouwen we websites op maat en hosten we ze op Europese servers, zonder pagebuilder of plugins die ballast meebrengen. Het principe geldt voor elk platform: hoe minder er geladen moet worden, hoe minder er kan vertragen.

#Snel blijven: onderhoud en monitoring

Een snelle site blijft niet vanzelf snel. Elke nieuwe plugin, een extra trackingpixel of een ongecomprimeerde banner op de startpagina kan de winst weer tenietdoen.

Spreek daarom een paar vaste gewoontes af:

• Maandelijks: kijk het Core Web Vitals-rapport in Search Console na.
• Na elke update of nieuwe functie: test de belangrijkste sjablonen opnieuw op mobiel.
• Bij nieuwe content: wie foto's uploadt, weet dat ze eerst verkleind moeten worden, of het systeem doet dat automatisch.
• Per kwartaal: loop alle scripts van derden na en schrap wat niemand meer gebruikt.
• Prestatiebudget: spreek af hoe zwaar een pagina maximaal mag zijn, en leg nieuwe wensen daartegen.

Wil je dat iemand dit structureel opvolgt, dan kan dat ook als onderdeel van een onderhouds- en hostingplan. Belangrijker dan wie het doet, is dat het gebeurt: snelheid is een gewoonte, geen eenmalig project.