Core Web Vitals: LCP, INP, CLS — de SEO-metrieken van Google uitgelegd

Core Web Vitals zijn drie metrieken die Google heeft gedefinieerd om de kwaliteit van de gebruikerservaring van een webpagina te meten. Geïntroduceerd in 2020 en geïntegreerd in het Google-rankingalgoritme in 2021 via de Page Experience-update, zijn ze inmiddels een officiële SEO-factor. Voor e-commercewinkels is het begrijpen en optimaliseren van deze drie indicatoren — LCP, INP en CLS — net zo belangrijk geworden als het werk aan content of linkbuilding.

Wat zijn Core Web Vitals?

Vóór Core Web Vitals werd de snelheid van een webpagina gemeten door technische metrieken zoals Time to First Byte (TTFB) of First Contentful Paint (FCP) — nuttige indicatoren voor ontwikkelaars, maar die niet getrouw weerspiegelden wat een gebruiker werkelijk ervaart. Google wilde deze kloof overbruggen door drie metrieken te definiëren die gericht zijn op de ervaren ervaring: hoe snel wordt de hoofdinhoud weergegeven? Reageert de pagina snel op interacties? Verplaatst de inhoud zich onverwacht?

Deze drie vragen komen precies overeen met de drie Core Web Vitals: LCP voor laadsnelheid, INP voor reactievermogen, en CLS voor visuele stabiliteit. Google verzamelt deze gegevens geaggregeerd via Chrome (het Chrome User Experience Report, of CrUX) en gebruikt ze in zijn algoritme om pagina's te belonen die een goede gebruikerservaring bieden.

LCP — Largest Contentful Paint: de weergavesnelheid van de hoofdinhoud

LCP (Largest Contentful Paint, of "weergave van het grootste inhoudselement") meet de tijd die verstrijkt tussen het begin van het laden van een pagina en het moment waarop het grootste zichtbare element volledig op het scherm is weergegeven. Dit element kan een afbeelding, een videotag, een tekstblok of andere inhoud zijn die zichtbaar is in het viewport zonder te scrollen (above the fold).

Voor e-commercewinkels wordt de LCP bijna altijd bepaald door de hoofdafbeelding van het product — de packshot-foto die een groot deel van het scherm inneemt boven op de productpagina. Deze afbeelding is doorgaans de zwaarste op de pagina en duurt daardoor het langst om te laden. Dat is waarom LCP-optimalisatie in de e-commerce-context prioritair de levering van afbeeldingen betreft.

De voornaamste oorzaken van een slechte LCP in e-commercewinkels zijn: te zware productafbeeldingen (niet-geoptimaliseerde JPEG), trage hosting met een hoge TTFB, het ontbreken van CDN waardoor geografische latentie ontstaat, en lazy loading dat ten onrechte wordt toegepast op de hoofdafbeelding. Deze laatste fout komt vaak voor: het attribuut loading="lazy" mag nooit worden toegepast op de above-the-fold-afbeelding, omdat het precies de browser verhindert snel het element te laden dat Google gebruikt om de LCP te berekenen.

INP — Interaction to Next Paint: de reactiesnelheid van de pagina

INP (Interaction to Next Paint) heeft in maart 2024 FID (First Input Delay) vervangen als officiële Core Web Vital. Waar FID alleen de responsvertraging bij de eerste interactie mat, meet INP de latentie van alle gebruikersinteracties tijdens de volledige levensduur van de pagina — klikken, tikken op mobiel, toetsenbordinvoer — en neemt de waarde op het 98e percentiel.

Concreet meet INP de tijd tussen het moment dat de gebruiker interageert (bijvoorbeeld klikt op de knop "In winkelwagen") en het moment dat de browser visueel reageert op die interactie. Als jouw JavaScript zwaar is en de hoofdthread van de browser monopoliseert, is de INP hoog: de pagina lijkt "bevroren" of traag te reageren.

Voor e-commercewinkels zijn de voornaamste oorzaken van een slechte INP: overmatige JavaScript van derden (chatwidgets, analytics-trackers, scripts van prijsvergelijkers), te zware event-handlers, en omvangrijke UI-bibliotheken die synchroon worden geladen. INP-optimalisatie vereist het auditeren en verminderen van niet-essentieel JavaScript, en het uitstellen van het laden van scripts van derden tot na gebruikersinteractie.

CLS — Cumulative Layout Shift: de visuele stabiliteit van de pagina

CLS (Cumulative Layout Shift, of "cumulatieve verschuiving van de opmaak") meet in hoeverre elementen op de pagina onverwacht verschuiven tijdens het laden. Telkens wanneer een zichtbaar element verschuift — tekst die verspringt door een afbeelding die laadt zonder gereserveerde afmetingen, een reclamebanner die wordt ingevoegd en de inhoud naar beneden duwt — stijgt de CLS.

Een hoge CLS is bijzonder frustrerend op mobiel: de gebruiker staat op het punt op een link te klikken, en op het moment dat zijn vinger het scherm raakt, laadt een afbeelding en verschuift de inhoud. Hij klikt op een andere link — soms op "In winkelwagen" terwijl hij de beschrijving wilde lezen. Dit is een verslechterde ervaring die Google bestraft.

