Core Web Vitals en website snelheid: meten en verbeteren

Core Web Vitals zijn drie meetwaarden waarmee Google de gebruikservaring van een pagina uitdrukt in cijfers. Ze beantwoorden drie vragen van een bezoeker: zie ik snel iets, reageert de pagina als ik tik en blijft alles op zijn plek?

De drie heten LCP, INP en CLS. Google meet ze bij echte bezoekers die Chrome gebruiken en verzamelt die gegevens in het Chrome User Experience Report, afgekort CrUX.

Deze grenzen komen uit de documentatie van Google op web.dev en gelden in 2026 ongewijzigd. Een pagina slaagt als minstens 75 procent van de bezoeken binnen de grens voor goed valt, op mobiel en op de computer apart gemeten.

Website snelheid werkt op twee manieren door. De eerste is Google. Core Web Vitals maken deel uit van de signalen waarmee Google de ervaring op een pagina weegt. Google zegt daar eerlijk bij dat relevante inhoud zwaarder weegt.

Zie snelheid daarom als de scheidsrechter bij een gelijkspel. Twee loodgieters met even goede pagina's over lekkage: de snellere en stabielere site heeft dan een streepje voor.

De tweede manier is directer: je bezoeker. Iemand met een lekkende kraan staat met zijn telefoon in de badkamer, op mobiel internet. Laadt jouw pagina traag, dan tikt hij op terug en belt hij de volgende.

Daar komt de omzet vandaan. Een snelle site houdt meer bezoekers vast, en meer bezoekers die blijven betekent meer aanvragen, afspraken en bestellingen. Snelheid is daarmee vooral klantvriendelijkheid.

LCP staat voor Largest Contentful Paint. Het is de tijd tussen de klik op je link en het moment dat het grootste zichtbare onderdeel van de pagina op het scherm staat. Meestal is dat de grote foto bovenaan of de hoofdkop.

Voor de bezoeker is dat het moment waarop de pagina 'er is'. Google wil dat dit binnen 2,5 seconden gebeurt.

Google splitst LCP in vier stukken. Dat helpt je om de oorzaak te vinden.

1. Reactietijd van de serverDe tijd tot het eerste antwoord van je server, ook wel TTFB genoemd. Google noemt 0,8 seconden of sneller goed.
2. Wachttijd tot het laden begintDe tijd tussen dat eerste antwoord en het moment dat de browser de hoofdafbeelding gaat ophalen.
3. Laadtijd van het bestandHoe lang het downloaden van de afbeelding of het lettertype zelf duurt. Grote bestanden kosten hier seconden.
4. Vertraging bij het tonenDe tijd tussen binnen zijn en op het scherm staan. Zware scripts en stijlen houden dit tegen.

PageSpeed Insights laat deze vier stukken per pagina zien. Zo weet je of je bij de host, bij de afbeelding of bij de scripts moet zijn.

INP staat voor Interaction to Next Paint. Het meet de tijd tussen een actie van de bezoeker, zoals een tik op het menu, en het moment dat het scherm zichtbaar reageert. Google wil dat binnen 200 milliseconden.

INP verving op 12 maart 2024 de oudere meting FID. Het verschil: FID keek alleen naar de eerste actie. INP kijkt naar alle acties tijdens het hele bezoek en rapporteert ongeveer de traagste.

Een trage INP voel je meteen. Je tikt op 'In winkelwagen' en er gebeurt een halve seconde niets. Je tikt nog een keer. Nu liggen er twee producten in je wagen.

De oorzaak is bijna altijd JavaScript: scripts die de browser bezig houden op het moment dat de bezoeker iets wil doen. Denk aan chatwidgets, trackingcodes, schuifbalken met foto's en zware thema's.

CLS staat voor Cumulative Layout Shift. Het meet hoeveel de onderdelen van je pagina verspringen tijdens het laden en gebruiken. De uitkomst is een getal: hoe lager, hoe stabieler. Google wil 0,1 of lager.

