Core Web Vitals verbeteren in WordPress is een directe rankingfactor bij Google. De drie core web vitals — LCP, CLS en INP — meten wat bezoekers als frustrerend ervaren. Een slechte score op core web vitals in WordPress geeft een nadeel in de zoekresultaten, ook als je content uitstekend is. Dit artikel legt uit wat elke metric betekent en hoe je ze verbetert.
Core Web Vitals zijn drie meetpunten die Google gebruikt om de gebruikerservaring te beoordelen. Ze zijn niet willekeurig gekozen: ze meten precies wat bezoekers als frustrerend ervaren — trage laadtijd, springende lay-out en trage reactie op klikken.
| Metric | Meet | Goed | Verbetering nodig | Slecht |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Laadsnelheid zichtbare inhoud | < 2,5s | 2,5–4s | > 4s |
| CLS — Cumulative Layout Shift | Lay-outverschuiving tijdens laden | < 0,1 | 0,1–0,25 | > 0,25 |
| INP — Interaction to Next Paint | Reactiesnelheid op klikken | < 200ms | 200–500ms | > 500ms |
Waar controleer je je scores?
Via Google Search Console > Core Web Vitals rapport: hier zie je per pagina of ze “Goed”, “Verbetering nodig” of “Slecht” scoren, gebaseerd op echte bezoekersdata (Chrome-gebruikers).
Via Google PageSpeed Insights (pagespeed.web.dev): directe score per URL, inclusief specifieke aanbevelingen.
Belangrijk: Google Search Console toont data van de afgelopen 28 dagen op basis van echte gebruikers. PageSpeed Insights toont een laboratoriumtest. Beide zijn nuttig — de Search Console is doorslaggevend voor rankings.
LCP meet hoe snel het grootste zichtbare element op de pagina geladen is. Dat is bijna altijd de hero-afbeelding of de hoofdkop (H1). Een LCP onder 2,5 seconden is goed; boven 4 seconden is slecht.
De meest voorkomende oorzaken van slechte LCP:
Een grote, niet-geoptimaliseerde hero-afbeelding is de meest voorkomende oorzaak. Een JPEG van 2 MB vertraagt de LCP met meerdere seconden, zelfs bij goede hosting.
Geen caching actief betekent dat de server elke keer PHP en de database moet doorlopen voor de HTML klaar is — dit vertraagt de TTFB (Time to First Byte), wat de LCP mee vertraagt.
Render-blocking CSS of JavaScript: bestanden die de browser verplichten te wachten voor hij de pagina kan tonen.
Oplossingen voor LCP:
De hero-afbeelding converteren naar WebP en comprimeren is de snelste winst. Gebruik Imagify of Smush.
De hero-afbeelding preloaden zodat de browser hem prioritair ophaalt:
Dit kan via een caching-plugin of handmatig in het thema.
Caching activeren om de TTFB te verlagen. → WordPress caching instellen
Hosting upgraden als de TTFB structureel boven 600ms zit — dat is een serverprobleem, geen WordPress-probleem.
CLS meet de mate waarin elementen verschuiven terwijl de pagina laadt. Een hoge CLS is bijzonder frustrerend: de bezoeker wil op een knop klikken, de pagina verschuift op het laatste moment, en hij klikt op iets anders.
De meest voorkomende oorzaken van slechte CLS:
Afbeeldingen zonder width en height-attributen. Als de browser de afbeelding nog aan het laden is, weet hij niet hoeveel ruimte hij moet reserveren — de pagina verschuift zodra de afbeelding inlaadt.
Advertenties of embeds die laat inladen en ruimte innemen op een plek waar al andere content staat.
Lettertypes die wisselen: de browser toont eerst een systeemlettertype, daarna het weblettertype. Dit heet FOUT (Flash of Unstyled Text) en veroorzaakt zichtbare verschuiving.
Elementen die dynamisch worden ingevoegd bovenaan de pagina — cookie-banners, promotiebars en chatwidgets zijn klassieke boosdoeners.
Oplossingen voor CLS:
Altijd width en height instellen op afbeeldingen — de meeste goede thema’s doen dit al automatisch.
Ruimte reserveren voor advertenties en iframes met een vaste hoogte in CSS.
Lettertypes preloaden of een font-display: swap-waarde instellen in CSS zodat de overgang soepeler verloopt.
INP (Interaction to Next Paint) vervangt FID (First Input Delay) als metric sinds maart 2024. Het meet hoe snel de pagina reageert nadat een bezoeker klikt, typt of een element aanraakt — niet alleen de eerste keer, maar doorheen de hele pagina.
Een slechte INP voelt aan als een “trage” pagina: je klikt op iets en er gebeurt niets, of pas een halve seconde later.
De meest voorkomende oorzaken van slechte INP:
Zware JavaScript die de main thread blokkeert. De browser kan JavaScript maar één taak tegelijk uitvoeren — als een script lang bezig is, kan de browser niet reageren op klikken.
Te veel plugins met frontend-scripts. Elke plugin die JavaScript toevoegt vergroot de kans op een geblokkeerde main thread.
Zware externe scripts: analytics, chatbots, advertentiescripts en social media-widgets laden vaak traag en blokkeren de main thread ondertussen.
Oplossingen voor INP:
Overbodige JavaScript uitstellen: voeg defer of async toe aan script-tags zodat ze niet meer de paginalading blokkeren. WP Rocket doet dit via “Render-blocking resources verwijderen” in de instellingen.
Plugins auditen op frontend-impact: installeer Query Monitor (gratis) om te zien welke plugins het meeste JavaScript laden.
Externe scripts vertragen met de plugin Flying Scripts: laad tracking- en social media-scripts pas als de bezoeker interageert met de pagina.
| Plugin | Helpt met |
|---|---|
| WP Rocket | LCP (caching, TTFB), INP (JS defer) |
| Imagify / Smush | LCP (afbeeldingsoptimalisatie, WebP) |
| Autoptimize | INP (JS/CSS optimalisatie en defer) |
| Flying Scripts | INP (externe scripts vertragen) |
| Perfmatters | LCP + INP (script manager per pagina) |
Core Web Vitals-optimalisatie is technisch en sterk afhankelijk van het specifieke thema, de plugins en de hosting. Wij analyseren je scores, identificeren de grootste knelpunten en pakken ze aan — met voor- en nameting.
Terug naar: WordPress sneller maken (pillar) → Caching instellen voor betere LCP: WordPress caching → Afbeeldingen optimaliseren voor LCP: Afbeeldingen optimaliseren → Site traag? Directe hulp: WordPress traag →
n
📚 Lees ook: Bekijk onze complete gids over WordPress sneller maken.
Geen technische kennis nodig · Antwoord binnen de dag