Core Web Vitals voor webshops: LCP, INP en CLS uitgelegd

Wat LCP, INP en CLS meten, de drempels bij het 75e percentiel, labdata versus velddata en de gangbare oplossingen voor Shopify- en WooCommerce-webshops.

FixReports-redactie13 min. leestijd

Core Web Vitals zijn drie meetwaarden van Google die beschrijven hoe echte bezoekers een pagina ervaren: Largest Contentful Paint (LCP) voor het laden, Interaction to Next Paint (INP) voor de reactiesnelheid en Cumulative Layout Shift (CLS) voor de visuele stabiliteit. Een pagina slaagt als minstens 75% van de bezoeken in het bereik “goed” valt: LCP binnen 2,5 seconden, INP binnen 200 milliseconden en CLS van 0,1 of minder, apart gemeten voor mobiel en desktop. Bij webshops zijn slechte scores meestal terug te voeren op grote of lazy geladen hero- en productafbeeldingen, scripts van apps en tracking, webfonts, en banners of reviewwidgets die de content omlaag duwen nadat de pagina al zichtbaar is.

De belangrijkste punten

Wat zijn de drempelwaarden van de Core Web Vitals?

Een pagina voldoet aan de Core Web Vitals als het 75e percentiel van de paginaladingen voor alle drie de meetwaarden in het goede bereik valt.

MeetwaardeWat ze meetGoedVerbetering nodigSlecht
LCPTijd tot de grootste afbeelding, video of tekstblok in de viewport wordt weergegeven2,5 s of minderMeer dan 2,5 s tot en met 4,0 sMeer dan 4,0 s
INPTijd van een klik, tik of toetsaanslag tot het volgende frame wordt getekend200 ms of minderMeer dan 200 ms tot en met 500 msMeer dan 500 ms
CLSHoeveel zichtbare content onverwacht verschuift0,1 of minderMeer dan 0,1 tot en met 0,25Meer dan 0,25

De drempelwaarden komen uit de handleidingen van web.dev over LCP (opent in een nieuw tabblad), INP (opent in een nieuw tabblad) en CLS (opent in een nieuw tabblad), stand oktober 2026.

Het 75e percentiel betekent dat het resultaat de meeste bezoekers weerspiegelt, niet alleen de snelste, en Google meet mobiel en desktop apart (opent in een nieuw tabblad). PageSpeed Insights laat een pagina slagen als alle drie de meetwaarden goed zijn; zijn er niet genoeg INP-gegevens, dan beoordeelt het alleen LCP en CLS (documentatie van PageSpeed Insights (opent in een nieuw tabblad)). Volgens Google veranderen stabiele Core Web Vitals niet vaker dan één keer per jaar.

In een webshop is het LCP-element vaak de herobanner of de hoofdafbeelding van het product. Daarom is de manier waarop je afbeeldingen laadt zo belangrijk.

Waarom verving INP in maart 2024 FID?

INP verving FID omdat FID alleen de eerste interactie mat, en daarvan maar een deel van de vertraging, terwijl INP naar de interacties tijdens het hele bezoek kijkt.

Google kondigde in mei 2023 aan dat INP een Core Web Vital zou worden, en de overstap ging in op 12 maart 2024 (opent in een nieuw tabblad). FID rapporteerde alleen de eerste interactie, en daarvan alleen de invoervertraging, niet de tijd die nodig was om event handlers uit te voeren of het resultaat te tekenen. INP volgt klikken, tikken en toetsaanslagen tijdens het hele bezoek en rapporteert de langste, met uitzondering van uitschieters; scrollen en hoveren tellen niet mee. Wie de API’s van CrUX en PageSpeed Insights gebruikte, had tot 9 september 2024 de tijd om over te stappen (web.dev (opent in een nieuw tabblad)).

Elke interactie bestaat uit drie delen: invoervertraging (wachten op drukke scripts), verwerkingstijd (de handlers uitvoeren) en presentatievertraging (het volgende frame tekenen) (web.dev (opent in een nieuw tabblad)).

In een webshop zijn dat interacties met de variantkiezer, de knoppen voor het aantal, de knop “In winkelwagen”, de winkelwagenlade, filters en menu’s. Een pagina kon voor FID slagen dankzij een snelle eerste tik en toch traag aanvoelen als iemand later de filters opende.

Wat is het verschil tussen labdata en velddata?

