Core Web Vitals voor MKB: hoe Google snelheid jouw vindbaarheid bepaalt

Vorige week was onze eigen website-laadtijd voor mobiel 16,8 seconden. Dat is niet “een beetje traag”. Dat is een ranking-doodvonnis van Google, en de meeste MKB-sites die wij analyseren scoren niet veel beter. Hier is wat we eraan deden, wat het opleverde, en waarom Core Web Vitals het belangrijkste SEO-onderwerp is waar bijna geen MKB-ondernemer iets over hoort.

Sinds 2021 gebruikt Google Core Web Vitals als rankingfactor. Dat betekent: hoe sneller en stabieler je website laadt op een gemiddelde mobiele telefoon, hoe hoger je in de zoekresultaten staat. Twee identieke sites met dezelfde inhoud, dezelfde keywords en dezelfde links, de snelste wint. Toch gaat 90% van het MKB-SEO-budget naar keywords en backlinks, en bijna 0% naar laadtijd. Dat is een gat in de markt dat jij kunt gebruiken.

Wat zijn Core Web Vitals precies?

Google meet drie dingen aan je site:

• LCP (Largest Contentful Paint), hoe snel het grootste element op het scherm verschijnt. Vaak het hero-beeld of de hoofdkop. Goed: onder 2,5 seconden. Slecht: boven 4 seconden.
• INP (Interaction to Next Paint), hoe snel je site reageert op een klik of tap. Goed: onder 200ms. Vroeger heette dit FID, maar INP is sinds maart 2024 de officiele meting.
• CLS (Cumulative Layout Shift), hoeveel elementen verspringen tijdens het laden. Niets vervelender dan op een knop willen tikken en dat hij wegspringt omdat er nog een advertentie inlaadt. Goed: onder 0,1.

Google meet deze cijfers via twee bronnen. De ene is field data: echte cijfers van echte bezoekers via Chrome User Experience Report (CrUX). De andere is lab data: gesimuleerde tests via PageSpeed Insights. Wat telt voor de ranking is field data, maar lab data is wat jij kunt testen voordat je live gaat.

Waarom 90% van MKB-sites hierop faalt

De meeste sites worden gebouwd op desktop, getest op desktop, opgeleverd op desktop, en bekeken op mobiel. Op een MacBook met snelle WiFi laadt alles binnen een seconde. Op een Samsung A33 in de trein met 4G-haperingen kan diezelfde site 15 seconden nodig hebben. Dat is het verschil dat Google ziet, en dat is het verschil dat je ranking maakt of breekt.

De hoofdoorzaken die we structureel terugzien als we sites doormeten:

1. Te zware hero-beelden of -video’s. Een mooie hero-video van 2 MB voelt fantastisch op desktop. Op 4G is hij een laadtijd-moordenaar.
2. Render-blocking CSS en JavaScript. Externe Google Fonts die via een @import in de stylesheet zitten. Plugin-scripts die bovenaan in de head laden in plaats van onderaan via defer.
3. Shared hosting. Bij goedkope hosters deel je een server met 200 andere sites. Op piekuren is je TTFB (time to first byte) 2 seconden voordat er één pixel renderbaar is.
4. Plugins die niets toevoegen. Een gemiddelde WordPress-site heeft 15+ plugins, waarvan er 5 actief assets laden op elke pagina. Daar valt direct winst te halen.
5. Geen lazy-loading op below-fold beelden. Je hoeft de afbeeldingen in section 8 niet te downloaden voordat de bezoeker bij section 1 binnen is.

Wat wij deden aan onze eigen site

Eind vorige week haalden we een Lighthouse-rapport van circularmedia.nl op mobiel: 16,8 seconden LCP. Dat is in Google’s eigen termen “Poor” met hoofdletters, ver onder de 4-seconden-drempel die nog “Needs improvement” heet. Onze site stond effectief op een SEO-handicap waar we ons jaren niet bewust van waren geweest.

De diagnose was vier-lagig:

1. Onze hero-mascotvideo was 1,5 MB groot en werd door de browser direct gedownload met preload="auto". Op een trage 4G-verbinding nam dat alleen al 8 seconden in beslag.
2. Onze main.css was 82 KB ongecomprimeerd en importeerde Google Fonts via @import, een keten die de browser pas kon doorlopen nadat de hele CSS gedownload was.
3. De Google Fonts laadden zonder display=swap, dus tekst bleef onzichtbaar tot de fonts er waren.
4. Verschillende beeldformaten werden 3 tot 4 keer gerenderd in dezelfde pixeldichtheid, terwijl mobiel niet meer dan 480 pixels breed weergeeft.

De ingrepen:

• Video opnieuw gecodeerd van 1,5 MB naar 321 KB, met behoud van visuele kwaliteit. Preload uitgezet, fetchpriority verlaagd. De poster-afbeelding krijgt nu fetchpriority="high" zodat die het LCP-element wordt.
• CSS geminimaliseerd: 82 KB naar 57 KB. Google Fonts losgekoppeld van het CSS-bestand en als non-blocking <link rel="preload" as="style"> in de header gezet.
• Transparante PNG-fallback van 2,4 MB vervangen door een geoptimaliseerde versie van 76 KB.
• Het inline-img-element binnen de video-tag verwijderd, moderne browsers gebruiken dat nooit maar laden het wel eager.

