Core Web Vitals voor MKB

TL;DR Core Web Vitals = LCP (laadt het grootste element binnen 2.5s?), INP (reageert je site binnen 200ms op een klik?), CLS (springt content rond tijdens laden, onder 0.1?). Voor MKB: LCP is verreweg het belangrijkst, omdat 70% van MKB-sites op LCP zakken door zware foto's. Fix LCP eerst, dan CLS, dan INP. Meet op pagespeed.web.dev (mobiel).

Waarom Core Web Vitals bestaan

Google introduceerde Core Web Vitals in 2020-2021 om iets meetbaars te hebben voor "gebruikerservaring". Tot dan rankte een trage maar relevante site nog steeds hoog. Vanaf 2021 is snelheid een tiebreaker geworden. Vanaf 2024 (met de INP-update) is het een gewicht-criterium in het ranking-algoritme.

Voor jou als MKB-ondernemer betekent dat: een goed-geoptimaliseerde concurrent met minder content kan jou voorbijgaan in zoekresultaten, simpelweg omdat zijn site sneller is. Dat is geen theorie — wij zien dat structureel terug in onze audits.

De drie metrieken in MKB-taal

1. LCP — Largest Contentful Paint

Wat het meet: hoe snel het grootste element op je pagina zichtbaar wordt. Voor MKB-sites is dat bijna altijd de hero-afbeelding of de hoofd-titel.

Doelwaarde: onder 2.5 seconden op mobiel.

Waarom MKB hier zakt: grote, niet-geoptimaliseerde hero-foto's. Een 4 MB hero-foto die niet in WebP staat doet er op 4G makkelijk 5-7 seconden over. Fix: foto in WebP (zie WebP vs JPG) + dimensie aanpassen aan scherm + lazy loading uit op de hero. Detail in LCP fixen 2026.

2. INP — Interaction to Next Paint

Wat het meet: hoe snel je site reageert op een klik, tap of toetsenbord-input. Sinds maart 2024 vervangt INP de oudere FID-metriek.

Doelwaarde: onder 200 ms.

Waarom MKB hier zakt: te veel JavaScript dat tegelijk wil starten. Vooral WordPress-sites met 25+ plugins lopen vast. Een hamburger-menu dat 500ms doet over openen, een formulier dat hapert — dat is INP. Fix: scripts saneren, async/defer toevoegen, plugin-audit. Detail in INP uitleg.

3. CLS — Cumulative Layout Shift

Wat het meet: hoeveel content rondspringt tijdens het laden. Een ad die laat verschijnt en de tekst naar beneden duwt, een font dat verandert nadat tekst al getoond is, een afbeelding zonder gespecificeerde hoogte die opeens ruimte vraagt.

Doelwaarde: onder 0.1.

Waarom MKB hier zakt: afbeeldingen zonder width/height-attribuut, fonts zonder font-display: swap, cookie-banners die laat injecteren. Fix is meestal eenvoudig maar moet wel gedaan. Detail in CLS uitleg.

Sites die alle drie de Core Web Vitals halen, ranken gemiddeld 24% hoger op vergelijkbare keywords — Google Search Central data 2025.

Wat MKB anders moet aanpakken dan corporate

Voor grote sites (corporate, e-commerce platforms) wordt CWV gefixt door dev-teams, A/B-tests en performance-engineers. Voor MKB is dat onhaalbaar — maar gelukkig ook niet nodig. Vier dingen waar MKB anders is:

Minder pagina's = lagere fix-kost. Een MKB-site heeft typisch 10-30 pagina's. Alle in één keer fixen kan in 1-3 dagen werk.
Foto's zijn de hoofdoorzaak. Bij corporate is het vaak JavaScript-overload. Bij MKB zijn het foto's. Begin daarbij, geen dev-team nodig.
Concurrenten zijn vaak ook traag. Lokale MKB-sectoren (hoveniers, kappers, restaurants) hebben gemiddeld PageSpeed 35-50. Jij naar 75+ = direct competitief voordeel.
Tooling is gratis. Squoosh.app voor foto's, pagespeed.web.dev voor metingen, Google Search Console voor monitoring. €0 in tools.