Je kent het gevoel. Je wilt op een link tikken, er laadt bovenaan nog een banner in, alles schuift omlaag en je tikt op een advertentie. Dat is een layout shift.

De drie bekendste oorzaken: afbeeldingen waar de afmetingen in de code ontbreken, banners en cookiemeldingen die bovenaan worden ingevoegd en lettertypen die na het laden een andere breedte blijken te hebben.

CLS is van de drie metingen vaak het snelst op te lossen. De oplossingen staan verderop in dit hoofdstuk.

Je website snelheid testen doe je gratis met PageSpeed Insights, de meettool van Google op pagespeed.web.dev. Je hebt alleen het adres van je pagina nodig.

1. Stap 1: plak het adresBegin met je homepage en klik op 'Analyseren'. De test duurt ongeveer een halve minuut.
2. Stap 2: kijk eerst bovenaanHet blok 'Ontdek wat je echte gebruikers ervaren' toont LCP, INP en CLS van echte bezoekers, met de uitslag geslaagd of gezakt.
3. Stap 3: kies mobielHet tabblad Mobiel is het belangrijkst. De meeste bezoekers komen met een telefoon en Google beoordeelt je mobiele versie.
4. Stap 4: lees de scoreLager op de pagina staat de prestatiescore van 0 tot 100. Vanaf 90 is groen, 50 tot 89 oranje en daaronder rood.
5. Stap 5: open de adviezenOnder de score staan de verbeterpunten, gesorteerd op geschatte winst. Klik ze open om te zien welke bestanden het betreft.
6. Stap 6: test meer pagina'sHerhaal de test voor je belangrijkste dienstpagina, een productpagina en je contactpagina. Elk type pagina heeft eigen knelpunten.

Noteer de uitkomsten in een eenvoudige tabel met datum. Zo zie je na elke verbetering wat het heeft opgeleverd.

PageSpeed Insights toont twee soorten cijfers door elkaar. Wie het verschil kent, voorkomt veel verwarring.

De veldgegevens zijn je rapportcijfer. De labscore is je oefentoets. Een oefentoets van 65 bij geslaagde veldgegevens is prima. Andersom vraagt om actie.

Kleine sites hebben vaak te weinig Chrome-bezoekers voor veldgegevens. PageSpeed Insights toont dan alleen de labtest. Werk in dat geval met de labcijfers en mik op een mobiele score van 90 of hoger.

Verandert de labscore per test een paar punten? Dat is normaal. Draai de test drie keer en neem de middelste uitkomst.

PageSpeed Insights test één pagina tegelijk. Google Search Console laat je hele site in één keer zien. Open in het menu 'Core Web Vitals' onder het kopje Ervaring.

Je ziet twee grafieken, mobiel en computer, met drie kleuren: goed, verbetering nodig en slecht. Klik op een rapport en je ziet welk probleem speelt, bijvoorbeeld 'LCP-probleem: langer dan 2,5 s', met voorbeeldadressen.

Search Console groepeert pagina's die op elkaar lijken. Los je het probleem op in het sjabloon van je productpagina, dan verbeteren alle productpagina's mee.

Na een verbetering klik je op 'Oplossing valideren'. Google volgt de pagina's dan 28 dagen. Heb je Search Console nog te koppelen? Hoofdstuk 7 van deze cursus legt het uit.

Wil je je website sneller maken, begin dan bij de afbeeldingen. Bij de meeste mkb-sites zijn foto's het zwaarste onderdeel van de pagina. Een foto rechtstreeks uit de telefoon is al snel 4 MB en 4000 pixels breed.