Labdata komt uit één test onder vaste omstandigheden, terwijl velddata over langere tijd bij echte bezoekers wordt verzameld. Google raadt aan velddata te gebruiken om te bepalen wat je eerst aanpakt (web.dev (opent in een nieuw tabblad)).

LabdataVelddata
BronEén gesimuleerde paginalading (Lighthouse, Chrome DevTools, het labgedeelte van PageSpeed Insights)Echte bezoekers met Chrome (Chrome UX Report), of je eigen real user monitoring
OmstandighedenVast apparaat en vast netwerk. De standaard mobiele test van Lighthouse (opent in een nieuw tabblad) gebruikt “Slow 4G” (150 ms round trip, 1,6 Mbps download) en een 4x vertraagde CPUDe apparaten, netwerken en locaties die je bezoekers toevallig hebben
INPNiet gemeten bij een gewone paginalading. Total Blocking Time (TBT) is een grove benaderingGemeten aan echte interacties
Het meest geschikt voorDebuggen en een wijziging controleren vóór de releaseWeten wat bezoekers werkelijk krijgen

TBT telt per taak op de main thread het deel boven 50 ms bij elkaar op; web.dev adviseert minder dan 200 ms op gemiddelde mobiele hardware, maar zegt dat TBT geen vervanging is voor INP (web.dev (opent in een nieuw tabblad)).

Drie details van het Chrome UX Report (CrUX) zijn belangrijk voor webshops:

  • Het is een voortschrijdend gemiddelde over 28 dagen (opent in een nieuw tabblad) dat dagelijks wordt bijgewerkt.
  • Het omvat Chrome op desktop en Android, voor gebruikers die aan de rapportagevoorwaarden van Chrome voldoen. Chrome op iOS valt erbuiten, dus een webshop met vooral iPhone-klanten ziet velddata van maar een deel van zijn publiek (methodologie (opent in een nieuw tabblad)).
  • Pagina’s en origins verschijnen alleen als ze openbaar vindbaar en populair genoeg zijn, dus een webshop met weinig verkeer heeft misschien alleen gegevens op origin-niveau, of helemaal geen.

Het webprestatiedashboard (opent in een nieuw tabblad) van Shopify rapporteert ook LCP, INP en CLS van echte gebruikers bij het 75e percentiel, maar over 30 dagen in plaats van 28. Reken dus op enige verschillen met CrUX.

Wat vertraagt LCP op webshoppagina’s?

LCP is in webshops meestal traag omdat de hoofdafbeelding te zwaar is, te laat wordt gevonden of bewust wordt uitgesteld door lazy loading of een animatie.

  • De LCP-afbeelding lazy laden. Volgens web.dev moet je dat nooit doen (web.dev (opent in een nieuw tabblad)). Uit een analyse van WordPress-pagina’s bleek dat sites met native lazy loading een tragere LCP bij het 75e percentiel hadden, en wie afbeeldingen boven de vouw niet lazy liet laden, was die achteruitgang kwijt (web.dev (opent in een nieuw tabblad)).
  • Een afbeelding die laat wordt gevonden. Een hero die als CSS-background-image is ingesteld of door een sliderscript wordt ingevoegd, staat niet in de HTML die de browser als eerste doorzoekt. Shopify raadt CSS-achtergronden voor herocontent en fade-in-effecten op de LCP-afbeelding af (Shopify (opent in een nieuw tabblad)).
  • Lage prioriteit. Afbeeldingen laden met lage prioriteit tot de lay-out klaar is, dus Shopify adviseert fetchpriority="high" op de LCP-afbeelding (Shopify (opent in een nieuw tabblad)). web.dev merkt op dat het nut afneemt als je het op meer dan een of twee afbeeldingen zet (web.dev (opent in een nieuw tabblad)).
  • Render-blocking CSS en scripts. Grote stylesheets en synchrone scripts in de <head> vertragen de weergave, zelfs als de afbeelding al binnen is (web.dev (opent in een nieuw tabblad)).
  • Bestandsgrootte en lettertypen. Gebruik moderne formaten, srcset en sizes, en een CDN. Gebruik voor webfonts een font-display-waarde anders dan auto of block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Waardoor is INP traag op webshoppagina’s?

Een trage INP in een webshop betekent meestal te veel JavaScript op de main thread, voor een groot deel afkomstig van apps, trackingtags en themafuncties, waardoor tikken moeten wachten.

