Performance

Core Web Vitals check voor snellere en stabielere pagina's

Core Web Vitals zijn de meetbare maten waarmee Google de gebruikerservaring van je pagina beoordeelt: hoe snel de hoofdinhoud verschijnt, hoe stabiel de layout blijft en hoe vlot de pagina reageert op input. Ze beïnvloeden zowel je positie in de zoekresultaten als hoeveel bezoekers blijven en converteren. CheckBorg meet deze waarden, vertaalt ze naar concrete oorzaken op je pagina en geeft aan welke knelpunten je het eerst zou aanpakken.

Controlepunten

LCP (Largest Contentful Paint): tijd tot de grootste zichtbare inhoud geladen is
CLS (Cumulative Layout Shift): hoeveel de layout verspringt tijdens het laden
INP (Interaction to Next Paint): reactiesnelheid op klikken, tikken en typen
Render-blocking CSS en JavaScript in de <head>
Afbeeldingen: formaat, compressie, moderne formaten (WebP/AVIF) en lazy loading
Caching-headers en gebruik van een CDN
Compressie van tekstbestanden (gzip/Brotli)
Ongebruikte CSS/JS en de totale hoeveelheid meegestuurde code
Webfonts: laadstrategie en font-display

Waarom dit belangrijk is

Snelheid is geen luxe maar een directe factor in vertrouwen en omzet. Bezoekers haken af bij trage pagina's, en elke seconde extra laadtijd kost meetbaar conversie, zeker op mobiel met een trager netwerk. Google gebruikt Core Web Vitals als rankingsignaal: bij gelijke relevantie kan een snellere, stabielere pagina hoger eindigen, en een pagina die structureel slecht scoort heeft een nadeel. Layout-verspringingen (CLS) zijn bovendien een bron van frustratie en foutklikken, bijvoorbeeld wanneer een knop verschuift net op het moment dat iemand erop tikt. Een trage reactie op input (INP) laat je site kapot aanvoelen, ook al is alles technisch in orde. Goede scores betekenen dus niet alleen betere vindbaarheid, maar vooral een site die professioneel en betrouwbaar overkomt.

Veelvoorkomende bevindingen

LCP te hoog doordat een grote, ongecomprimeerde hero-afbeelding of een traag serverantwoord de hoofdinhoud vertraagt
CLS doordat afbeeldingen, advertenties of embeds geen vaste hoogte/breedte hebben en de tekst eronder wegduwen
Render-blocking JavaScript en CSS die het tonen van de pagina onnodig uitstellen
Afbeeldingen die veel groter worden geladen dan ze getoond worden, of nog in JPEG/PNG in plaats van WebP/AVIF
Ontbrekende of te korte caching-headers, waardoor terugkerende bezoekers alles opnieuw moeten downloaden
Geen gzip/Brotli-compressie op HTML, CSS en JavaScript
Zware externe scripts (trackers, chatwidgets, sliders) die de reactiesnelheid en INP verslechteren

Core Web Vitals bestaan uit drie meetwaarden. LCP (Largest Contentful Paint) meet hoe lang het duurt voordat het grootste zichtbare element, meestal een hero-afbeelding of een groot tekstblok, geladen is; als richtlijn geldt 2,5 seconde of sneller als goed. CLS (Cumulative Layout Shift) meet visuele stabiliteit: hoeveel de inhoud verspringt terwijl de pagina laadt, met 0,1 of lager als doel. INP (Interaction to Next Paint) verving in maart 2024 de oudere FID-meting en kijkt hoe snel de pagina zichtbaar reageert op interacties zoals klikken en typen, waarbij 200 milliseconde of sneller goed is.

Belangrijk om te weten: er zijn twee soorten metingen. Veldgegevens (field data) komen van echte bezoekers via het Chrome User Experience Report en zijn wat Google daadwerkelijk voor ranking gebruikt. Labgegevens (lab data) komen uit een gesimuleerde test, zoals Lighthouse, op een vast moment en netwerk. Een labtest is reproduceerbaar en handig om oorzaken op te sporen, maar kan afwijken van wat je echte bezoekers ervaren. CheckBorg signaleert de knelpunten in de opbouw van je pagina; de definitieve scores die Google gebruikt komen uit het gedrag van je werkelijke bezoekers over een periode.

Veel snelheidsproblemen ontstaan in de manier waarop de pagina is opgebouwd. Render-blocking betekent dat de browser eerst bepaalde CSS- of JavaScript-bestanden volledig moet downloaden en verwerken voordat er iets op het scherm komt. Te veel of te zware scripts, vaak van externe partijen zoals trackers, chatwidgets en sliders, leggen beslag op de hoofdthread van de browser en zorgen voor een trage INP. Afbeeldingen zijn een andere grote bron: een foto die als 3000 pixels breed bestand wordt geladen maar op 600 pixels getoond wordt, verspilt bandbreedte en vertraagt de LCP.

Layout-stabiliteit (CLS) gaat bijna altijd mis door elementen zonder gereserveerde ruimte. Een afbeelding zonder opgegeven breedte en hoogte, een advertentie of embed die later inlaadt, of een webfont dat tekst herpositioneert: allemaal duwen ze de inhoud die er al stond opzij. De oplossing zit in het vooraf vastleggen van afmetingen, zodat de browser de ruimte al kent voordat het element binnen is. Aan de serverkant tellen caching en compressie zwaar mee: met goede caching-headers en een CDN downloaden terugkerende bezoekers niet telkens alles opnieuw, en met Brotli- of gzip-compressie gaan tekstbestanden vaak een factor drie tot vier kleiner over de lijn.