1. Juiste afmetingEen foto over de volle breedte heeft op een telefoon ongeveer 800 pixels nodig en op een groot scherm 1600 tot 2000. Verklein hem voor het uploaden.
2. Modern formaatSla foto's op als WebP of AVIF. Die formaten zijn bij gelijke kwaliteit veel kleiner dan JPEG en werken in alle gangbare browsers.
3. Meerdere breedtes aanbiedenMet 'srcset' in de code kiest de browser zelf de passende versie. Moderne systemen en plugins regelen dat automatisch.
4. Hoofdafbeelding met voorrangGeef de grote foto bovenaan het kenmerk fetchpriority='high'. De browser haalt hem dan als eerste op. Dat is vaak de grootste winst voor LCP.
5. De rest uitgesteld ladenGeef foto's lager op de pagina loading='lazy'. Ze laden dan pas als de bezoeker er bijna is. Sla de hoofdafbeelding hierbij over.
6. Afmetingen in de codeZet breedte en hoogte bij elke afbeelding. De browser houdt de ruimte vrij en de pagina blijft stabiel.

Een gratis hulpmiddel als Squoosh, gemaakt door het Chrome-team, zet een foto in je browser om naar WebP of AVIF en toont het verschil in grootte.

Het formaat bepaalt voor een groot deel het gewicht van je pagina. Met deze tabel kies je in tien seconden.

Een richtlijn uit de praktijk: houd een grote foto bovenaan onder de 200 kB en gewone foto's in de tekst onder de 100 kB. Het totale gewicht van een pagina blijft bij voorkeur onder de 2 tot 3 MB.

Elke meting begint bij je server. Antwoordt die traag, dan blijft elke andere verbetering daarachter hangen. In PageSpeed Insights zie je dit terug als 'Reactietijd van de server' of TTFB.

Drie dingen bepalen die reactietijd. De kwaliteit van je hosting. De hoeveelheid werk die de server per bezoek doet. En de afstand tussen de server en je bezoeker.

1. HostingGoedkope gedeelde hosting deelt één server met honderden sites. Een pakket met eigen rekenkracht en servers in of nabij Nederland scheelt vaak een halve seconde.
2. CachingMet caching bewaart de server een kant-en-klare versie van elke pagina. Het volgende bezoek krijgt die versie direct en bespaart het opnieuw opbouwen van de pagina.
3. CDNEen content delivery network zet kopieën van je bestanden op servers over de hele wereld. Nuttig bij bezoekers uit meerdere landen en bij veel afbeeldingen.
4. CompressieLaat de server tekstbestanden verkleind versturen met Brotli of gzip. Bij de meeste hosts staat dit standaard aan.
5. Recente softwareEen actuele versie van PHP of van je platform is merkbaar sneller dan een versie van jaren terug.

Lettertypen zijn een stille vertrager. Een site met vier lettertypen in zes diktes laadt zomaar een megabyte aan letters. De tekst wacht daar soms op en blijft dan even onzichtbaar.

Beperk je tot twee lettertypen en de diktes die je echt gebruikt. Kies het formaat WOFF2, het lichtste formaat voor weblettertypen.

Host de lettertypen op je eigen domein. Dat scheelt een extra verbinding naar een andere server. Laat de bouwer het belangrijkste lettertype 'preloaden', zodat de browser het vroeg ophaalt.

Vraag ook naar 'font-display: swap'. De browser toont de tekst dan meteen in een standaardletter en wisselt naar jouw lettertype zodra het binnen is. Kies een standaardletter met ongeveer dezelfde breedte, dan blijft de pagina stabiel.

Voor stijlen geldt hetzelfde principe. Het stijlbestand, de CSS, houdt het tonen van de pagina tegen tot het geladen is. Laat ongebruikte stijlen verwijderen en het bestand verkleinen.

Een goede INP haal je door de browser minder JavaScript te laten verwerken. Begin met een inventaris: welke scripts laadt je site? PageSpeed Insights toont ze onder 'Code van derden' en 'JavaScript-uitvoeringstijd'.

