Core Web Vitals Verbeteren: Praktische Gids

Scoort je website onder de 70 in Google PageSpeed Insights? Dan laat je waarschijnlijk klanten liggen.

Google bundelde casestudies waarin betere Core Web Vitals samengingen met betere bedrijfsresultaten. Vodafone verbeterde zijn 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. Of je nu een bestaande site optimaliseert of een webapplicatie op maat laat bouwen met performance als ontwerpeis.

Geen vaag advies over "performance verbeteren", maar meetbare stappen die je score binnen dagen omhoog trekken.

In onze gids over maatwerk software behandelen we het volledige traject van scope tot livegang, en in web-app laten maken de keuzes die de snelheid van een applicatie vooraf bepalen. Dit artikel focust op het technische fundament dat voor elke webapplicatie geldt: de drie metrics 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 meten elk een ander aspect van je paginaprestaties.

Google schrijft zelf dat Core Web Vitals worden gebruikt door zijn rankingsystemen. Relevantie gaat wel voor: Google toont altijd de meest relevante content, ook als de gebruikservaring daar tegenvalt.

De drie metrics en hun drempelwaarden#

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 websites ervoor? Volgens het 2025 Web Almanac van HTTP Archive slaagt slechts 48% van alle mobiele websites wereldwijd voor alle drie de Core Web Vitals, tegen 56% op desktop. 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.

Prioriteitsmatrix: welke maatregel eerst?#

Niet elke optimalisatie levert evenveel op, en niet elke fix kost evenveel tijd. Deze matrix rangschikt de tien meest effectieve maatregelen op impact en moeite — werk van boven naar beneden:

De eerste zes maatregelen zijn quick wins: elk uit te voeren binnen een uur, samen goed voor het grootste deel van de scorewinst op een gemiddelde MKB-site. Maatregel 7 tot en met 10 vragen meer werk of budget, maar zijn nodig als je field-data na de quick wins nog steeds oranje of rood is.

Hieronder vind je per metric de uitwerking, inclusief code die je direct kunt overnemen.

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:

1. Time to First Byte (TTFB) — hoe snel reageert je server?
2. Resource load delay — hoe snel wordt het LCP-element ontdekt?
3. Resource load duration — hoe lang duurt het downloaden?
4. Element render delay — hoe lang duurt het renderen na download?

Bij minstens de helft van de sites met een slechte LCP is de TTFB op het 75e percentiel al 2,27 seconden — dat is bijna het volledige budget van 2,5 seconden.

Concrete stappen om LCP te verbeteren#

Server en hosting optimaliseren:

• Houd je TTFB op of onder 0,8 seconde, de grens die web.dev goed noemt. Voor Nederlandse bezoekers scheelt een server in Amsterdam of Frankfurt reistijd
• Schakel HTTP/2 of HTTP/3 in voor parallelle downloads
• Zet server-side caching aan, zodat de server een pagina niet bij elk bezoek opnieuw hoeft op te bouwen

Afbeeldingen aanpakken:

• Converteer naar WebP of AVIF. Lossy WebP-bestanden zijn 25-34% kleiner dan vergelijkbare JPEG's; AVIF haalt in sommige tests meer dan 50% besparing
• Stel expliciete width- en height-attributen in op elke afbeelding
• Gebruik loading="eager" en fetchpriority="high" op je hero-afbeelding — de afbeelding die waarschijnlijk je LCP-element is. Lazy-load je LCP-afbeelding nooit
• Bied responsive afbeeldingen aan via het srcset-attribuut, zodat mobiele bezoekers geen desktop-formaat downloaden

Zo ziet een correct gemarkeerde hero-afbeelding eruit:

<!-- Hero-afbeelding: op de meeste pagina's het LCP-element -->
<img
  src="/images/hero.webp"
  alt="Beschrijving van de afbeelding"
  width="1200"
  height="600"
  fetchpriority="high"
  decoding="async"