Wat goed is, herken je aan een combinatie: een snel serverantwoord, een hoofdinhoud die vrijwel meteen verschijnt, geen zichtbaar verspringen, en knoppen die direct reageren. Geen enkele losse maatregel lost alles op; snelheid is het resultaat van veel kleine, juiste keuzes in hosting, opmaak en het beheer van afbeeldingen en scripts. CheckBorg brengt in kaart welke van die keuzes op jouw pagina nog niet goed staan en welke de meeste winst opleveren.

Hoe pak je het aan

1

Optimaliseer je afbeeldingen

Lever afbeeldingen aan op de werkelijke weergavegrootte, comprimeer ze en gebruik moderne formaten zoals WebP of AVIF. Geef altijd een breedte en hoogte mee zodat er geen layout-verspringing ontstaat. Dit gebeurt in je CMS, mediabeheer of build-proces, niet in CheckBorg zelf.

2

Verminder render-blocking code

Laad niet-kritieke CSS en JavaScript uitgesteld (defer/async) en verwijder ongebruikte code. In WordPress en vergelijkbare systemen kan een goed ingestelde caching- of optimalisatieplugin dit grotendeels regelen; in maatwerk gebeurt het in de build-configuratie.

3

Zet caching en compressie aan

Configureer caching-headers en Brotli- of gzip-compressie op je server of via een CDN. Dit is een instelling op hosting-/serverniveau (of in een plugin), waardoor terugkerende bezoekers veel minder hoeven te downloaden.

4

Beperk en stroomlijn externe scripts

Inventariseer trackers, chatwidgets, sliders en andere externe scripts en verwijder wat je niet nodig hebt. Laad de rest zo laat mogelijk. Minder hoofdthread-werk verbetert direct je INP.

5

Reserveer ruimte voor dynamische elementen

Geef advertenties, embeds en lazy-loaded afbeeldingen een vaste afmeting of placeholder, zodat de inhoud eronder niet wegspringt. Stel webfonts in met font-display zodat tekst direct leesbaar blijft tijdens het laden.

6

Meet met echte bezoekersdata

Controleer na aanpassingen niet alleen een labtest maar ook de veldgegevens (via Search Console of het Chrome UX Report). Die geven over een periode het beeld dat Google daadwerkelijk gebruikt voor ranking.

Controleer je eigen website

Vul je domein in en ontdek welke checks aandacht nodig hebben.

We voeren alleen veilige, passieve checks uit op publiek beschikbare informatie.

Je krijgt eerst een snelle intake met score en prioriteiten. Uitgebreide rapportage en monitoring zijn later op te schalen.

Veelgestelde vragen

Wat zijn precies de drie Core Web Vitals?

LCP (Largest Contentful Paint) meet hoe snel de grootste zichtbare inhoud verschijnt, met 2,5 seconde als goede grens. CLS (Cumulative Layout Shift) meet hoeveel de layout verspringt tijdens het laden, met 0,1 als doel. INP (Interaction to Next Paint) meet hoe snel de pagina reageert op input, met 200 milliseconde als goede grens.

Lost CheckBorg mijn snelheidsproblemen automatisch op?

Nee. CheckBorg meet de waarden, spoort de oorzaken op en geeft aan wat je het eerst zou aanpakken. De daadwerkelijke fix gebeurt in je hosting, server, CMS of de code van je site. Wij maken de knelpunten zichtbaar en prioriteren ze, jij of je bouwer voert de aanpassing door.

Waarom verschilt mijn score tussen verschillende meettools?

Er zijn labgegevens en veldgegevens. Een labtest (zoals Lighthouse) draait op een vast moment, apparaat en netwerk en is reproduceerbaar. Veldgegevens komen van je echte bezoekers over een periode en zijn wat Google voor ranking gebruikt. Verschillen tussen tools en momenten zijn daardoor normaal.

Telt snelheid echt mee voor mijn Google-positie?

Ja, Core Web Vitals zijn een rankingsignaal, maar relevantie en inhoud blijven het zwaarst wegen. Bij vergelijkbare pagina's kan snelheid het verschil maken, en een structureel slechte score is een nadeel. Het grootste effect zie je doorgaans in lager afhaakgedrag en hogere conversie.

Mijn site voelt snel aan, waarom is mijn LCP dan toch hoog?

Wat jij ervaart kan afwijken van je bezoekers, die vaak op trager mobiel internet en minder snelle toestellen zitten. Bovendien zijn jouw bestanden waarschijnlijk al in je browsercache opgeslagen. LCP wordt gemeten over echte bezoekers in uiteenlopende omstandigheden, dus een eerste bezoek op mobiel kan flink trager zijn dan jouw ervaring.

Is INP hetzelfde als de oude FID-meting?

Nee, INP heeft FID in maart 2024 vervangen als Core Web Vital. FID keek alleen naar de eerste interactie, terwijl INP de reactiesnelheid over alle interacties op de pagina beoordeelt. Daardoor geeft INP een eerlijker en completer beeld van hoe vlot je site aanvoelt.