1. Ruim opVerwijder plugins, pixels en widgets die je al maanden laat liggen. Elk script dat weg is, scheelt de browser bij elk bezoek werk.
2. Stel uitLaad scripts die pas later nodig zijn met 'defer' of na de eerste actie van de bezoeker. Een chatwidget kan prima drie seconden later verschijnen.
3. Vervang zware onderdelenEen schuifbalk met tien foto's kost veel rekenkracht. Eén sterke foto met een kop werkt vaak beter en laadt sneller.
4. Laad video op klikToon een stilstaand beeld met een afspeelknop en laad de speler van YouTube pas na de klik.
5. Beperk de pagina-opbouwPaginabouwers stapelen soms tien lagen code om één knop. Een eenvoudiger opbouw maakt elke actie sneller.
6. Stel cookietoestemming goed inLaad marketingscripts pas na toestemming. Dat is netjes volgens de privacyregels en scheelt direct laadwerk.

In de labtest zie je INP nergens terug, omdat een robot alleen laadt en nergens op tikt. Kijk daar naar 'Total Blocking Time', de tijd dat de browser bezet is. Daalt die waarde, dan verbetert INP bij echte bezoekers meestal mee.

De oplossing voor verspringende pagina's is steeds dezelfde: reserveer vooraf de ruimte voor alles wat later laadt.

1. Afbeeldingen en videoZet breedte en hoogte in de code of gebruik de CSS-eigenschap 'aspect-ratio'. De browser tekent het vak alvast.
2. Advertenties en ingesloten blokkenGeef het blok voor een kaart, een reviewwidget of een advertentie een vaste minimale hoogte.
3. Cookiemelding en bannersLaat ze over de pagina heen zweven, bijvoorbeeld onderaan. Een balk die bovenaan wordt ingevoegd, duwt alles omlaag.
4. LettertypenKies een standaardletter met dezelfde breedte als je eigen lettertype, zodat regels gelijk blijven bij het wisselen.
5. AnimatiesLaat onderdelen bewegen met 'transform' en 'opacity'. Die eigenschappen verplaatsen niets in de opbouw van de pagina.

Wil je zien wat er verspringt? PageSpeed Insights toont onder 'Grote lay-outverschuivingen vermijden' precies welke onderdelen bewegen.

De laadtijd van je website is een verzamelnaam. De ene tool bedoelt de tijd tot het eerste beeld, de andere de tijd tot alles binnen is. Daarom geven twee tools voor dezelfde pagina verschillende seconden.

Core Web Vitals lossen dat op door te meten wat de bezoeker merkt. Gebruik deze streefwaarden als kompas.

Haal je LCP, INP en CLS in de veldgegevens, dan is je site snel genoeg voor Google. Elke tiende seconde daarbovenop is winst voor je bezoeker.

Veel ondernemers werken met WordPress of een webshopplatform. De principes blijven gelijk. De knoppen zitten op een andere plek.

1. WordPress: themaEen licht thema is de basis. Zware thema's met tientallen ingebouwde functies laden die op elke pagina mee.
2. WordPress: pluginsLoop je plugins langs en verwijder wat je kunt missen. Eén plugin voor caching en één voor afbeeldingen doen het meeste werk.
3. WordPress: paginabouwersBouwers als Elementor en Divi maken ontwerpen makkelijk en voegen veel code toe. Zet ongebruikte onderdelen in de instellingen uit.
4. Shopify en andere webshopsDe server is geregeld. De winst zit in een licht thema, minder apps en kleinere productfoto's. Elke app voegt eigen scripts toe.
5. Eigen codeEen site in eigen code laadt alleen wat de pagina nodig heeft. Dat is de reden dat wij bij Delta Six zo bouwen.

Test na elke wijziging opnieuw. Soms levert het verwijderen van één plugin meer op dan een week finetunen.

Een voorbeeld om het concreet te maken. Een kapsalon heeft een homepage met een schuifbalk van zes foto's uit de camera, een ingesloten Instagram-feed, een chatwidget en drie lettertypen.

