Zo slaag je voor de Core Web Vitals: stap voor stap (2026)

De snelste weg om te slagen voor Core Web Vitals

Je weet dat je Core Web Vitals aandacht nodig hebben. Google Search Console kleurt rood of oranje, een klant stelt vragen, of PageSpeed Insights kwam net met slecht nieuws. Deze pagina toont de workflow die ik gebruik om sites zo snel mogelijk te laten slagen.

Met deze workflow heb ik op honderdduizenden pagina's geholpen om te slagen voor Core Web Vitals. Het werkt op WordPress, Shopify, maatwerk en elk platform daartussenin. De volgorde waarin je dingen fixt maakt uit. Pak eerst het fundament aan en werk van daaruit verder. Anders verspil je tijd aan optimalisaties die teniet worden gedaan door een dieper probleem.

Hoe het web er nu voor staat

Volgens de 2025 Web Almanac (gebaseerd op CrUX-data van juli 2025) slaagt 48% van de mobiele websites en 56% van de desktopsites voor alle drie de Core Web Vitals. Dat is een verbetering ten opzichte van 44% mobiel in 2024, maar nog steeds faalt meer dan de helft van het mobiele web.

De uitsplitsing per metric (percentage origins dat 'goed' scoort op mobiel):

Bron: 2025 Web Almanac (HTTP Archive, CrUX-data van juli 2025). RUM-data van CoreDash over gemonitorde sites laat vergelijkbare verdelingen zien.

LCP is het knelpunt. 77% slaagt voor INP en 81% voor CLS, maar slechts 62% haalt LCP. Daardoor zakt het totale slagingspercentage naar 48%. Daarom geeft de workflow hieronder eerst prioriteit aan TTFB en LCP.

Stap 1: Bepaal waar je staat

Voordat je iets aanpast: zoek eerst exact uit welke metrics falen en op welke pagina's. Sla je dit over en ga je gokken, dan verspil je tijd aan de verkeerde zaken.

Kijk in Google Search Console

Ga naar je Search Console-property en open het rapport Core Web Vitals onder "Ervaring". Dit toont:

