Google beoordeelt je hele website als 1 geheel. En 1 trage pagina trekt alles omlaag.

Wat zijn Core Web Vitals en waarom doen ze ertoe

Core Web Vitals zijn drie meetwaarden waarmee Google bepaalt hoe snel en prettig jouw website is voor bezoekers. Het zijn geen vage richtlijnen of suggesties. Het zijn harde cijfers die direct meewegen in je positie in de zoekresultaten. En sinds 2021 worden ze steeds zwaarder meegeteld.

De eerste meetwaarde is LCP, Largest Contentful Paint. Dit meet hoe snel het grootste zichtbare element op je pagina laadt. Dat kan een afbeelding zijn, een video, of een groot tekstblok. Google wil dat dit binnen 2,5 seconden gebeurt. Alles daarboven is te traag. Voor de gemiddelde bezoeker voelt het dan alsof de pagina hapert, en die klikt weg. Naar je concurrent, die wel snel laadt.

De tweede is INP, Interaction to Next Paint. Dit verving in maart 2024 de oude FID meting. INP kijkt naar hoe snel je website reageert als iemand ergens op klikt of tikt. Druk je op een knop en duurt het langer dan 200 milliseconden voordat er iets verandert op het scherm? Dan is je INP te hoog. Bezoekers voelen dat als “stroperig”. Ze kunnen het niet benoemen, maar ze merken het wel. En ze vertrekken.

De derde is CLS, Cumulative Layout Shift. Dit meet of elementen op je pagina onverwacht verspringen terwijl de pagina laadt. Ken je dat moment dat je een artikel wilt lezen, je begint met scrollen, en dan springt alles omhoog omdat er ineens een banner verschijnt? Dat is CLS. Google wil dat die waarde onder de 0,1 blijft. Alles daarboven is storend voor bezoekers en kost je punten.

Tot maart 2026 keek Google naar deze drie waarden per individuele pagina. Elke pagina werd apart beoordeeld. Had je een snelle homepage maar een trage contactpagina? Dan werd alleen die contactpagina bestraft. De rest van je site had daar geen last van. Dat is nu anders. Fundamenteel anders.

Wat is composite CWV scoring en wat veranderde er in maart 2026

In maart 2026 heeft Google een update doorgevoerd die de manier waarop Core Web Vitals worden meegewogen compleet heeft veranderd. Het heet composite CWV scoring, en het principe is simpel maar de gevolgen zijn groot: Google beoordeelt je website nu als een geheel in plaats van per pagina.

Wat dat in de praktijk betekent is dat de prestaties van al je pagina’s bij elkaar worden opgeteld en gemiddeld. Niet een simpel gemiddelde trouwens, maar een gewogen berekening waarbij de slechtste pagina’s zwaarder meetellen dan de beste. Google noemt dit een “site level performance signal” en het werkt vergelijkbaar met hoe ze al langer naar HTTPS en mobile friendliness kijken: het is een eigenschap van je hele site, niet van een individuele pagina.

De reden die Google geeft is logisch. Gebruikers ervaren een website als een geheel. Als je homepage snel laadt maar je productpagina’s traag zijn, dan is de totale gebruikerservaring matig. En Google wil de totale ervaring weerspiegelen in de zoekresultaten, niet een cherry picked versie waarbij je homepage goed scoort terwijl de rest achterblijft.

Voor grote websites met duizenden pagina’s is dit overzichtelijk te managen, die hebben technische teams die sitebrede prestaties bewaken. Maar voor MKB websites, en dat zijn er honderdduizenden in Nederland, is dit een probleem waar bijna niemand van weet. Want de meeste ondernemers kijken helemaal niet naar hun Core Web Vitals. En als ze het al doen, checken ze alleen hun homepage. Niet die ene blogpost van drie jaar geleden met een ongecomprimeerde afbeelding van 4 megabyte die je hele site score omlaag trekt.

Waarom een trage pagina nu je hele site schaadt

Stel je voor dat je een restaurant hebt. De entree is prachtig, het eten is goed, de bediening is vriendelijk. Maar de toiletten zijn smerig. Wat onthouden gasten? De toiletten. Zo werkt composite CWV scoring ook. Je kunt tien pagina’s hebben die perfect scoren, maar als er drie zijn die dramatisch traag laden, dan trekt dat je hele site omlaag.

