Core Web Vitals Optimalisatie
Repareer LCP, CLS en INP — maak falende Core Web Vitals tot rankingvoordelen.
Waarom Core Web Vitals in 2026 belangrijk zijn
Google's Core Web Vitals zijn sinds 2021 bevestigd rankingfactoren, maar hun gewicht is alleen maar toegenomen. In maart 2024 vervangen Google First Input Delay (FID) door Interaction to Next Paint (INP) — een strengere, meer omvattende interactiviteitsmeting waarop veel websites falen zonder dat zij dit beseffen.
De impact gaat verder dan traditionele zoeken. AI Overviews en LLM-aangedreven zoekmachines geven de voorkeur aan snel geladen pagina's. Wanneer Perplexity of ChatGPT informatie van het web haalt, worden pagina's die snel laden en schoon weergeven betrouwbaarder geïndexeerd. Langzame sites worden helemaal overgeslagen of aangehaald met lagere betrouwbaarheid.
We hebben dit uit eerste hand gezien: onze clients met Lighthouse-scores boven 90 zien aanzienlijk betere crawl-efficiëntie in Google Search Console en snellere opname in door AI gegenereerde citaten. Slechte Core Web Vitals schaden niet alleen je rankings — ze verminderen je zichtbaarheid in het gehele opkomende zoeklandschap.
De drie Core Web Vitals uitgelegd
LCP (Largest Contentful Paint)
Doelstelling: onder 2,5 seconden
LCP meet wanneer het grootste zichtbare inhoudselement klaar is met renderen — meestal je hero-afbeelding, kop of featured video-thumbnail. Dit is wat gebruikers zien als "de pagina is geladen."
Belangrijkste culprits: Niet-geoptimaliseerde hero-afbeeldingen (2MB PNG's serveren in plaats van responsieve WebP), trage serverreactietijd (TTFB boven 800ms), render-blocking CSS en fonts, lazy-loaded afbeeldingen boven de vouw (een contra-intuïtieve fout).
Op SleepDr.com hebben we LCP van 6,8 seconden naar 1,8 seconden teruggebracht, voornamelijk door een render-blocking chain te elimineren: het WordPress-thema laadde een 1,2MB niet-gecomprimeerde hero-afbeelding nadat het wachtte op drie blocking CSS-bestanden en twee Google Fonts-verzoeken.
CLS (Cumulative Layout Shift)
Doelstelling: onder 0,1
CLS meet visuele stabiliteit — hoeveel de pagina-layout onverwacht verschuift tijdens het laden. Een score van 0 betekent dat niets beweegt; een score boven 0,25 betekent dat elementen significant springen.
Belangrijkste culprits: Afbeeldingen en iframes zonder expliciete afmetingen, laat-geladen webfonts die tekstherschikking veroorzaken, dynamisch ingevoegde inhoud (advertenties, cookie-banners, nieuwsbriefpopups), CSS die na HTML-inhoud wordt geladen.
De fix is meestal eenvoudig: geef altijd width- en height-attributen op voor afbeeldingen, gebruik font-display: swap met juiste font-fallbacks, reserveer ruimte voor dynamische inhoud met CSS aspect-ratio-vakken.
INP (Interaction to Next Paint)
Doelstelling: onder 200 milliseconden
INP is de nieuwste Core Web Vital en het moeilijkst om te optimaliseren. Het meet de latentie tussen een gebruikersinteractie (klik, tik, toetsaanslag) en de volgende visuele update. In tegenstelling tot FID, dat alleen inputvertraging mat, volgt INP de gehele interactie-lifecycle inclusief verwerkingstijd en presentatievertraging.
Belangrijkste culprits: Zware JavaScript-bundels die op de main thread worden uitgevoerd, lange taken die de event loop blokkeren, third-party scripts (analytics, chatwidgets, ad networks), complexe React re-renders van gebruikersinteracties.
De meeste WordPress-sites falen INP vanwege jQuery-plugins en slecht-geoptimaliseerde theme JavaScript. Zelfs goed gebouwde React-sites kunnen falen als ze niet strategisch server components gebruiken om client-side hydration te verminderen.
Ons optimalisatieproces
1. Audit
We vertrouwen niet op één gegevensbron. Lighthouse biedt lab-data onder gecontroleerde omstandigheden. PageSpeed Insights voegt realtime Chrome User Experience Report (CrUX) data toe. WebPageTest geeft ons gedetailleerde waterfall-analyse die precies laat zien waar tijd wordt doorgebracht.
Het doel is geen generieke aanbevelingenlijst — het is het identificeren van jouw specifieke knelpunten. Een site met een score van 45 op Lighthouse kan volledig andere redenen hebben dan een ander site met een score van 45. We bepalen precies of je wordt geblokkeerd door afbeeldingen, fonts, JavaScript, serverreactie, of (meestal) een combinatie.
2. Prioriteren
Niet alle fixes leveren gelijke impact. Een hero-afbeelding die een 3 seconden LCP-vertraging veroorzaakt is het waard om eerst op te lossen voordat je een 0,01 CLS-verbetering maakt. We rangschikken optimalisaties op impact versus inspanning, wat je een duidelijk stappenplan geeft.
Soms is het eerlijke antwoord dat jouw huidige platform een performancelimit heeft. WordPress met WP Rocket, Cloudflare en geoptimaliseerde afbeeldingen kan je tot 70 op mobiel brengen — maar het PHP-executiemodel en plugin-architectuur creëren inherente beperkingen. Wanneer een client 90+ nodig heeft, zijn we duidelijk over of optimalisatie of migratie het snellere pad is.
3. Implementeren
Onze standaard toolkit voor Next.js-projecten:
- next/image: Automatische WebP/AVIF-conversie, responsieve srcsets, lazy loading voor afbeeldingen onder de vouw, priority loading voor LCP-afbeeldingen
- next/font: Lokaal font-hosting met automatisch subsetting, juiste
font-display: swap, eliminatie van Google Fonts-netwerkverzoeken - Server Components: Inhoud boven de vouw wordt op de server weergegeven met nul JavaScript hydration, wat INP drastisch verlaagt
- Dynamic imports: Code-splitting voor niet-kritieke JavaScript (analytics, chatwidgets, interactieve componenten onder de vouw)
- Edge caching via Vercel: Reactietijden onder 100ms wereldwijd met juiste ISR-configuratie
- Third-party script management: Uitstel van niet-essentiële scripts, gebruik van
next/scriptmetafterInteractiveoflazyOnloadstrategieën
4. Verifiëren
We voeren alle audits opnieuw uit na implementatie en vergelijken lab-data (Lighthouse) met field-data (CrUX). Aangezien CrUX op 28-daagse rolling basis wordt bijgewerkt, monitoren we het Core Web Vitals-rapport van Google Search Console gedurende een volledige cyclus om te bevestigen dat verbeteringen in realtime-data van gebruikers worden weerspiegeld.
Lab-scores die verbeteren terwijl field-scores gelijk blijven duidt op een test-omgevingsprobleem — meestal third-party scripts die niet in Lighthouse worden geladen maar wel voor echte gebruikers.
SleepDr case study: Lighthouse 35 → 94
SleepDr.com kwam naar ons toe met een WordPress-site met een score van 35 op Lighthouse mobiel. De site was functioneel maar traag — pagina's duurden 6+ seconden om interactief te worden, en gebruikers verdwenen voordat inhoud geladen was.
We migreerden naar Next.js 15 met Payload CMS 3, Supabase voor data en Vercel voor hosting. Hier is de exacte voor en na:
| Metriek | Voor (WordPress) | Na (Next.js 15) | Verbetering |
|---|---|---|---|
| Lighthouse Score | 35 | 94 | +169% |
| First Contentful Paint | 4,2s | 1,1s | -74% |
| Largest Contentful Paint | 6,8s | 1,8s | -74% |
| Cumulative Layout Shift | 0,28 | 0,01 | -96% |
| Total Blocking Time | 1.200ms | 50ms | -96% |
| Time to First Byte | 2,1s | 0,3s | -86% |
De TTFB-verbetering (2,1s → 0,3s) kwam door PHP-uitvoering helemaal uit te schakelen. WordPress genereert pagina's dynamisch op elk verzoek, tenzij intensief gecacht. Next.js met ISR serveert vooraf gegenereerde HTML van edge.
De TBT-verbetering (1.200ms → 50ms) kwam van het verwijderen van het WordPress-thema JavaScript-bundel, jQuery en plugin-scripts — vervangen door React Server Components die nul JavaScript voor inhoud boven de vouw leveren.
Lees de volledige technische uitsplitsing: SleepDr WordPress to Next.js Migration
Wat veroorzaakt slechte Core Web Vitals (en hoe we elk ervan oplossen)
Niet-geoptimaliseerde afbeeldingen
Probleem: Afbeeldingen zijn vaak de grootste resource op een pagina. Een 2MB PNG serveren wanneer een 150KB WebP volstaat vernietigt LCP.
Fix: Automatische formaatconversie (WebP/AVIF), responsieve srcsets zodat mobiele apparaten niet desktop-sized afbeeldingen downloaden, juiste priority hints voor afbeeldingen boven de vouw, lazy loading voor alles anders.
Render-blocking fonts
Probleem: Google Fonts-verzoeken voegen 200-500ms blokkingstijd toe. Custom fonts zonder fallbacks veroorzaken onzichtbare tekst (FOIT) of layoutverschuiving wanneer ze laden (FOUT).
Fix: Zelf-gehoste fonts met next/font, automatisch subsetting om bestandsgrootte te verminderen, font-display: swap met geschikte fallback-stacks.
JavaScript-bloat
Probleem: Elke third-party script — analytics, chatwidgets, A/B-testing, ad networks — voegt toe aan Total Blocking Time en INP. WordPress-sites laden vaak 500KB+ JavaScript voordat de pagina interactief is.
Fix: Code-splitting en dynamic imports, server components voor niet-interactieve inhoud, agressieve uitstel van niet-essentiële scripts, volledige eliminatie van ongebruikte JavaScript.
Slechte serverreactie
Probleem: TTFB boven 600ms maakt het vrijwel onmogelijk om goede LCP te bereiken. PHP-gebaseerde CMS's die op elk verzoek worden uitgevoerd, niet-geoptimaliseerde databasequery's en ver verwijderde hosting dragen allemaal bij.
Fix: Edge-caching, statische generatie waar mogelijk, ISR voor dynamische inhoud. Op HostList (25.000 bedrijfsprofielen) verlaagde het veranderen van force-dynamic naar revalidate: 3600 de TTFB drastisch door cached responses van edge te serveren in plaats van op elk verzoek de database te raken.
Layoutverschuiving van dynamische inhoud
Probleem: Cookie consent-banners, nieuwsbriefpopups, laat-geladen advertenties en afbeeldingen zonder afmetingen veroorzaken allemaal CLS-pieken.
Fix: Gereserveerde ruimte met CSS aspect-ratio, juiste afbeeldingsafmetingen, strategische plaatsing van dynamische elementen buiten de viewport, banner-animaties die inhoud niet verschuiven.
Technologie die we gebruiken
Framework: Next.js App Router met React Server Components voor minimale client-side JavaScript
Afbeelding-optimalisatie: next/image met automatische WebP/AVIF, Cloudinary voor geavanceerde transformaties indien nodig
Font-optimalisatie: next/font met automatisch subsetting en zelf-hosting
Hosting: Vercel Edge voor sub-100ms TTFB wereldwijd, met ISR voor dynamische inhoud
Database: Supabase met juiste indexering en connection pooling
Analyse: Chrome DevTools Performance-paneel, Lighthouse, PageSpeed Insights, CrUX-dashboard, WebPageTest voor waterfall-analyse, Google Search Console Core Web Vitals-rapport
Voor Deluxe Astrology (91.000 programmatische pagina's) behouden we Lighthouse-scores boven 90 site-breed met behulp van ISR met selectieve revalidatie. Pagina's worden volgens schema opnieuw gegenereerd zonder volledige rebuilds nodig, en edge-caching zorgt voor consistente TTFB ongeacht verkeerspieken.
Prijzen
Audit alleen: $1.500–$3.000
Uitgebreide analyse met Lighthouse, CrUX, PageSpeed Insights en WebPageTest. Deliverable omvat specifieke geïdentificeerde knelpunten, geprioriteerde fixlijst met geschatte impact en aanbevelingen over of optimalisatie of migratie het betere pad is.
Audit + fixes: $3.000–$8.000
Volledige audit plus implementatie van fixes in jouw huidige platform. Realistisch voor sites die met optimalisatie alleen 80+ kunnen bereiken. Inclusief 28-daagse monitoring om CrUX-verbeteringen te verifiëren.
Volledige migratie: $8.000–$25.000
Wanneer jouw platform een performancelimit heeft die optimalisatie niet kan doorbreken, is migratie naar Next.js vaak het enige pad naar 90+. CWV-optimalisatie is ingebouwd in ons Next.js-ontwikkelingsproces — we bouwen geen langzame sites en optimaliseren ze daarna.
Sommige WordPress-sites kunnen 75-80 bereiken met agressieve caching, afbeelding-optimalisatie en plugin-opschoning. Maar als je 90+ consistent nodig hebt, creëert het PHP-executiemodel en plugin-architectuur beperkingen die geen hoeveelheid WP Rocket-configuratie kan overwinnen. We zeggen je eerlijk welke situatie je bent.
Voor een compleet technisch SEO-overzicht buiten Core Web Vitals, zie onze Technical SEO Services.
De meeste bureaus kunnen je Lighthouse-score met 10-20 punten verbeteren met standaard optimalisaties. We hebben sites van 35 naar 94 gebracht, en we behouden 91.000 programmatische pagina's boven 90 op Lighthouse. Wanneer Google's Core Web Vitals-rapport een competitief voordeel wordt in plaats van een op te lossen probleem, zul je begrijpen waarom performance engineering belangrijker is dan performance-plugins.
Common questions
What is the difference between Lighthouse score and Core Web Vitals?
Lighthouse is a lab test — it simulates a page load in controlled conditions. Core Web Vitals (LCP, CLS, INP) are measured from real users via the Chrome User Experience Report (CrUX). Google uses field data, not lab data, for ranking. We optimise both, but CrUX data is what actually matters for your ranking.
Can you improve Core Web Vitals on a WordPress site?
Yes, but with a hard ceiling. WP Rocket, LiteSpeed Cache, and similar plugins can typically get a WordPress site from Lighthouse 35-50 to 60-70. Getting to 90+ on WordPress is extremely rare because jQuery, theme CSS bloat, and plugin JavaScript cannot be fully removed. We took SleepDr from WordPress Lighthouse 35 to Next.js Lighthouse 94. Sometimes migration is the only path.
How long does Core Web Vitals optimisation take?
An audit with a prioritised fix list takes 3-5 days. Implementation of fixes varies: image optimisation (1-2 days), font subsetting (1 day), JavaScript reduction (3-7 days), full migration (2-6 weeks). CrUX data updates monthly, so you will see ranking impact 30-60 days after implementation.
What Lighthouse score do I need to rank well?
Google uses field data, not Lighthouse scores directly. But lab and field data correlate strongly. Our target is Lighthouse 90+ on mobile — that typically produces Good CWV ratings (LCP < 2.5s, CLS < 0.1, INP < 200ms) in the field. We don't stop at 80.
What causes INP to fail and how do you fix it?
INP measures the delay between a user interaction (click, tap, keypress) and the browser next paint. Main causes: long JavaScript tasks blocking the main thread, synchronous third-party scripts, heavy event handlers. Fix: break long tasks into smaller chunks, use requestIdleCallback for non-critical work, lazy-load third-party scripts, use Next.js server components to move logic off the client.
Does Core Web Vitals affect SEO?
Yes. Google confirmed CWV are a ranking signal as part of Page Experience. Sites with Good CWV get a ranking boost over equivalent sites with Poor CWV. More importantly: fast sites have lower bounce rates, higher conversion rates, and more pages indexed (Google crawls fast sites more aggressively). The SleepDr migration from Lighthouse 35 to 94 correlated with a significant increase in organic impressions within 60 days.
Ready to get started?
Free consultation. No commitment. Just an honest conversation about your project.
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.