Core Web Vitals verbeteren op WordPress is geen kwestie van één plugin installeren en klaar. Het is een combinatie van serverconfiguratie, thema-keuzes, afbeelding-optimalisatie en JavaScript-discipline. In deze gids loop je stap voor stap door de drie meetwaarden, LCP, INP en CLS, en leer je welke ingrepen écht impact maken.
De reden dat dit belangrijk is: Google gebruikt Core Web Vitals als ranking-signaal, en slechte scores betekenen naast SEO-verlies ook hogere bouncerates en minder conversie. Goed nieuws: met gerichte optimalisaties kun je op WordPress vrijwel altijd naar het groene gebied.
Wat zijn Core Web Vitals precies?
Core Web Vitals bestaan uit drie meetwaarden die samen de gebruikerservaring scoren:
- LCP (Largest Contentful Paint): hoe snel het grootste zichtbare element geladen is. Goed: onder 2,5 seconden.
- INP (Interaction to Next Paint): hoe snel de pagina reageert op interacties. Goed: onder 200 ms.
- CLS (Cumulative Layout Shift): hoeveel de pagina tijdens het laden verspringt. Goed: onder 0,1.
Google gebruikt field-data uit het Chrome User Experience Report (CrUX), niet de lab-scores die je in Lighthouse ziet. Je moet dus optimaliseren voor échte gebruikers, niet voor de test.
Lab-data vs field-data
Lab-data krijg je uit tools als PageSpeed Insights en Lighthouse: gecontroleerde metingen op één moment. Field-data komt van echte Chrome-gebruikers over een periode van 28 dagen. De discrepantie is vaak groot, een site die in Lighthouse 95 scoort kan in het veld onder de 50 zitten door trage 4G-verbindingen of oude telefoons.
Meer over het meten van performance lees je in WordPress performance bottlenecks herkennen.
LCP verbeteren: de grote winst zit hier
LCP is bij WordPress-sites bijna altijd het grootste probleem. Het element dat LCP triggert is meestal een hero-afbeelding, een header-video of een grote heading met webfont. Aanpakken doe je op meerdere lagen.
Server-response versnellen (TTFB)
LCP begint bij TTFB (Time To First Byte). Zit die boven de 600 ms, dan ben je de strijd al half verloren voor je eerste pixel verschijnt.
Concrete acties:
- Zet full page caching aan. Een ongecachte WordPress-pagina doet minimaal 30–100 database-queries. Met caching serveer je HTML in milliseconden. Zie Full page caching: NGINX vs plugins.
- Gebruik Redis voor object caching. Dat versnelt ongecachte requests (admin, ingelogde users, AJAX). Lees Object caching met Redis in WordPress.
- Activeer OPcache en preloading. PHP hoeft dan niet elke request opnieuw te compileren.
- Tune PHP-FPM. Te weinig workers betekent wachtende requests. Zie PHP-FPM tuning voor WordPress.
Hero-afbeelding optimaliseren
Het LCP-element is in 70% van de WordPress-sites een afbeelding. Die moet snel binnenkomen:
- Gebruik moderne formaten: WebP of AVIF in plaats van JPG/PNG.
- Zet
fetchpriority="high"op de hero-afbeelding. Dit is vaak de snelste winst van allemaal. - Laad de hero-afbeelding NIET lazy. Alleen afbeeldingen onder de fold krijgen
loading="lazy". - Preload kritische afbeeldingen met
<link rel="preload" as="image">in de header.
Meer diepgang vind je in Lazy loading correct implementeren en Image optimization pipelines.
Webfonts onder controle
Fonts blokkeren je LCP als ze niet goed geladen worden:
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
Gebruik altijd font-display: swap of font-display: optional zodat tekst direct zichtbaar is met een fallback. Host fonts zelf, Google Fonts via een externe CDN kost je extra DNS- en TLS-latency.
Render-blocking resources elimineren
WordPress-thema's laden vaak tientallen CSS- en JS-bestanden in de <head>. Elke render-blocking request vertraagt LCP:
- Combineer en minify CSS/JS met een plugin als FlyingPress, WP Rocket of Perfmatics.
- Inline kritieke CSS voor de above-the-fold content.
- Defer niet-kritieke JavaScript met
deferofasync. - Verwijder ongebruikte plugins, elke plugin kan CSS/JS in je frontend injecteren.
INP verbeteren: JavaScript is de boosdoener
INP vervangt sinds maart 2024 FID als officiële meetwaarde. Het meet elke interactie (klik, tap, toetsaanslag) en rapporteert de langste vertraging op de pagina.
Bij WordPress komt slechte INP bijna altijd door:
- Zware theme-frameworks (Elementor, Divi) die honderden KB's aan JavaScript laden.
- Third-party scripts zoals chatwidgets, tracking, A/B-testing.
- jQuery-plugins die lange tasks uitvoeren op de main thread.
Long tasks opsporen en opsplitsen
Open Chrome DevTools → Performance → Record een interactie. Je ziet long tasks als rode balken in de timeline. Alles boven de 50 ms blokkeert interactiviteit.
Oplossingen:
- Stel third-party scripts uit tot na user-interactie (bijv. chatwidgets pas laden bij scroll).
- Gebruik
requestIdleCallbackvoor niet-kritieke logica. - Splits grote event handlers met
setTimeout(fn, 0)ofscheduler.yield(). - Verwijder jQuery waar mogelijk, veel moderne thema's hebben het niet meer nodig.
Admin-ajax vermijden op frontend
Gebruikt je thema of plugin admin-ajax.php voor frontend-requests? Dan boot je WordPress bij elke interactie. Verplaats dit naar de REST API met eigen endpoints. Lees Admin-ajax.php: de verborgen performance drain en REST API performance in WordPress.
CLS verbeteren: voorkom layout shifts
CLS is vaak het eenvoudigst op te lossen, maar wordt frequent over het hoofd gezien. De regels zijn simpel:
Altijd afmetingen op media
<img src="hero.webp" width="1200" height="600" alt="...">
Zonder width en height reserveert de browser geen ruimte en springt de layout zodra de afbeelding geladen wordt. Dit geldt ook voor iframes, embeds (YouTube, Twitter) en advertenties.
Reserveer ruimte voor dynamische content
- Cookie-banners: toon ze als overlay, niet als element dat content naar beneden duwt.
- Lazy-loaded content: gebruik een skeleton-placeholder met vaste hoogte.
- A/B-test tools: laad ze synchroon of reserveer ruimte, anders zie je een flash en een shift.
Font-swap zonder shift
Bij font-display: swap kan de fallback-font een andere breedte hebben dan je webfont, wat subtiele shifts veroorzaakt. Gebruik size-adjust, ascent-override en descent-override in je @font-face-declaratie om fallback-metrics te matchen.
Meten en monitoren
Optimaliseren zonder meten is gokken. Combineer deze tools:
- PageSpeed Insights: lab + field-data per URL.
- Google Search Console → Core Web Vitals rapport: laat zien welke URLs onderpresteren in het veld.
- Chrome DevTools → Performance Insights: zoom in op specifieke pagina's.
- Real User Monitoring (RUM): tools als Cloudflare Web Analytics of web-vitals.js geven je continue field-data.
web-vitals.js zelf loggen
Installeer het web-vitals npm-pakket en stuur metrics naar je eigen endpoint of Google Analytics 4:
import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(console.log);
onINP(console.log);
onCLS(console.log);
Zo zie je scores per template, apparaat en browser, veel specifieker dan CrUX.
Een pragmatisch stappenplan
Loop deze volgorde af voor snelle winst:
- Activeer full page caching en Redis object caching. Meetbare TTFB-winst binnen een dag.
- Optimaliseer de hero-afbeelding: WebP,
fetchpriority="high", juiste afmetingen. - Audit je plugins. Deactiveer alles wat je niet écht gebruikt.
- Elimineer render-blocking CSS/JS via een performance-plugin of handmatig.
- Self-host fonts en voeg
preloadtoe voor je primaire font. - Voeg
width/heighttoe aan alle afbeeldingen en iframes. - Stel third-party scripts uit tot na interactie waar mogelijk.
- Meet met RUM om te zien wat écht impact heeft in het veld.
Na deze basis loont het om dieper te kijken naar database optimalisatie, CDN-integratie met Cloudflare en eventueel HTTP/3.
Veelgemaakte fouten
- Alleen op Lighthouse-score sturen. Lab-data vertelt niet wat gebruikers ervaren.
- Te veel caching-plugins stapelen. Kies er één en tune die goed.
- Lazy loading op de hero-afbeelding. Dat verpest je LCP direct.
- Pagebuilders vertrouwen. Elementor en Divi laden veel ongebruikte CSS/JS per pagina, vraag je af of een lightweight thema niet beter past.
- Geen mobiele test. Google meet mobiel, jij moet dus ook mobiel testen.
Veelgestelde vragen
Wat zijn Core Web Vitals?
Core Web Vitals zijn drie meetwaarden van Google die de gebruikerservaring van een website meten: LCP (laadtijd), INP (interactiviteit) en CLS (visuele stabiliteit). Ze zijn onderdeel van de ranking-signalen voor Google Search.
Wat is een goede LCP-score voor WordPress?
Een goede LCP (Largest Contentful Paint) is onder de 2,5 seconden. Tussen 2,5 en 4 seconden vraagt om verbetering, boven 4 seconden is slecht. Meet altijd op mobiel, want dat is wat Google meeneemt.
Waarom is INP belangrijker dan FID?
Per maart 2024 heeft Google FID vervangen door INP (Interaction to Next Paint). INP meet de vertraging van alle interacties op een pagina, niet alleen de eerste. Dat geeft een realistischer beeld van de responsiviteit.
Kan ik Core Web Vitals verbeteren zonder developer?
Voor basis-optimalisaties zoals afbeelding-compressie, caching-plugins en een goed thema kom je een eind. Voor diepere verbeteringen zoals server-tuning, render-blocking JavaScript en custom fixes heb je technische kennis of een developer nodig.
Hoe lang duurt het voordat wijzigingen zichtbaar zijn?
In de lab-data (PageSpeed Insights, Lighthouse) zie je wijzigingen direct. De field-data van Google (CrUX) heeft 28 dagen rollend nodig voordat nieuwe scores volledig doorwerken in de rapportage.