De voornaamste oorzaak van een hoge CLS in e-commercewinkels is het ontbreken van expliciete afmetingen op afbeeldingen (width- en height-attributen in de HTML). Wanneer de browser de HTML parseert en een img-tag zonder afmetingen tegenkomt, kan hij niet de benodigde ruimte in de opmaak reserveren. Wanneer de afbeelding laadt en zijn werkelijke afmetingen onthult, wordt de opmaak herberekend en verschuift alles. De oplossing is eenvoudig: altijd width en height opgeven op img-tags, of de CSS-eigenschap aspect-ratio gebruiken.

Hoe Core Web Vitals de Google-ranking beïnvloeden

Google gebruikt Core Web Vitals als rankingsignaal sinds juni 2021. Technisch gezien maken ze deel uit van een breder signaal dat "Page Experience" wordt genoemd, dat ook mobielvriendelijkheid, HTTPS-beveiliging en het ontbreken van opdringerige interstitiële inhoud omvat. Google heeft verduidelijkt dat kwalitatieve inhoud het dominante signaal blijft, maar dat Core Web Vitals het verschil kunnen maken tussen twee pagina's van vergelijkbare kwaliteit.

In de praktijk evalueert Google Core Web Vitals via twee databronnen: velddata (field data) die anoniem worden verzameld via Chrome bij echte bezoeken van gebruikers, en laboratoriumdata (lab data) berekend door tools zoals Lighthouse in gecontroleerde omstandigheden. De velddata — geaggregeerd in het Chrome User Experience Report (CrUX) — zijn de data die in het algoritme worden gebruikt. Een pagina moet voldoende Chrome-verkeer ontvangen om in CrUX te verschijnen; pagina's met weinig verkeer worden beoordeeld op domeinniveau of root-URL-niveau.

Specifieke uitdagingen voor e-commerce

Webshops concentreren meerdere uitdagingen die de optimalisatie van Core Web Vitals bijzonder moeilijk maken. Ten eerste het volume van afbeeldingen: een winkel met 1.000 producten en 5 foto's per product moet 5.000 afbeeldingen beheren, elk te optimaliseren qua grootte, formaat en afmetingen. Vervolgens de complexiteit van de pagina's: productpagina's met galerijen, carrousels, zoommogelijkheden, beschrijvingstabbladen, widgets voor klantbeoordelingen, variantconfigurators — allemaal JavaScript-componenten die de INP kunnen verslechteren.

• Zware productafbeeldingen zonder formaatoptimalisatie (niet-geoptimaliseerde JPEG vs. WebP/AVIF)
• Carrousels en galerijen met JavaScript van derden die de hoofdthread blokkeren
• Slecht geconfigureerde lazy loading toegepast op de hero-afbeelding (verslechtert de LCP)
• Afbeeldingen zonder expliciete width/height-attributen in de templates (verslechtert de CLS)
• Analytics- en remarketingscripts die synchroon worden geladen (verslechtert de INP)
• Trage gedeelde hosting met hoge TTFB die alle Core Web Vitals beïnvloedt

Hoe Lexiik jouw Core Web Vitals verbetert

Lexiik werkt voornamelijk op LCP en CLS — de twee Core Web Vitals die het meest direct verband houden met afbeeldingen. Voor LCP vermindert de Cloudflare CDN drastisch de levertijd van de hoofdproductafbeelding door deze te serveren vanuit een geografisch nabije node, met cache-headers van één jaar. Voor CLS garandeert Lexiik dat afbeeldingen die via CDN worden geserveerd hun originele afmetingen behouden, zodat de browser de juiste ruimte kan reserveren vóór het volledige laden.

De automatische conversie naar WebP en AVIF vermindert de afbeeldingsgrootte met 30 tot 50% zonder zichtbaar kwaliteitsverlies, wat niet alleen de LCP versnelt maar ook alle ervaren prestatiemetrieken verbetert. Op mobiele verbindingen via 4G kan het wisselen van een JPEG-afbeelding van 400 KB naar een WebP-afbeelding van 120 KB de LCP terugbrengen van 3,5 seconden naar minder dan 1,5 seconde.

Hoe controleer je jouw Core Web Vitals-scores

Meerdere tools maken het mogelijk je Core Web Vitals te meten en te bewaken. Google Search Console is het referentietool voor echte velddata (CrUX): de sectie "Paginaervaring" toont het percentage URLs van jouw site dat is geclassificeerd als "Goede ervaring", "Verbetering nodig" of "Slechte ervaring", met een uitsplitsing per metriek. Dit is het tool dat weerspiegelt wat Google werkelijk ziet.

• Google Search Console (search.google.com/search-console): echte velddata, per URL of groep URLs
• PageSpeed Insights (pagespeed.web.dev): velddata + laboratoriumdata voor een specifieke URL
• Google Lighthouse (geïntegreerd in Chrome DevTools): alleen laboratoriumdata, nuttig voor ontwikkeling
• Chrome DevTools > Performance-tabblad: gedetailleerde analyse van rendergebeurtenissen en interacties
• web.dev/measure: Google-tool voor een snelle online analyse