Scoort je website onder de 70 in Google PageSpeed Insights? Dan laat je waarschijnlijk klanten liggen. Onderzoek van Google toont aan dat 53% van mobiele bezoekers een pagina verlaat als die langer dan drie seconden laadt. En dat is geen theoretisch probleem: Vodafone verbeterde hun Largest Contentful Paint met 31% en zag 8% meer sales als direct gevolg. Deze gids is voor MKB-sites die onder die 70 scoren — en daar snel vanaf willen. Geen vaag advies over "performance verbeteren", maar meetbare stappen die je score binnen dagen omhoog trekken.
In onze gids over website laten maken behandelen we het volledige traject van strategie tot lancering. Dit artikel focust op het technische fundament: de drie Core Web Vitals die bepalen hoe Google je laadsnelheid beoordeelt, en hoe je ze concreet verbetert.
Wat zijn Core Web Vitals precies?
Core Web Vitals zijn drie meetwaarden waarmee Google de gebruikerservaring op je website beoordeelt. Ze zijn sinds juni 2021 een bevestigde rankingfactor en meten elk een ander aspect van je paginaprestaties.
De drie metrics en hun drempelwaarden
| Metric | Wat het meet | Goed | Matig | Slecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Laadsnelheid van het grootste zichtbare element | Onder 2,5 sec | 2,5 - 4,0 sec | Boven 4,0 sec |
| INP (Interaction to Next Paint) | Reactietijd na klik, tik of toetsaanslag | Onder 200 ms | 200 - 500 ms | Boven 500 ms |
| CLS (Cumulative Layout Shift) | Visuele stabiliteit — verschuift de pagina tijdens het laden? | Onder 0,1 | 0,1 - 0,25 | Boven 0,25 |
Google evalueert deze metrics op het 75e percentiel van je bezoekersdata. Dat betekent dat 75% van je paginabezoeken een "goede" score moet halen voordat Google je pagina als geslaagd beschouwt.
Hoe staan Nederlandse websites ervoor? Volgens het 2025 Web Almanac van HTTP Archive slaagt slechts 48% van alle mobiele pagina's wereldwijd voor alle drie de Core Web Vitals. LCP is de bottleneck: maar 62% van mobiele pagina's haalt een goede LCP-score. CLS scoort het beste met 81%, terwijl INP op 77% zit.
Hoe verbeter je LCP (Largest Contentful Paint)?
LCP meet hoe snel het grootste zichtbare element op je pagina verschijnt. Dat is meestal een hero-afbeelding, een grote heading of een achtergrondvideo. Van de drie metrics is LCP het moeilijkst om te verbeteren — en tegelijk het meest bepalend voor hoe snel je site aanvoelt.
De vier componenten van LCP
Elke LCP-meting bestaat uit vier fasen. Je moet weten welke fase het probleem veroorzaakt voordat je gaat optimaliseren:
- Time to First Byte (TTFB) — hoe snel reageert je server?
- Resource load delay — hoe snel wordt het LCP-element ontdekt?
- Resource load duration — hoe lang duurt het downloaden?
- Element render delay — hoe lang duurt het renderen na download?
Sites met een slechte LCP besteden gemiddeld 2,27 seconden aan TTFB alleen — dat is bijna het volledige budget van 2,5 seconden.
Concrete stappen om LCP te verbeteren
Server en hosting optimaliseren:
- Kies hosting met een TTFB onder 200 milliseconden. Shared hosting levert vaak 400-800 ms TTFB; een VPS of managed hosting halveert dat. Voor Nederlandse bezoekers maakt een server in Amsterdam of Frankfurt meetbaar verschil
- Schakel HTTP/2 of HTTP/3 in voor parallelle downloads
- Zet server-side caching aan — cached pagina's laden 2-5 keer sneller dan niet-gecachte pagina's
Afbeeldingen aanpakken:
- Converteer naar WebP of AVIF. WebP-bestanden zijn 25-34% kleiner dan vergelijkbare JPEG's; AVIF bespaart tot 50%
- Stel expliciete width- en height-attributen in op elke afbeelding
- Gebruik
loading="eager"enfetchpriority="high"op je hero-afbeelding — de afbeelding die waarschijnlijk je LCP-element is - Bied responsive afbeeldingen aan via het srcset-attribuut, zodat mobiele bezoekers geen desktop-formaat downloaden
Render-blocking resources elimineren:
- Inline je critical CSS (de CSS die nodig is voor de bovenste viewport) direct in de
<head> - Laad overige CSS asynchroon met
media="print"en eenonload-handler - Voeg
deferofasynctoe aan niet-essentieel JavaScript - Gebruik
rel="preconnect"voor domeinen van externe fonts of analytics. Dat bespaart 100-300 ms per verbinding
Hoe verbeter je INP (Interaction to Next Paint)?
INP (Interaction to Next Paint) verving in maart 2024 de oudere FID-metric. Waar FID alleen de eerste interactie mat, meet INP alle interacties gedurende het hele paginabezoek en rapporteert de slechtste score. Een traag reagerende knop halverwege de pagina telt mee.
Waarom is INP vaak slecht?
De hoofdoorzaak is JavaScript dat de main thread blokkeert. Elke klik of toetsaanslag moet wachten tot lopende JavaScript-taken klaar zijn voordat de browser de interactie kan verwerken. Bij pagina's met veel third-party scripts — analytics, chatwidgets, social media embeds — stapelen die taken zich op.
Concrete stappen om INP te verbeteren
Lange taken opsplitsen:
- Breek JavaScript-taken die langer dan 50 ms duren op in kleinere stukken. Gebruik
setTimeout(fn, 0)ofrequestIdleCallbackom de browser tussentijds interacties te laten afhandelen - Stel niet-kritiek JavaScript uit: chatwidgets, social media knoppen en analytics hoeven niet mee te laden bij het eerste paginabezoek
Third-party scripts beheren:
- Audit welke scripts je daadwerkelijk gebruikt. Elke externe tag voegt 20-100 ms toe aan de verwerkingstijd
- Laad scripts van derden asynchroon of pas lazy loading toe
- Overweeg een tag manager die scripts pas na gebruikersinteractie laadt
DOM-complexiteit verminderen:
- Houd je DOM onder de 1.500 elementen. Complexere pagina's kosten meer rendering-tijd na elke interactie
- Vermijd deeply nested elementen — meer dan 32 niveaus diep veroorzaakt meetbare vertraging
- Gebruik CSS-animaties met
transformenopacityin plaats vantop,leftofwidth— die eerste twee vermijden dure layout-herberekeningen
Hoe voorkom je CLS (Cumulative Layout Shift)?
CLS meet hoe stabiel je pagina is tijdens het laden. Denk aan die ervaring waarbij je op een knop wilt klikken, maar de pagina verschuift net op dat moment door een advertentie of afbeelding die inlaadt. Met 81% van mobiele pagina's op een goede CLS-score is dit de "makkelijkste" metric om te verbeteren — maar veel MKB-sites hebben nog steeds vermijdbare problemen.
De vijf grootste CLS-boosdoeners
- Afbeeldingen zonder afmetingen — de browser weet niet hoeveel ruimte hij moet reserveren. Stel altijd width en height in
- Webfonts die layout verschuiven — wanneer een custom font laadt en de tekst herspringt. Gebruik
font-display: swapoffont-display: optionalin je@font-face-declaratie - Dynamisch ingevoegde content — cookie-banners, nieuwsbriefbalken of advertenties die later inladen en andere elementen verschuiven
- Iframes zonder gereserveerde ruimte — YouTube-embeds of Google Maps zonder vaste hoogte
- Late CSS-wijzigingen — stylesheets die na de eerste render nog klassen toevoegen
Concrete stappen om CLS te verbeteren
- Reserveer ruimte voor alle media-elementen via CSS
aspect-ratioof expliciete afmetingen - Gebruik
font-display: optionalals je CLS-problemen door fonts hebt — het toont alleen het custom font als het snel genoeg laadt, anders blijft het systeemfont staan - Pas
size-adjustenascent-overridetoe in je@font-facezodat het fallback-font dezelfde afmetingen heeft als je custom font - Preload je belangrijkste font met
<link rel="preload" as="font" crossorigin> - Plaats cookie-banners en nieuwsbriefbanners bovenaan of onderaan met een vaste hoogte — nooit als overlay die de content verschuift
Hoeveel verschil maakt optimalisatie in de praktijk?
Om de impact concreet te maken, hier een overzicht van typische verbeteringen die we in de praktijk zien bij MKB-sites:
| Optimalisatie | Typisch voor | Typisch na | Verbetering |
|---|---|---|---|
| Shared hosting naar VPS | 650 ms TTFB | 180 ms TTFB | 72% sneller |
| JPEG naar WebP-conversie | 2,4 MB pagina | 850 KB pagina | 65% kleiner |
| Critical CSS inlinen | 3,8 sec LCP | 1,9 sec LCP | 50% sneller |
| Third-party scripts uitstellen | 380 ms INP | 120 ms INP | 68% sneller |
| Afbeeldingsafmetingen toevoegen | CLS 0,28 | CLS 0,04 | 86% stabieler |
| Font-display: optional | CLS 0,15 | CLS 0,02 | 87% stabieler |
De totale impact is cumulatief. Een site die al deze stappen doorvoert, gaat typisch van een PageSpeed-score rond de 35-50 naar 85-95.
Hoe optimaliseer je Core Web Vitals in WordPress?
WordPress drijft 43% van alle websites wereldwijd, maar scoort gemiddeld tussen de 40 en 75 op PageSpeed zonder optimalisatie. De combinatie van thema's, page builders en plugins maakt WordPress kwetsbaar voor trage laadtijden. In ons artikel over WordPress websites bespreken we het platform uitgebreid — hier focussen we op de performance-kant.
Essentieel: caching-plugin installeren
Een goede caching-plugin is het verschil tussen een WordPress-site die in 3+ seconden laadt en eentje die onder de seconde blijft. De populairste opties:
- WP Rocket (€59/jaar) — de meest complete optie met lazy loading, critical CSS-generatie, en database-opschoning ingebouwd
- LiteSpeed Cache (gratis) — werkt op serverniveau bij LiteSpeed-hosting, effectiever dan PHP-based caching
- WP Super Cache (gratis) — eenvoudig en bewezen. Recente tests tonen 35% betere prestaties dan complexere alternatieven
Plugin-audit: minder is sneller
Elke actieve plugin voegt JavaScript en CSS toe die geladen moet worden. Drie vuistregels:
- Houd het onder 15 actieve plugins — meer dan 20 is een rode vlag
- Deactiveer plugins die je niet actief gebruikt. Gedeactiveerd is niet genoeg; verwijder ze
- Vervang meerdere losse plugins door een alles-in-een-oplossing waar dat kan
Beeldoptimalisatie automatiseren
Gebruik ShortPixel of Smush om afbeeldingen automatisch te comprimeren en naar WebP te converteren bij upload. Dat voorkomt dat niet-technische teamleden per ongeluk een 4 MB foto uploaden die je LCP om zeep helpt.
Scoren moderne frameworks als Next.js automatisch beter?
Frameworks als Next.js, Nuxt en Astro scoren doorgaans 90-100 op PageSpeed Insights zonder extra optimalisatie. Dat komt door architectuurkeuzes die performance standaard afdwingen:
- Server Components verplaatsen rendering naar de server, waardoor de browser minder JavaScript hoeft te verwerken — direct beter voor INP
- Automatische image-optimalisatie via
next/imagegenereert responsive formaten en laadt afbeeldingen lazy - Automatische font-optimalisatie via
next/fontvoorkomt layout shifts door fonts lokaal te hosten met de juiste fallback-metrics - Static Generation serveert vooraf gegenereerde HTML, waardoor TTFB minimaal is
Dat betekent niet dat Next.js-sites geen aandacht vragen. Veelvoorkomende fouten: te veel client components (verhoogt JavaScript-bundel), ontbrekende priority-prop op de hero-afbeelding, en ongecontroleerde third-party scripts die de main thread blokkeren.
Welke hosting kies je voor de beste Core Web Vitals?
Je kunt je code en afbeeldingen optimaliseren tot op de byte, maar als je server traag reageert, is het dweilen met de kraan open. De keuze tussen shared hosting, VPS en dedicated hosting heeft meetbare impact:
| Hosting type | Typische TTFB | Prijs/maand | Geschikt voor |
|---|---|---|---|
| Shared hosting | 400 - 800 ms | €3 - €15 | Hobby-projecten, blogs |
| VPS (managed) | 100 - 250 ms | €20 - €60 | MKB-websites, webshops |
| Dedicated server | 50 - 150 ms | €80 - €200+ | High-traffic sites |
Voor de meeste MKB-sites is managed VPS-hosting de sweet spot. De TTFB daalt gemiddeld 60-70% ten opzichte van shared hosting, en je krijgt gegarandeerde resources in plaats van gedeelde capaciteit.
CDN toevoegen: Een Content Delivery Network zoals Cloudflare (gratis basisplan) cachet je statische bestanden op 200+ locaties wereldwijd. Voor Nederlandse bezoekers maakt het weinig verschil bij een Nederlandse server, maar het beschermt wel tegen traffic-pieken en voegt een beveiligingslaag toe.
Hoe meet en monitor je Core Web Vitals?
Optimaliseren zonder meten is gokken. Gebruik deze tools om je voortgang te volgen:
Eenmalige meting:
- PageSpeed Insights — combineert labdata (Lighthouse) met velddata (echte bezoekers via Chrome UX Report)
- Lighthouse in Chrome DevTools (F12 > Lighthouse tab) — voor gedetailleerde diagnostiek per pagina
Continue monitoring:
- Google Search Console > Core Web Vitals-rapport — toont welke pagina's slagen en falen op basis van echte bezoekersdata
- De Chrome UX Report (CrUX) API voor geautomatiseerde tracking
Prioritering: Begin altijd bij de pagina's met het meeste verkeer. Een homepage die dagelijks 500 bezoekers ontvangt en slecht scoort, heeft meer impact dan een contactpagina met 10 bezoekers per week.
Veelgestelde vragen over Core Web Vitals
Is een PageSpeed-score van 100 nodig?
Nee. Een score van 90+ op desktop en 70-80+ op mobiel is voor de meeste MKB-sites voldoende. De relatie tussen score en ranking is niet lineair — het verschil tussen 92 en 100 is verwaarloosbaar voor je positie in Google. Focus op groene Core Web Vitals (alle drie de metrics goed) in plaats van een perfecte Lighthouse-score.
Hoe snel merk ik resultaat in Google?
Core Web Vitals worden als "tiebreaker" gebruikt bij vergelijkbare contentrelevantie. Als jouw pagina en die van een concurrent inhoudelijk gelijkwaardig zijn, wint de pagina met betere Core Web Vitals. Het effect op rankings is meetbaar maar bescheiden — verwacht geen spectaculaire stijging van positie 30 naar positie 1. De grootste winst zit in lagere bounce rates en hogere conversies door de snellere ervaring.
Moet ik lab-data of field-data gebruiken?
Beide. Lab-data (Lighthouse) is diagnostisch — het helpt je problemen te vinden en op te lossen. Field-data (Chrome UX Report) is beslissend — het laat zien hoe echte bezoekers je site ervaren, en dit is wat Google gebruikt voor rankings. Een pagina kan 95 scoren in Lighthouse maar toch slechte field-data hebben door trage mobiele netwerken.
Tellen Core Web Vitals zwaar mee voor SEO?
Core Web Vitals zijn een bevestigde maar bescheiden rankingfactor. Google's eigen documentatie noemt ze een onderdeel van het page experience-signaal. Contentrelevantie, backlinks en zoekintentie blijven zwaarder wegen. Maar bij vergelijkbare content kan het net het verschil maken — en de indirecte effecten (lager bouncepercentage, hogere conversie) zijn minstens zo waardevol.
Volgende stappen
Core Web Vitals verbeteren is geen eenmalig project. Elke plugin-update, elk nieuw script en elke grote afbeelding kan je scores beinvloeden. Neem performance-monitoring op in je websiteonderhoud — een maandelijkse PageSpeed-check kost vijf minuten en voorkomt dat scores ongemerkt wegzakken.
Wil je weten hoe je website er nu voorstaat? Vraag een vrijblijvende performance-analyse aan en we meten je Core Web Vitals, identificeren de grootste bottlenecks en geven een concreet actieplan.
Opgesteld met AI-tools en gecontroleerd door het redactieteam van CleverTech — tech-leads met ervaring in AI, procesautomatisering en IT-consulting.