Resultaat: LCP van 16,8 seconden naar 3,5 seconden, een verbetering van 79%. Totale paginaload van 5,4 MB naar 671 KB, een reductie van 88%. Geen extra plugins, geen CDN, geen migratie. Alleen het opruimen van wat erop stond.

Hoe je je eigen Core Web Vitals meet (gratis, binnen 2 minuten)

Voordat je iets gaat optimaliseren, weet je waar je staat:

1. Ga naar pagespeed.web.dev.
2. Vul je homepage-URL in.
3. Wacht 30 seconden voor de mobile-tab te laden.

Je krijgt twee dingen: een groot rond cijfer met een score (op 100) en een tabblad “Diagnostics” met concrete observaties. Het cijfer zelf is minder belangrijk dan de individuele Core Web Vitals-metingen onderaan. Kijk vooral naar LCP en CLS. INP is moeilijker te repareren zonder developer.

Als je rood scoort op LCP, kijk dan eerst naar je hero-section. 8 van de 10 keer is dat de oorzaak: een te grote afbeelding of video, of een ranking-blockend script.

De ranking-impact in cijfers

Onderzoek van Backlinko (2020) en Google’s eigen Web Vitals-team laat consistent zien: sites die alle drie Core Web Vitals binnen Google’s “Good” range halen, krijgen gemiddeld 24% lager bounce rate dan sites in de “Poor” range, en converteren in e-commerce-context 13 tot 17% beter.

Voor Google’s ranking-algoritme specifiek: in 2021 noemde Google Page Experience (waar Core Web Vitals onder valt) een “tiebreaker” tussen twee gelijkwaardige resultaten. Sindsdien is het gewicht ervan toegenomen. We hebben klanten gezien die na een Core Web Vitals-fix in twee maanden tijd van pagina 2 naar pagina 1 voor hun belangrijkste keyword stegen, zonder een enkele content- of linkverandering.

De winst zit niet alleen in directe ranking. Snelheid is ook een Google E-E-A-T-signaal. AI-zoekmachines zoals ChatGPT, Perplexity en Google AI Overviews scrapen content veel sneller van snelle sites, en zijn waarschijnlijker om jou te citeren als bron. Slow site = slow citation rate.

Wat je deze week kunt doen (zonder developer)

Als je geen WordPress-developer in huis hebt, zijn dit de drie snelste wins:

1. Comprimeer je hero-beeld

Sleep je hero-foto in squoosh.app (gratis, geen account). Kies aan de rechterkant “WebP” als format en zet de quality op 75. In 10 seconden heb je een bestand dat 70 tot 90% kleiner is, met geen zichtbaar kwaliteitsverlies. Vervang het origineel in je media library.

2. Schakel onnodige plugins uit

In WordPress: ga naar Plugins, deactiveer alles wat je in 30 dagen niet hebt gebruikt. Test de site daarna. Plugins als sliders, contact-form builders die je nooit gebruikt, of analytics-tools die dubbel staan ingeladen zijn vrijwel altijd de eerste verdachten. Een geactiveerde, maar ongebruikte plugin laadt nog steeds zijn CSS en JavaScript op elke pagina.

3. Zet een caching-plugin aan

Als je nog geen caching gebruikt: installeer WP-Optimize (gratis) of WP Rocket (betaald, beter). Activeer minimaal “Page cache” en “Combine CSS/JS”. Test daarna eerst op een staging-omgeving als je die hebt, in zeldzame gevallen botst caching met formulieren of dynamische content.

Als deze drie stappen je TTFB niet onder de 1 seconde brengen, ligt het probleem dieper, meestal in je hosting. In dit artikel vergeleken we Hostinger, Cloudways en SiteGround voor MKB-gebruik, met name op laadsnelheid. En hier leggen we uit waarom shared hosting bijna altijd je TTFB de das omdoet.

Tot slot

Core Web Vitals is een van de weinige SEO-onderwerpen waarop het MKB direct meetbare voordelen kan halen zonder maandenlange contentcampagnes. Het is technisch, ja. Maar het is technisch in een afgesloten domein, er is een eindige hoeveelheid wat je kunt fixen, het is testbaar, en de resultaten zie je in dagen, niet in maanden. De ondernemers die hierin investeren, halen voorsprong op concurrenten die nog voor backlinks aan het betalen zijn.

Wil je weten hoe jouw site er op dit moment voor staat, en wat we als eerste zouden aanpassen om je laadtijd onder de Google “Good”-drempel te brengen? Vraag een gratis website-analyse aan. We doen een Lighthouse-meting, identificeren je drie grootste rem-veroorzakers, en sturen binnen een werkdag een eerlijk rapport met wat je zelf kunt doen en wat een developer-fix nodig heeft.