De reden dat dit zo hard aankomt bij MKB websites is dat de meeste sites organisch gegroeid zijn over jaren. Je begon met een homepage en een paar dienstpagina’s. Toen kwamen er blogposts bij, een portfolio, misschien een kennisbank. Elk jaar kwam er wat bij, maar niemand keek terug naar wat er al stond. Die blogpost uit 2021 met de embedded YouTube video, drie ongecomprimeerde foto’s en een social media widget? Die laadt in 8 seconden. En die trekt nu je homepage mee omlaag.

Het gewogen gemiddelde maakt het extra pijnlijk. Google kijkt niet alleen naar het gemiddelde van al je pagina’s. De slechtste presteerders wegen zwaarder mee in de berekening. Dat betekent dat tien snelle pagina’s niet opwegen tegen drie trage. De drie trage pagina’s hebben een disproportioneel grote impact op je totale score. Het is alsof je op school een 9 haalt voor vijf vakken maar een 2 voor wiskunde, en dat die 2 dubbel telt in je gemiddelde.

Concreet zie je dit terug in je zoekresultaten. Pagina’s die voorheen op positie 3 of 4 stonden, zakken naar positie 7 of 8. Niet omdat de content slechter is geworden, maar omdat de sitewijde snelheidsscore is gezakt. En jouw concurrent die wel zijn hele site heeft opgeschoond? Die schuift naar boven. Niet met betere content, maar met een snellere site.

Hoe je erachter komt of jouw site een probleem heeft

De meeste ondernemers hebben geen idee wat hun Core Web Vitals score is. Dat is niet erg, want tot maart 2026 maakte het per pagina uit en was de impact beperkt. Maar nu het sitebreed meetelt, moet je het weten. En het is makkelijker te checken dan je denkt.

De eerste plek om te kijken is Google Search Console. Als je die al hebt ingericht (en dat zou je moeten hebben), ga dan naar het rapport “Core Web Vitals” in het linkermenu. Daar zie je direct hoeveel pagina’s van je site als “goed”, “verbetering nodig” of “slecht” worden beoordeeld. Sinds de maart update zie je ook een sitebreed overzicht met je composite score. Als daar meer dan 20% van je pagina’s als “slecht” staat, heb je een probleem dat nu al je rankings beïnvloedt.

Een tweede manier is PageSpeed Insights van Google. Ga naar pagespeed.web.dev en voer je URL in. Je krijgt dan een rapport voor die specifieke pagina. Doe dit niet alleen voor je homepage. Check je contactpagina, je meest bezochte blogposts, je dienstpagina’s. Het zijn vaak de pagina’s waar je het minst naar omkijkt die de slechtste score hebben. Die ene oude pagina met een stockfoto van 3000×2000 pixels die je vijf jaar geleden hebt geüpload? Die kan nu je hele site naar beneden trekken.

Als je WordPress gebruikt, en zo’n 40% van alle websites in Nederland draait op WordPress, dan is er een derde optie. Installeer een plugin als Site Kit van Google. Die koppelt je Search Console data direct aan je WordPress dashboard en laat je per pagina zien welke Core Web Vitals problemen er zijn. Zo hoef je niet steeds heen en weer te schakelen tussen tools.

Wat je ook doet, check niet alleen je homepage. Dat is de valkuil waar bijna iedereen in trapt. Je homepage is waarschijnlijk je snelste pagina omdat die de meeste aandacht heeft gekregen. Het zijn de vergeten pagina’s, de oude blogposts, de niet meer actuele landingspagina’s, die je composite score naar beneden halen.

Wat je nu moet doen: concrete stappen

Je weet nu wat composite CWV scoring is en waarom het ertoe doet. De vraag is: wat doe je eraan? Het goede nieuws is dat de meeste problemen relatief eenvoudig op te lossen zijn. Je hoeft geen developer te zijn en je hoeft je site niet opnieuw te bouwen. Maar je moet wel actie ondernemen, want van niks doen wordt het alleen maar erger.

Stap 1: Inventariseer je slechtste pagina’s

Open Google Search Console en ga naar het Core Web Vitals rapport. Sorteer op “slecht” en maak een lijst van de pagina’s die het slechtst scoren. Dit zijn je prioriteiten. Niet je homepage, niet je nieuwste pagina, maar de pagina’s die het hardst zakken. In veel gevallen zijn het oude blogposts, portfolio items van jaren geleden, of landingspagina’s die ooit voor een campagne zijn gemaakt en daarna nooit meer zijn aangepast.