Hoe Google meet — twee bronnen

Goed om te weten: Google heeft twee meetbronnen voor CWV.

Lab-data (Lighthouse). Wat je ziet op pagespeed.web.dev wanneer je je site analyseert. Gesimuleerde meting. Goed voor diagnose, niet voor ranking.
Veld-data (CrUX, Chrome User Experience Report). Anonieme echte-gebruikersdata van Chrome-gebruikers. Dit is wat Google gebruikt voor ranking. Te zien in Google Search Console > "Core Web Vitals"-tab.

Veld-data heeft 28 dagen nodig om bij te trekken na een fix. Je kunt vandaag perfectioneren en pas eind volgende maand de ranking-boost zien. Plan ernaar.

Concreet stappenplan voor MKB

Meet vandaag. pagespeed.web.dev op mobiel. Noteer LCP, CLS, INP. Doe dat ook voor 3 concurrenten.
Fix foto's eerst. WebP, juiste dimensies, lazy-loading. Verbetert vaak LCP en CLS in één keer met 30-50%.
Plugin-audit (alleen WordPress). Schakel uit wat je niet gebruikt. Vervang zware door lichte alternatieven. INP gaat omhoog.
CLS-fix. Voeg width/height toe aan alle afbeeldingen, font-display: swap aan fonts.
Meet opnieuw na 1 week. Veld-data komt pas na 28 dagen. Hou je dashboard in Search Console in de gaten.

Wanneer fix-zelf niet werkt

Als je na bovenstaande nog steeds onder PageSpeed 60 zit, ligt het waarschijnlijk aan de codebase. Verouderd thema, oud framework, opgestapelde technische schuld. Dan helpt verder optimaliseren nauwelijks meer — een rebuild is goedkoper op de lange termijn.

DesignCheck garandeert Lighthouse 90+ op elk rebuild-pakket (€1.995-€6.995 vast, zie prijzen). Wil je weten of het de moeite waard is? De verliescalculator rekent het door op basis van jouw bezoekers en conversie. Voor regio-MKB werken we vanuit DesignCheck Mijdrecht.

CWV-audit — gratis

Wij meten alle drie de metrieken op 5 pagina's en sturen binnen 48 uur de top-3 fixes met prijs erbij.

Audit aanvragen →

De vierde metriek niemand noemt: TTFB

Core Web Vitals zijn drie metrieken, maar er bestaat een vierde meting die geen ranking-factor is en toch je hele performance-budget bepaalt: Time To First Byte. TTFB meet hoe lang de browser moet wachten tussen het verzenden van het verzoek en het binnenkrijgen van de eerste byte HTML. Op trage shared hosting is dat 800-1200 ms. Op edge-hosting zoals Vercel of Cloudflare Pages is dat onder 100 ms.