Tikt een klant op “In winkelwagen” terwijl scripts voor reviews, chat en statistieken nog draaien, dan moet die tik wachten. Een variantkiezer die het hele productformulier opnieuw rendert, voegt verwerkingstijd toe. Enorme megamenu’s en collectierasters met veel kleurstalen voegen presentatievertraging toe.

web.dev raadt aan lange taken op te splitsen en de main thread vrij te geven, eerst het scherm bij te werken en de rest uit te stellen, en de DOM kleiner te houden (web.dev (opent in een nieuw tabblad)). Shopify voegt stappen toe die specifiek voor webshops gelden: controleer elke app, elke pixel en elk themascript, stel uit wat niet essentieel is, laad functies pas bij interactie, en zet anti-flicker-snippets voor A/B-tests uit als er geen test loopt (Shopify (opent in een nieuw tabblad)).

Wat veroorzaakt lay-outverschuivingen op product- en collectiepagina’s?

Lay-outverschuivingen in webshops komen vooral door content die na de eerste weergave verschijnt of van grootte verandert: afbeeldingen zonder afmetingen, aankondigings- en cookiebalken, reviewwidgets, app-blokken en het wisselen van lettertypen.

web.dev noemt als veelvoorkomende oorzaken media met onbekende afmetingen, content die boven bestaande content wordt toegevoegd, widgets van derden die zelf hun grootte aanpassen, en webfonts die in grootte afwijken van hun fallback-lettertype (web.dev (opent in een nieuw tabblad)). In webshops gaat het dan om een balk voor gratis verzending die bovenaan wordt ingevoegd, sterrenbeoordelingen die na de titel laden, informatie over betalen in termijnen onder de prijs, en carrousels met aanbevelingen. Shopify merkt op dat ook pop-upcontent verschuivingen kan veroorzaken (Shopify (opent in een nieuw tabblad)).

Verschuivingen binnen 500 ms na een invoer van de gebruiker tellen niet mee, maar verschuivingen tijdens het scrollen wel, en labtools missen die vaak (web.dev (opent in een nieuw tabblad)). Geef afbeeldingen een width en height of een CSS-aspect-ratio, reserveer ruimte voor widgets, toon banners als overlay, beperk verschuivingen door het wisselen van lettertypen met size-adjust, en animeer met transform in plaats van top of left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Hoe verbeter je de Core Web Vitals in Shopify?

In Shopify haal je de meeste winst door de eerste afbeelding direct en met hoge prioriteit te laden, scripts van apps te schrappen en het resultaat te controleren in de webprestatierapporten van je beheercentrum.

Controleer de gegevens in je beheercentrum

Een samenvatting staat op de pagina Online Store > Themes, en volledige rapporten over LCP, INP en CLS vind je onder Analytics > Reports. De gegevens kunnen tot 36 uur vertraagd zijn, en de privémodus moet uit staan (Shopify Help Center (opent in een nieuw tabblad)).

Bepaal in Liquid hoe afbeeldingen laden

Het filter image_tag laadt afbeeldingen in secties verder op de pagina lazy, tenzij je preload instelt (referentie van image_tag (opent in een nieuw tabblad)): eager voor de secties 1 tot en met 3, lazy vanaf sectie 4. Omdat section.index in de thema-editor nil is, test je met > 3 in plaats van <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

In productrasters adviseert Shopify alleen de eerste paar kaarten eager te laden (bijvoorbeeld forloop.index <= 4) (Shopify (opent in een nieuw tabblad)). Gebruik preload: true spaarzaam; Shopify raadt aan alleen een of twee bronnen vooraf te laden die laat worden gevonden.

Verwijder wat apps achterlaten

Zet ongebruikte app-embeds uit onder Online Store > Edit theme > App embeds (Shopify Help Center (opent in een nieuw tabblad)). Als je een app verwijdert, verdwijnen ook de app-blokken, maar apps die themabestanden rechtstreeks hebben aangepast, kunnen “spookcode” achterlaten die volgens Shopify problemen met kwaliteit en prestaties kan veroorzaken (Shopify (opent in een nieuw tabblad)). Shopify zegt ook dat scripttags vanaf 1 maart 2027 niet meer worden uitgevoerd. Voor lettertypen raadt Shopify zijn eigen CDN of systeemlettertypen aan in plaats van externe lettertypediensten (Shopify (opent in een nieuw tabblad)).