Stap 2: Pak de afbeeldingen aan

In 70% van de gevallen zijn afbeeldingen de grootste boosdoener. Ongecomprimeerde foto’s, afbeeldingen die groter zijn dan nodig, en afbeeldingen zonder lazy loading. De oplossing is simpel: comprimeer elke afbeelding tot onder de 200KB, gebruik het WebP formaat in plaats van JPG of PNG, en zorg dat afbeeldingen pas laden als ze in beeld komen. Als je WordPress gebruikt, doet een plugin als ShortPixel of Imagify dit automatisch voor je.

Stap 3: Ruim je scripts op

Elke plugin, widget, tracker en chatbot op je site laadt JavaScript. En elk script vertraagt je pagina. Kijk kritisch naar wat je echt nodig hebt. Die social media feed die niemand bekijkt? Verwijder hem. Die chatbot die twee keer per week wordt gebruikt? Overweeg of die de vertraging waard is. Elke script dat je verwijdert maakt je site sneller, niet een beetje maar meetbaar.

Stap 4: Fix je hosting

Goedkope shared hosting was prima toen snelheid per pagina werd beoordeeld. Nu het sitebreed meetelt, is een trage server een probleem dat al je pagina’s raakt. Je hoeft geen dure dedicated server te nemen, maar een fatsoenlijke managed WordPress hosting met caching en CDN maakt een wereld van verschil. Denk aan partijen als Cloudways, Kinsta of WP Engine. De investering is 20 tot 50 euro per maand, en het effect op je Core Web Vitals is direct meetbaar.

Stap 5: Verwijder of verbeter oude pagina’s

Dit is de stap die de meeste mensen overslaan, en het is misschien wel de belangrijkste. Heb je pagina’s die niemand meer bezoekt en die slecht scoren? Verwijder ze. Of redirect ze naar een relevante pagina die wel goed presteert. Je site hoeft niet elk stuk content te bewaren dat er ooit op is gezet. Minder pagina’s met betere scores is beter dan veel pagina’s waarvan de helft je composite score kapotmaakt.

De meest voorkomende snelheidsvreters op MKB websites

Na honderden website audits zien we steeds dezelfde problemen terugkomen. Het zijn zelden complexe technische issues. Het zijn bijna altijd dezelfde vijf dingen die sitebrede snelheidsproblemen veroorzaken.

Nummer een: ongecomprimeerde afbeeldingen. We zeiden het al, maar het kan niet vaak genoeg benadrukt worden. Wij zien wekelijks sites waar de homepage snel laadt, maar er ergens op pagina 17 een foto staat van 6 megabyte die de hele composite score kapotmaakt. Eén foto. Zes megabyte. Je hele site lijdt eronder.

Nummer twee: te veel plugins. De gemiddelde WordPress site heeft 25 tot 30 plugins geïnstalleerd. Daarvan zijn er misschien 10 echt nodig. De rest laadt scripts die je pagina’s vertragen zonder dat je het merkt. Elke plugin die je deactiveert en verwijdert maakt je site een klein beetje sneller, en al die kleine beetjes tellen nu sitebreed op.

Nummer drie: geen caching. Caching zorgt ervoor dat je server niet elke keer opnieuw de hele pagina hoeft op te bouwen als iemand langskomt. Zonder caching doet je server bij elke bezoeker hetzelfde werk. Met caching bewaar je het resultaat en serveer je dat direct. Het verschil kan oplopen tot 3 of 4 seconden laadtijd. Op elke pagina.

Nummer vier: externe scripts van derden. Google Analytics, Facebook Pixel, HotJar, Intercom, Google Tag Manager met twintig tags erin. Elk extern script is een verzoek naar een andere server die ook weer moet laden. En als die externe server even traag is, is jouw pagina ook traag. Beperk het aantal externe scripts tot wat je echt nodig hebt voor je bedrijfsvoering.

Nummer vijf: embedded content. YouTube video’s, Google Maps, Instagram feeds, Twitter timelines. Elk embedded element laadt een complete externe applicatie binnen je pagina. Een enkele YouTube embed voegt gemiddeld 1,5 seconde toe aan je laadtijd. Gebruik in plaats daarvan een thumbnail met een play knop die pas de video laadt als iemand erop klikt. Dat scheelt enorm.

Veelgestelde vragen over Core Web Vitals en snelheid