Wat is LCP (Largest Contentful Paint)?
LCP meet hoe lang het duurt voordat het grootste zichtbare element op je pagina geladen is. Dat is meestal de hero-afbeelding, een grote kop of een video. Concreet is het het moment waarop de bezoeker denkt: de pagina is er.
Goede score: onder 2,5 seconden
Matig: 2,5 tot 4 seconden
Slecht: boven 4 seconden
Google stelde vast dat de kans op een bounce stijgt met 32% als de laadtijd van 1 naar 3 seconden gaat. Bij 5 seconden is de kans op vertrek 90%.
Wat het beinvloedt: afbeeldingsformaat en -grootte, server-responstijd, render-blocking CSS en JavaScript, font loading. Zo kan een hero-afbeelding van 3MB die niet geoptimaliseerd is, kan je LCP alleen al boven de 4 seconden tillen.
Wat is INP (Interaction to Next Paint)?
Goede score: onder 200 milliseconden
Matig: 200 tot 500 milliseconden
Slecht: boven 500 milliseconden
Ter vergelijking: een knipperbeweging duurt 100 tot 400 milliseconden. Als je pagina trager reageert dan een oogknip voelt de interactie traag aan, zelfs als de gebruiker het niet bewust registreert.
De meest voorkomende boosdoener: Google Tag Manager met meerdere tags die allemaal op elke pagina laden. Of een chat-widget die bij elke klik de hele DOM herberekent.
Praktisch tip: laad third-party scripts pas na interactie of via requestIdleCallback. Je bezoeker merkt geen verschil, maar je INP-score verbetert direct.
Wat is CLS (Cumulative Layout Shift)?
CLS meet hoeveel de pagina-layout verschuift terwijl de pagina laadt. Je kent het: je wilt op een knop klikken en net op dat moment schuift er een afbeelding of advertentie in beeld. Je klikt verkeerd. Dat is een layout shift.
Goede score: onder 0,1
Matig: 0,1 tot 0,25
Slecht: boven 0,25
Wat het beinvloedt: afbeeldingen zonder width/height attributen, web fonts die de tekst laten verspringen (FOUT: Flash of Unstyled Text), dynamisch ingevoegde content (banners, cookie notices), advertenties die ruimte innemen na het laden.
Meest voorkomende fix: geef elke afbeelding en video een width en height attribuut. De browser reserveert dan de ruimte voordat het element geladen is. Gebruik font-display: swap met correcte fallback-fonts die qua grootte overeenkomen.
Hoe presteren template vs maatwerk sites?
De Lighthouse-scores (de lab-versie van Core Web Vitals) laten het verschil duidelijk zien. Template-sites scoren gemiddeld tussen 40 en 70 op performance. Maatwerk sites scoren regelmatig boven de 90.
Dat verschil komt overigens niet door betere hosting of snellere servers. Het komt namelijk door schonere code. Dus: geen onnodige plugins, geen pagebuilder-overhead, geen scripts die op elke pagina laden terwijl ze maar op een pagina nodig zijn.
Bij IntoPixel scoren onze websites structureel boven de 95 op desktop en 90 op mobiel. Dat is overigens geen toeval maar het resultaat van handgeschreven code, geoptimaliseerde afbeeldingen en selectief laden van scripts.
Hoe meet je je eigen Core Web Vitals?
pagespeed.web.dev geeft je zowel lab-data (Lighthouse-simulatie) als velddata (echte gebruikers). De velddata is het meest relevant omdat Google die gebruikt voor ranking.
2. Google Search Console
Onder Core Web Vitals zie je welke pagina's goed, matig of slecht scoren. Dit is gebaseerd op echte gebruikersdata uit Chrome (CrUX-rapport).
3. Chrome DevTools
Voor developers: de Performance tab toont LCP, INP en CLS in real-time. Ideaal voor het debuggen van specifieke problemen.
Lab-data (Lighthouse) simuleert een langzaam mobiel apparaat op een beperkte verbinding. Je werkelijke gebruikers hebben waarschijnlijk betere apparaten en snellere verbindingen.
Velddata (CrUX) komt van echte Chrome-gebruikers. Dit is wat Google gebruikt voor ranking. Het kan zijn dat je Lighthouse-score matig is maar je velddata goed, of andersom.
Test altijd op mobiel
Immers, meer dan 60% van het webverkeer is mobiel. Google beoordeelt je site primair op de mobiele versie (mobile-first indexing). Dus een site die op desktop 95 scoort maar op mobiel 50 heeft een probleem.
Zeven manieren om je scores te verbeteren
1. Afbeeldingen optimaliseren
Allereerst: converteer naar WebP, stel correcte afmetingen in, gebruik srcset voor responsive loading. Geef altijd width en height attributen mee.
2. Fonts lokaal hosten
Verder: Google Fonts van een extern CDN laden kost een extra DNS-lookup en verbinding. Host fonts lokaal als WOFF2 met font-display: swap.
3. JavaScript defer of async laden
Daarnaast moeten scripts die niet direct nodig zijn voor de eerste weergave moeten uitgesteld geladen worden. Geen render-blocking JavaScript.
4. Critical CSS inline in de head
Concreet: de CSS voor above-the-fold content inline in de HTML plaatsen. De rest asynchroon laden.
5. Third-party scripts uitstellen
Vervolgens: analytics, chat widgets en social embeds laden via requestIdleCallback of na DOMContentLoaded.
6. Lazy loading onder de fold
Afbeeldingen en video's onder de viewport pas laden wanneer de gebruiker erheen scrollt. Eerste viewport-afbeeldingen niet lazy loaden (dat schaadt LCP).
7. Onnodige plugins verwijderen
Immers, elke plugin voegt CSS en JavaScript toe. Hoe minder plugins, hoe minder code de browser moet verwerken.
Snelheid is geen luxe. Het is de basis.
Bovendien zijn de scores openbaar en meetbaar. Je kunt ze nu checken via PageSpeed Insights. En als de scores niet goed genoeg zijn, is dat geen schande. Het is een kans.
Het resultaat: consistent 95+ op desktop en 90+ op mobiel. Niet als uitzondering, maar als standaard.
Hoe snel is
jouw website?
We meten je Core Web Vitals en laten zien
waar de verbeterkansen liggen.