Hoe verbeter je de Core Web Vitals in WooCommerce?

Zorg er in WooCommerce voor dat plug-ins de prioritering van afbeeldingen door WordPress niet overschrijven, cache alles behalve de winkelwagen en de checkout, en verwijder scripts die zonder noodzaak overal laden.

  • Behoud de afbeeldingsafhandeling van de core. Sinds WordPress 6.3 (uitgebracht op 8 augustus 2023) voegt de core fetchpriority="high" toe aan de waarschijnlijke LCP-afbeelding (standaard minstens 50.000 vierkante pixels) en slaat lazy loading over voor de eerste drie contentafbeeldingen (Make WordPress Core (opent in een nieuw tabblad)). Voegt een optimalisatieplug-in zijn eigen lazy loading toe, controleer dan of die de hero en de hoofdafbeelding van het product uitsluit.
  • Cache pagina’s, geen winkelwagens. De handleiding van WooCommerce adviseert paginacaching op de server of via een plug-in en een CDN, maar de winkelwagen- en checkoutpagina’s niet te cachen (ontwikkelaarsdocumentatie van WooCommerce (opent in een nieuw tabblad)).
  • Controleer cart fragments. Sinds WooCommerce 7.8 laadt het script voor cart fragments alleen waar een Cart-widget staat, maar sommige thema’s hebben die widget vast in de code opgenomen. Het Mini-Cart-blok gebruikt geen cart fragments (ontwikkelaarsblog van WooCommerce (opent in een nieuw tabblad)).
  • Spoor zware plug-ins op. WooCommerce raadt Query Monitor aan om trage plug-ins te vinden, en om niet-essentiële JavaScript uit te stellen.

Toont je lay-out meer dan drie afbeeldingen boven de vouw, dan kun je de drempel van WordPress verhogen:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Hoe lang duurt het voordat verbeteringen zichtbaar worden?

Labtests laten het effect van een verbetering meteen zien, maar velddata heeft tot ongeveer vier weken nodig om het volledig te weerspiegelen, omdat CrUX een gemiddelde over de voorgaande 28 dagen neemt.

Voer de labtest vóór en na een wijziging meerdere keren uit, omdat losse metingen variëren, en volg daarna de veldcijfers in PageSpeed Insights, het Core Web Vitals-rapport van Search Console of de rapporten van Shopify. Een gratis scan geeft je in ongeveer een minuut een eerste indruk. Het Snelheidsrapport voert een mobiele labtest uit met beperkte snelheid (slow 4G, 4x vertraagde CPU) en voegt velddata uit het Chrome UX Report toe, inclusief INP als Google genoeg gegevens over je webshop heeft.

Veelgestelde vragen

Hebben Core Web Vitals invloed op de posities in Google?

Volgens Google worden Core Web Vitals gebruikt door zijn rankingsystemen, maar garanderen goede scores geen toppositie en toont Google nog steeds de meest relevante content, ook als de paginabeleving slecht is (Google Search Central (opent in een nieuw tabblad)).

Waarom toont PageSpeed Insights geen velddata voor mijn webshop?

CrUX bevat alleen pagina’s en origins die openbaar vindbaar zijn en genoeg geschikte bezoekers met Chrome hebben. Een webshop met weinig verkeer heeft misschien alleen gegevens op origin-niveau, of helemaal geen. Vertrouw in dat geval op labtests en de eigen rapporten van je platform.

Heb ik een Lighthouse-score van 90 of hoger nodig om te slagen?

Nee. De prestatiescore van Lighthouse is een labresultaat, terwijl de beoordeling van de Core Web Vitals velddata bij het 75e percentiel gebruikt. Een pagina kan dus slagen met een bescheiden Lighthouse-score en zakken met een hoge.

Moet ik alle productafbeeldingen lazy laden?

Nee. Laad afbeeldingen onder het eerste scherm lazy, maar laad de hero en de hoofdafbeelding van het product direct (eager), met fetchpriority="high" op een van beide.

Waarom zijn mijn mobiele resultaten slechter dan op desktop?

Google meet mobiel en desktop apart, en telefoons hebben tragere processors en netwerken. De mobiele test van Lighthouse simuleert dat met een Slow 4G-profiel en een 4x vertraagde CPU.

Bronnen

Alle handleidingen