Waarom dit zo belangrijk is: je LCP-budget van 2,5 seconden begint pas tikken zodra de eerste byte binnenkomt. Verlies je 1 seconde aan trage hosting, dan moet je site daarna binnen 1,5 seconde een afbeelding van 200 KB downloaden, parsen, renderen én aan de gebruiker tonen. Op 4G is dat nauwelijks haalbaar. Veel MKB-sites die "alles goed gedaan hebben" (foto's geoptimaliseerd, fonts gepreload, CSS gecomprimeerd) halen LCP niet omdat hun hosting twee tellen achterstand levert die niet meer in te halen is.

Hostingupgrade is vaak de snelste win. Een verhuis van shared hosting naar managed Astro op Vercel of Cloudflare Pages verlaagt TTFB met 600-900 ms. Dat is een gratis kortere LCP. Klanten op een DesignCheck-rebuild draaien standaard op edge-infrastructuur — TTFB op Keurmeesters meet 67 ms gemiddeld over 30 dagen.

Hoe ranking eigenlijk verschuift door Core Web Vitals

Veel ondernemers denken dat Core Web Vitals een aparte ranking-factor zijn die je positie direct beïnvloedt zoals een backlink dat doet. Klopt niet. Google noemt CWV een tiebreaker: bij twee resultaten van vergelijkbare relevantie krijgt de snellere voorrang. Op niet-competitieve queries (lokale niche, eigen merknaam) merk je daar weinig van. Op competitieve queries ("hovenier Mijdrecht", "afsprakentool voor kappers") is het verschil groot.

De tweede manier waarop CWV ranking beïnvloedt is indirect, via gedrag. Een trage site krijgt hogere bouncerate, lagere scroll-depth en kortere session-duration. Google ziet die signalen via Chrome en Search Console en interpreteert dat als lage kwaliteit. Het algoritme herrangschikt resultaten op basis van die signalen. Een snelle site krijgt meer kans om bovenaan te blijven omdat bezoekers langer doorklikken.

Voor MKB betekent dit: rank-tracking-tools tonen je positie maar geen oorzaak. Als je in een week zakt van plek 5 naar plek 9 zonder content-wijzigingen, check eerst je veld-CWV in Search Console. Een algoritme-update of een trage thema-update kan binnen dagen je positie laten zakken.

Wat veld-data vertelt dat lab-data niet doet

Lab-data komt uit Lighthouse. Dat is een enkele meting onder geconditioneerde omstandigheden: gesimuleerde 4G, een specifiek device-profiel, schoonloket cache. Handig voor diagnose, slecht voor ranking-voorspelling. Veld-data uit CrUX is de echte spiegel. Het toont hoe je site over 28 dagen presteert op duizenden bezoekers met verschillende telefoons, providers en locaties.

Drie dingen die je alleen in veld-data ziet:

Verschil tussen p75 en mediaan. Als de mediaan-LCP 1,8s is maar de p75 zit op 3,4s, weet je dat een kwart van je bezoekers een slechte ervaring heeft. Lab-data toont alleen die ene meting.
Verschil tussen Wi-Fi en mobiel verkeer. CrUX aggregateert per netwerk. Je ziet of je site uitvalt op 4G of 5G of dat het juist Wi-Fi-bezoekers zijn die hangen (vaak een DNS-probleem).
Trends over tijd. Een leesbare grafiek per week of maand toont of je vooruit gaat. Lab-data per fix-iteratie zegt nooit hoe het over een maand zit.

Google Search Console toont veld-CWV gratis. Klik in de linker navigatie op "Core Web Vitals" → "Mobile" of "Desktop". URL's worden gegroepeerd in "good", "needs improvement" en "poor". Een MKB-site met 30 pagina's heeft typisch 4-7 URL-groepen. Werk per groep, niet per pagina.

Een waarschuwing: veld-data heeft een minimum-drempel. Sites met te weinig verkeer (onder ongeveer 1.000-2.000 bezoekers per maand op één URL-template) krijgen geen CrUX-data van Google. Dan zie je "insufficient data" in PageSpeed Insights. Dat is geen vrijbrief — Google gebruikt dan een fallback op origin-niveau, de gemiddelde score van je hele domein. Optimaliseer dus alsnog, maar gebruik lab-data om voortgang te meten en wacht langer op zichtbare ranking-effecten.

Een tweede waarschuwing voor multi-language sites: CrUX aggregateert per URL, niet per taal. Heb je je Engelse pagina onder /en/ en je Nederlandse onder /, dan worden die apart gemeten. Bij wereldwijd publiek dat we vanuit DesignCheck remote bedienen, is dat een aandachtspunt — je optimaliseert per geografie omdat netwerken verschillen tussen Nederland, Duitsland en Verenigde Staten.

Sector-specifieke valkuilen voor MKB

Niet elke branche heeft dezelfde problemen. Wat we in onze audit-historie zien per sector:

Hoveniers en aannemers. Foto-overload. 20-40 ongecomprimeerde foto's op één projectpagina van 8-12 MB totaal. LCP zit standaard op 5-8s. Eerste fix: foto's converteren naar WebP en juiste afmeting renderen.
Restaurants en horeca. Embed-overload. Online reserveren, social-feeds, kaart-iframe, foto-galerij van Instagram. INP zit op 400-600 ms door third-party scripts. Eerste fix: scripts onder een interaction-pattern hangen (laden bij klik).
Webshops klein. Plugin-stack op Magento of WooCommerce. CLS en INP samen ontspoord. Eerste fix: plugin-audit en hosting-upgrade.
Zakelijke diensten (advocaten, accountants). Verouderde templates met inline-styling en jQuery-overhead. LCP redelijk, INP rampzalig. Eerste fix: jQuery vervangen of script-deferring.
Energie en certificering. Veel dynamische API-calls. Keurmeesters had dit risico en hebben we opgelost door BAG-API server-side te doen en alleen de gerenderde tabel aan de client te leveren. Resultaat: Lighthouse 96/100/100/100 op mobiel met live data uit een externe overheids-API.
Lokale dienstverleners (kappers, fysiotherapie). Boekingsmodules van externe providers die de hele homepage vertragen. Eerste fix: module verplaatsen naar dedicated /afspraak-pagina, op homepage alleen link.

Checklist — Core Web Vitals voor MKB-eigenaren

Draai pagespeed.web.dev op je homepage, mobiel-tab. Noteer LCP, INP, CLS van veld-data (boven in de balk staat "Discovered URL — field data").
Open Google Search Console. Klik linksonder op "Core Web Vitals". Bekijk welke URL-groepen rood of geel staan.
Doe dezelfde meting voor je drie belangrijkste concurrenten op dezelfde keywords. Zie waar zij staan.
Bepaal je hosting-TTFB met webpagetest.org of curl. Onder 200 ms = oké. Boven 600 ms = upgrade overwegen.
Tel het aantal ongeoptimaliseerde afbeeldingen op je hoofdpagina. Boven 10 = priority-fix.
Tel het aantal third-party scripts (Google Analytics, chatbots, social pixels, ads). Boven 5 = INP-risico.
Inspecteer of je hero-afbeelding lazy-loading aan heeft staan. Zet uit op de hero (alleen below-the-fold lazy laden).
Check je font-stack. font-display: swap aanstaan? Preload op de primaire font?
Plan een fix-cyclus per metriek. Eerst LCP (foto's en hosting), dan CLS (dimensies en banners), dan INP (scripts saneren).
Meet opnieuw na elke fix. Lab eerst — die updatet direct. Veld na 28 dagen.
Stel een rebuild-budget. Komt je site na 8 uur fix-werk niet onder de drempels, reken door wat een rebuild zou kosten via de verliescalculator.
Plan vier kwartaal-controles per jaar. Drift gebeurt sluipend door content-updates en plugin-installaties.

De kostprijs van uitstel — wat trage CWV maandelijks kost

Veel MKB-eigenaren behandelen Core Web Vitals als "leuk om ooit te fixen". De rekensom zegt iets anders. Stel je hebt 4.000 bezoekers per maand op je site, conversie van 2,1% (gemiddelde voor diensten-MKB) en een gemiddelde klantwaarde van €450. Dat is 84 leads, €37.800 omzet per maand uit organisch verkeer.

Studies van Cloudflare, Akamai en Google laten consistent zien dat één seconde extra laadtijd 7-12% conversiedrop oplevert. Trekken we het conservatief: je LCP zit op 4,2s, doel is 2,5s, je verliest dus 1,7 seconde × 8% = 13,6% conversie. Op €37.800 is dat €5.140 verloren omzet per maand. Per jaar €61.700. Een rebuild-pakket van €3.995 verdient zichzelf terug in onder de drie weken — als de fix volledig is.

De verliescalculator op designcheck.nl/verliescalculator rekent dit uit voor jouw eigen cijfers. Vul bezoekers, conversie en klantwaarde in, krijg een onderbouwde schatting van wat slechte CWV je elke maand kost. Het rapport is openbaar en gratis. Een nuchter cijfer is waardevoller dan goedbedoelde theorie.

Een nuance: niet elke seconde laadtijd weegt even zwaar. De eerste seconde tussen 0,5 en 1,5s heeft beperkt effect — bezoekers verwachten enige laadtijd. De seconde tussen 1,5 en 2,5s begint conversie te kosten. Daarboven kantelt het hard: tussen 3 en 5 seconden verdubbelt de bouncerate. Dat is precies waarom de drempel van 2,5s is gekozen — boven die grens kelderen gedragssignalen meetbaar. Sites die structureel onder 1,8s LCP zitten profiteren niet alleen van ranking, maar van merkperceptie. Een snelle site oogt professioneler dan een trage met identiek design.

Wat doe je vandaag?

Open pagespeed.web.dev. Plak je homepage. Wacht op de mobiele test. Scroll naar de "Discovered" sectie en kijk welk van de drie metrieken rood is. Die rode is je startpunt. Klik 'em open en lees welk element verantwoordelijk is. Negen van de tien keer is het een afbeelding (LCP), een banner (CLS) of een script (INP). Eén concrete actie vanavond: pak die ene grootste afbeelding op je homepage, exporteer 'em opnieuw als WebP op 1600 pixels breed. Upload, vervang. Meet morgen. Eén metriek verbeterd is meer waard dan een week plannen maken.

Gerelateerde gidsen

FAQ — Core Web Vitals MKB

Telt Core Web Vitals echt voor mijn ranking?

Ja. Sinds 2021 onderdeel van Google's algoritme, sinds 2024 verzwaard. Sites die alle drie de drempels halen ranken gemiddeld 24% hoger op vergelijkbare keywords (Google Search Central data 2025).

Moet ik alle drie halen?

Google kijkt naar alle drie, maar LCP weegt het zwaarst voor MKB-content-sites. Volgorde van prioriteit voor MKB: LCP eerst, CLS tweede, INP derde.

Wat als ik op desktop wel haal en op mobiel niet?

Mobiel telt. Google indexeert mobile-first sinds 2019. Desktop-scores zijn alleen interessant als secundaire benchmark.

Hoe vaak meten?

Lab-data (pagespeed.web.dev) maandelijks na een fix-cyclus. Veld-data in Google Search Console wekelijks — die updatet 28-daags rolling.

Wat is de relatie tussen TTFB en Core Web Vitals?

TTFB (Time To First Byte) is geen Core Web Vital, maar bepaalt wel je LCP-budget. Bij een TTFB van 800 ms heb je nog 1,7 seconde over om onder de LCP-drempel van 2,5 seconde te blijven. Bij 1,5 seconde TTFB is LCP onder 2,5s vrijwel onmogelijk.

Heeft hosting impact op Core Web Vitals?

Ja, fors. Shared hosting met overbevolkte servers geeft TTFB van 600-1200 ms. Moderne edge-hosting (Vercel, Cloudflare Pages, Netlify) levert TTFB onder 100 ms. Dat verschil van 500 ms tikt direct door in LCP en daarmee in je ranking.

Wat is de p75-metriek in PageSpeed Insights?

Google neemt het 75e percentiel van echte bezoekers. Dat betekent dat 75% van je bezoekers de gerapporteerde score of beter ervaart. Een p75-LCP van 2,4s betekent dat 25% van je bezoekers het nog slechter heeft. Optimaliseren voor de p75 dwingt je om óók trage telefoons en zwakke verbindingen serieus te nemen.

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.