/>

Wordt je hero-afbeelding via CSS (background-image) of client-side JavaScript geladen? Dan ontdekt de browser hem pas laat. Voeg een preload toe aan de <head>:

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high" />

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 een onload-handler
• Voeg defer of async toe aan niet-essentieel JavaScript
• Gebruik rel="preconnect" voor domeinen van externe fonts of analytics, zodat de browser de verbinding alvast opzet

Hoe verbeter je INP (Interaction to Next Paint)?#

INP (Interaction to Next Paint) is sinds 12 maart 2024 de Core Web Vital voor reactiesnelheid, als opvolger van FID. Het meet over het hele paginabezoek hoe lang het duurt van een klik, tik of toetsaanslag tot het scherm reageert.

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, zodat de browser tussentijds interacties kan afhandelen
• Anno 2026 is scheduler.yield() daarvoor de aanbevolen methode in Chromium-browsers; gebruik feature-detectie met een setTimeout-fallback voor browsers die het nog niet ondersteunen
• Stel niet-kritiek JavaScript uit: chatwidgets, social media knoppen en analytics hoeven niet mee te laden bij het eerste paginabezoek

Zo splits je een lange taak op zonder de volgorde van je code te breken:

async function verwerkBestellingen(bestellingen) {
  for (const bestelling of bestellingen) {
    verwerkBestelling(bestelling)

    // Geef na elk item de main thread terug aan de browser,
    // zodat klikken en toetsaanslagen direct verwerkt worden
    if ('scheduler' in window && 'yield' in window.scheduler) {
      await window.scheduler.yield()
    } else {
      await new Promise((resolve) => setTimeout(resolve, 0))
    }
  }
}

Third-party scripts beheren:

• Audit welke scripts je daadwerkelijk gebruikt. Elke externe tag kost verwerkingstijd op de main thread
• Laad scripts van derden asynchroon of pas lazy loading toe
• Overweeg een tag manager die scripts pas na gebruikersinteractie laadt

Een chatwidget die pas laadt bij de eerste interactie houdt de main thread vrij tijdens het laden:

// Laad de chatwidget pas zodra de bezoeker iets aanraakt of typt
function laadChatWidget() {
  const script = document.createElement('script')
  script.src = 'https://widget.voorbeeld-chat.nl/loader.js'
  script.async = true
  document.head.appendChild(script)
}

window.addEventListener('pointerdown', laadChatWidget, { once: true })

DOM-complexiteit verminderen:

• Houd je DOM klein: Lighthouse waarschuwt vanaf zo'n 800 elementen in de body en meldt een fout boven zo'n 1.400. Complexere pagina's kosten meer rendering-tijd na elke interactie
• Vermijd diep geneste elementen
• Gebruik CSS-animaties met transform en opacity in plaats van top, left of width — 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#

1. Afbeeldingen zonder afmetingen — de browser weet niet hoeveel ruimte hij moet reserveren. Stel altijd width en height in
2. Webfonts die layout verschuiven — wanneer een custom font laadt en de tekst herspringt. Gebruik font-display: swap of font-display: optional in je @font-face-declaratie
3. Dynamisch ingevoegde content — cookie-banners, nieuwsbriefbalken of advertenties die later inladen en andere elementen verschuiven
4. Iframes zonder gereserveerde ruimte — YouTube-embeds of Google Maps zonder vaste hoogte
5. 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-ratio of expliciete afmetingen
• Gebruik font-display: optional als je CLS-problemen door fonts hebt — het toont alleen het custom font als het snel genoeg laadt, anders blijft het systeemfont staan
• Pas size-adjust en ascent-override toe in je @font-face zodat 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

De belangrijkste fix in code: geef elke afbeelding width- en height-attributen, zodat de browser de ruimte reserveert vóórdat de afbeelding binnenkomt. Met twee regels CSS blijft de afbeelding toch responsive:

<img src="/images/team.webp" alt="Beschrijving" width="800" height="533" loading="lazy" decoding="async" />

img {
  max-width: 100%;
  height: auto; /* browser berekent de hoogte uit de width/height-verhouding */
}

Voor fonts combineer je font-display: swap met een fallback-font dat qua afmetingen is afgestemd op je webfont — dan is de wissel vrijwel onzichtbaar:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap; /* toon direct tekst in het fallback-font */
}

/* Fallback met dezelfde afmetingen als het webfont — voorkomt verspringen bij de wissel.
   Bereken de exacte percentages voor jouw font met een fallback-generator. */
@font-face {
  font-family: 'Inter-fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
}

body {
  font-family: 'Inter', 'Inter-fallback', sans-serif;
}

Hoeveel verschil maakt optimalisatie in de praktijk?#

Op een van onze eigen pagina's vervingen we in september 2026 84 iconen die als client-component in de browser werden opgebouwd door SVG's die de server direct meestuurt. We maten vóór en na met Lighthouse in PageSpeed Insights (mobiel, mediaan van drie runs, 17 september 2026):

Dit zijn labcijfers. TBT is een labmetric en geen Core Web Vital; web.dev noemt hem een redelijke lab-proxy voor INP, maar geen vervanging.

De labruis op TBT is zo'n 100 ms per run, daarom nemen we de mediaan van drie runs. Minder hydratiewerk in de browser verlaagde hier vooral de blokkeertijd; de LCP bleef gelijk.

Hoe optimaliseer je Core Web Vitals in WordPress?#

WordPress draait volgens W3Techs op 39,6% van alle websites wereldwijd (oktober 2026).

De combinatie van thema's, page builders en plugins maakt WordPress kwetsbaar voor trage laadtijden. Hier focussen we op de performance-kant.

Essentieel: caching-plugin installeren#

Een goede caching-plugin zorgt dat WordPress niet bij elk bezoek opnieuw PHP en databasequery's draait. De populairste opties:

• WP Rocket (betaald) — 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

Plugin-audit: minder is sneller#

Elke actieve plugin voegt JavaScript en CSS toe die geladen moet worden. Drie vuistregels:

1. Houd het onder 15 actieve plugins — meer dan 20 is een rode vlag
2. Deactiveer plugins die je niet actief gebruikt. Gedeactiveerd is niet genoeg; verwijder ze
3. Vervang meerdere losse plugins door een alles-in-een-oplossing of een maatwerk-plugin 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 hebben een voorsprong 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/image genereert responsive formaten en laadt afbeeldingen lazy
• Automatische font-optimalisatie via next/font voorkomt 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), geen loading="eager" of fetchPriority="high" op de hero-afbeelding (de oude priority-prop is sinds Next.js 16 verouderd), 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.

Voor de meeste MKB-sites is managed VPS-hosting de sweet spot: je krijgt gegarandeerde resources in plaats van gedeelde capaciteit. Meet je TTFB vóór en na een overstap, zodat je ziet wat die oplevert.

CDN toevoegen: Een Content Delivery Network zoals Cloudflare (gratis basisplan) cachet je statische bestanden op servers in honderden steden 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 per apparaat (mobiel en desktop) welke URL-groepen Goed, Verbetering nodig of Slecht scoren op echte bezoekersdata; na een fix start je met Bijhouden starten een validatie van 28 dagen
• De Chrome UX Report (CrUX) API voor geautomatiseerde tracking

PageSpeed Insights baseert zijn velddata op de afgelopen 28 dagen. Een pagina slaagt voor de beoordeling als het 75e percentiel van alle drie de metrics Goed is; zijn er te weinig INP-gegevens, dan tellen alleen LCP en CLS.

Heeft een URL te weinig data, dan valt PageSpeed Insights terug op de cijfers van het hele domein (origin).

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.

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 patch- en onderhoudsroutine — 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.