• Hoeveel URL's als Goed, Moet worden verbeterd of Slecht zijn beoordeeld
• Welke specifieke metric faalt (LCP, INP of CLS)
• URL-groepen met hetzelfde probleem (bijvoorbeeld alle productpagina's die zakken op INP)

Search Console gebruikt echte field data van Chrome-gebruikers over een voortschrijdend venster van 28 dagen. Dit is de data die Google gebruikt voor ranking. Geeft Search Console aan dat je slaagt, dan slaag je, ongeacht wat Lighthouse zegt.

Test belangrijke pagina's in PageSpeed Insights

Test minimaal één URL van elk paginatype: je homepage, een blogpost, een productpagina en een categorie- of overzichtspagina. PageSpeed Insights geeft je zowel field data (indien beschikbaar) als lab data met gerichte diagnostics.

Kijk eerst naar het field data-gedeelte (aangeduid als "Ontdek wat je echte gebruikers ervaren"). Kleurt dat groen voor alle drie de metrics, dan slaagt die pagina. Is er geen field data beschikbaar, dan heeft de pagina te weinig verkeer voor CrUX-data. Google kan in dat geval data op origin-niveau of URL-groepsniveau gebruiken.

Stel Real User Monitoring in

Search Console en CrUX werken met een voortschrijdend venster van 28 dagen, waardoor verbeteringen pas na weken zichtbaar worden. Wil je direct zien wat het effect van je wijzigingen is, zet dan een Real User Monitoring (RUM)-oplossing op zoals CoreDash. RUM levert realtime field data voor elke pagina, elk apparaat en elk land. Zo controleer je of elke fix werkt voordat je doorgaat naar de volgende.

Stap 2: Bepaal welke metric je als eerste fixt

Falen er meerdere metrics, pak ze dan in deze volgorde aan:

TTFB is zelf geen Core Web Vital, maar elke milliseconde TTFB telt direct op bij je LCP en FCP. Een pagina met een TTFB van 800ms is al een derde van het LCP-budget van 2,5 seconden kwijt voordat de browser überhaupt begint met renderen. De drempelwaarde voor "goed" in CrUX is 800ms voor TTFB, maar sneller is altijd beter: elke milliseconde winst op TTFB werkt direct door in je paint-metrics. Lees meer in onze Time to First Byte-handleiding.

Stap 3: Fix het fundament (TTFB)

Is je Time to First Byte structureel hoger dan 400ms, begin dan hier. Dit zijn de gebruikelijke knelpunten:

• Trage hosting: stap over op kwalitatieve hosting met caching op serverniveau. Managed hosts voor WordPress (Kinsta, SiteGround, Cloudways) of de ingebouwde infrastructuur van Shopify regelen dit.
• Geen page caching: zorg dat je CMS de volledig gerenderde HTML cachet, zodat de server deze niet bij elk request opnieuw hoeft op te bouwen.
• Geen CDN: zet een CDN in (Cloudflare is gratis) om pagina's te serveren vanaf edge-locaties dicht bij bezoekers. Bekijk onze Cloudflare-configuratiehandleiding.
• Redirects: elke redirect kost een volledige round-trip. Haal overbodige redirect-chains weg.
• Trage backend: niet-geoptimaliseerde database-queries, te veel WordPress-plugins of zware server-side verwerking. Gebruik query-monitoringtools om knelpunten te vinden.

Doel: breng de TTFB voor de meeste bezoekers onder 200ms. Minimaal onder 400ms.

Stap 4: Fix LCP

Zodra de TTFB goed zit, fix je Largest Contentful Paint. De aanpak:

Vind je LCP-element

Haal de falende pagina door PageSpeed Insights en zoek het "Largest Contentful Paint-element" op onder Diagnostische gegevens. Meestal is dit een hero image, uitgelichte afbeelding of een groot tekstblok.

Als LCP een afbeelding is

1. Zorg dat de browser de afbeelding direct in de HTML vindt. De afbeeldings-URL moet in een gewone <img src="">-tag staan, niet verstopt achter een data-src-attribuut of ingeladen via JavaScript. Kan de HTML-parser van de browser de URL niet zien, dan kan het downloaden niet vroeg beginnen. Volgens de 2025 Web Almanac verbergt 7% van de websites de LCP-afbeelding nog altijd op deze manier.
2. Voeg fetchpriority="high" toe aan de <img>-tag. Dit geeft de browser de instructie om deze afbeelding voorrang te geven boven andere bronnen die om bandbreedte strijden. Zonder dit attribuut downloadt de browser vaak eerst stylesheets, scripts en andere afbeeldingen. In een test van Google op Google Flights zorgde deze ene wijziging al voor een LCP-verbetering van 2,6s naar 1,9s.
3. Verwijder loading="lazy". Lazy loading vertraagt het request totdat de afbeelding dicht bij de viewport is. Bij een LCP-afbeelding telt die vertraging direct door in je LCP-score.
4. Optimaliseer de bestandsgrootte. Converteer naar WebP of AVIF. Serveer via srcset en sizes de juiste afmetingen voor de viewport.
5. Staat de afbeelding niet in de HTML (CSS-achtergrondafbeelding, ingeladen via JavaScript of op een pagina waar je de <img>-tag niet kunt aanpassen): voeg een preload toe. Gebruik <link rel="preload" as="image" href="..." fetchpriority="high"> in de <head>. Een preload dwingt de browser af om de afbeelding vroegtijdig te ontdekken, zelfs als deze niet direct in de HTML-broncode staat. Voor afbeeldingen die al in een normale <img>-tag staan is een preload meestal overbodig; de parser vindt ze dan al.

Als LCP tekst is

1. Houd render-blocking CSS klein. Laad alleen de CSS die de pagina echt gebruikt, zodat de browser de tekst kan renderen zonder te wachten op een grote stylesheet.
2. Optimaliseer hoe fonts laden. Host je fonts zelf en preload het primaire font-bestand om de tijd tot de tekst rendert te verkorten.
3. Minimaliseer render-blocking JavaScript. Defer niet-kritieke JavaScript, zodat het de HTML-parser niet blokkeert.

Stap 5: Fix INP

Slaagt LCP, pak dan Interaction to Next Paint aan. INP faalt als JavaScript de main thread blokkeert tijdens interacties van de gebruiker.

Vind het knelpunt

Open Chrome DevTools, ga naar het Performance-paneel en maak een opname terwijl je interactie hebt met de pagina. Zoek naar long tasks (taken van meer dan 50ms, zichtbaar als rode balken). Dit blokkeert de browser om te reageren op je klikken.

Dit blokkeert meestal de main thread:

• Third-party scripts (analytics, advertenties, chatwidgets, marketingtags) die strijden om tijd op de main thread
• Grote JavaScript-bundles van frameworks, pagebuilders of plugins die tijdens het laden van de pagina uitvoeren
• Niet-geoptimaliseerde event handlers die te veel werk verzetten in reactie op een klik of toetsaanslag

De prioriteit bij het fixen

1. Stel third-party scripts uit. Laad scripts voor chat, analytics, social en marketing pas in na de eerste gebruikersinteractie, niet tijdens het laden van de pagina.
2. Defer niet-kritieke first-party JavaScript. Gebruik defer of async voor scripts die niet uitgevoerd hoeven te worden voordat de pagina interactief is.
3. Knip long tasks op. Bevat je eigen code functies die langer duren dan 50ms, yield dan naar de main thread. Zo kan de browser tussen blokken werk door gebruikersinput verwerken. De moderne methode is scheduler.yield() (ondersteund in Chrome 129+ en Edge). Voor bredere browserondersteuning val je terug op het inpakken van taken in een setTimeout(resolve, 0) binnen een Promise:

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. Verwijder ongebruikte JavaScript. Gebruik het Coverage-tabblad in Chrome DevTools om JavaScript op te sporen dat wel laadt maar nooit uitvoert. Verwijder dit of laad het voorwaardelijk in.

Bekijk onze INP-optimalisatiehandleiding voor de complete strategie.

Stap 6: Fix CLS

CLS is meestal de makkelijkste metric om te fixen. Dit zijn de meest voorkomende oorzaken en oplossingen:

Afbeeldingen zonder afmetingen

Elke <img>-tag heeft expliciete width- en height-attributen nodig. Ontbreken die, dan weet de browser niet hoeveel ruimte hij moet reserveren. De content verschuift dan zodra de afbeelding laadt. Dit is wereldwijd de belangrijkste oorzaak van CLS. Zie onze CLS-handleiding.

Het wisselen van webfonts

Laadt een webfont in en vervangt het de fallback, dan kan de tekst verspringen en omliggende elementen verschuiven. De fix: host fonts zelf, gebruik font-display: optional of gebruik de CSS-eigenschap size-adjust om de afmetingen van het fallback-font af te stemmen op het webfont.

Dynamisch ingevoegde content

Cookiebanners, notificatiebalken, advertentieblokken en pop-ups die na het laden de content naar beneden drukken. De fix: reserveer ruimte voor deze elementen met CSS min-height of laad ze op een manier die de omliggende layout niet beïnvloedt (bijvoorbeeld als overlay in plaats van inline injectie).

Stap 7: Verifieer met field data

Heb je de fixes doorgevoerd, controleer dan of ze echt werken in de praktijk, en niet alleen in Lighthouse.

• Directe verificatie: gebruik CoreDash of een andere RUM-tool voor realtime field data. Wijzigingen moeten binnen een paar uur zichtbaar zijn.
• CrUX-verificatie: het Chrome User Experience Report kijkt naar de afgelopen 28 dagen en wordt dagelijks bijgewerkt. Elke dag telt bezoeken van na de fix mee en vallen oudere bezoeken af. Het duurt dus tot 28 dagen voordat het venster alleen nog bezoeken bevat van na de fix.
• Search Console-verificatie: het Core Web Vitals-rapport in Search Console werkt op basis van CrUX. Zodra CrUX verbetering laat zien, volgt Search Console vanzelf.

Die vertraging maakt RUM essentieel. Zonder RUM zie je pas na weken of je wijzigingen echt gewerkt hebben.

Stap 8: Monitoren en onderhouden

Performance zakt altijd weer in. Elke nieuwe plugin, thema-update of third-party script kan je werk tenietdoen. Richt daarom continue monitoring in:

• Controleer wekelijks het Core Web Vitals-rapport in Search Console
• Gebruik CoreDash voor continue realtime monitoring met alerts
• Test opnieuw in PageSpeed Insights na elke ingrijpende wijziging (nieuwe plugin, thema-update, nieuw third-party script)
• Loop elk kwartaal alle third-party scripts na. Verwijder alles wat niet meer nodig is.

Gebruik onze Ultimate Core Web Vitals Checklist voor een compleet overzicht van alle checkpoints.

Quick wins: de fixes met de meeste impact

Heb je maar tijd voor vijf zaken, kies dan voor deze fixes met de meeste impact op elk platform:

Deze bandbreedtes zijn gebaseerd op RUM-data van CoreDash uit diverse optimalisatietrajecten. Je werkelijke winst hangt af van je startpunt, je hosting en je verkeersprofiel. Sites die beginnen met hele slechte scores (LCP boven 5 seconden) zien vaak nog grotere verbeteringen. Zit je al dicht bij de drempelwaarde, dan is de absolute winst misschien kleiner, maar het betekent wel het verschil tussen zakken en slagen.

De data uit de 2025 Web Almanac bevestigt deze prioriteiten. Homepages slagen voor de Core Web Vitals bij 45% op mobiel, tegenover 56% voor dieper liggende pagina's. Dit verschil ontstaat doordat homepages vaak meer dynamische content, grotere hero images en meer third-party scripts bevatten. Faalt je homepage terwijl interne pagina's wel slagen, richt je LCP- en INP-optimalisaties dan specifiek op het homepage-template.