De labtest op mobiel geeft een LCP van 6,1 seconden, een hoge blokkeertijd en een CLS van 0,28. Alle drie rood. De oorzaken zijn in vijf minuten te vinden in het rapport.

Ruim twee uur werk en alle zes de oorzaken zijn aangepakt. Hoeveel seconden het precies scheelt, verschilt per site. Meet daarom altijd voor en na, met dezelfde tool.

Pak het in stappen aan. Werk van groot naar klein en meet tussendoor. Deze volgorde geeft bij de meeste mkb-sites het snelst resultaat.

1. 1. Meet je beginstandPageSpeed Insights voor vier pagina's en het rapport in Search Console. Noteer alles met datum.
2. 2. AfbeeldingenAfmeting, formaat, voorrang voor de hoofdfoto en uitgesteld laden voor de rest.
3. 3. Scripts opruimenAlles weg wat aantoonbare waarde mist. De rest uitstellen.
4. 4. Ruimte reserverenAfmetingen in de code en zwevende meldingen voor een stabiele pagina.
5. 5. Server en cachingCaching aan, compressie aan en bij een blijvend trage server een beter hostingpakket.
6. 6. Lettertypen en stijlenMinder lettertypen, eigen hosting en opgeschoonde CSS.
7. 7. Meet opnieuw en wachtDe labtest verandert direct. De veldgegevens lopen over 28 dagen en volgen dus later.

Een site wordt vanzelf trager. Er komt een plugin bij, iemand uploadt een foto van 6 MB, de marketingafdeling plaatst een nieuwe pixel. Snelheid vraagt daarom een kort vast moment.

Open één keer per maand het rapport Core Web Vitals in Search Console. Staat alles op groen, dan ben je in twee minuten klaar. Verschijnt er oranje of rood, test dan een voorbeeldadres in PageSpeed Insights.

Spreek één regel af met iedereen die aan de site werkt: elke nieuwe foto gaat eerst door een verkleiner en elk nieuw script krijgt een eigenaar en een reden. Die ene regel voorkomt de meeste achteruitgang.

Wil je een snelle eerste indruk van je site, inclusief snelheid? Gebruik dan onze gratis controle op /seo-website-check/.

Bij Delta Six bouwen we elke website in eigen code, met lichte afbeeldingen en alleen de scripts die de pagina nodig heeft. Wij bouwen jouw custom website helemaal gratis. Je betaalt pas als je tevreden bent.

Je ziet je nieuwe site in een online showcase van 15 minuten. Kies je voor ons, dan sta je binnen twee weken live, met geld-terug-garantie. Ondernemers geven ons een 4,9 op Google. Ons kantoor staat in Maasdam.

• Ik heb mijn homepage en drie belangrijke pagina's getest in PageSpeed Insights, op het tabblad Mobiel.
• Ik heb de uitkomsten voor LCP, INP en CLS genoteerd met datum.
• Ik heb het rapport Core Web Vitals in Search Console bekeken.
• Alle foto's zijn verkleind naar de afmeting waarop ze getoond worden.
• Foto's staan in WebP of AVIF en logo's in SVG.
• De hoofdafbeelding bovenaan laadt met voorrang en de overige afbeeldingen laden uitgesteld.
• Elke afbeelding en video heeft een breedte en hoogte in de code.
• Ongebruikte plugins, pixels en widgets zijn verwijderd.
• Chat, video en andere zware onderdelen laden pas later of na een klik.
• Caching en compressie staan aan op de server.
• De site gebruikt hoogstens twee lettertypen, in WOFF2 en vanaf het eigen domein.
• Cookiemelding en banners zweven over de pagina en duwen de inhoud nergens weg.
• Na elke wijziging heb ik opnieuw getest en het verschil genoteerd.
• In mijn agenda staat een maandelijkse controle van het rapport in Search Console.