Core Web Vitals: snelheid gemeten bij je echte klanten, opgelost in je platform
Een groene Lighthouse-score zegt weinig over wat je klanten ervaren op een drie jaar oude telefoon via 4G. Google beoordeelt Core Web Vitals op data van echte bezoekers, en je omzet doet dat ook. Wij meten met real user monitoring waar je shop traag is, per paginatype en per apparaat, en lossen het op in de code van Magento, Hyvä, Shopify of Laravel.
- Field data van echte bezoekers via RUM, als RUMvision Gold Partner
- Fixes in thema, templates, scripts en server, door het team dat de shop bouwt
- Voor- en nameting per paginatype, niet één gemiddelde score
Wat zijn Core Web Vitals?
Core Web Vitals zijn drie meetwaarden waarmee Google de gebruikservaring van een pagina beoordeelt. Largest Contentful Paint (LCP) meet hoe snel het grootste zichtbare element geladen is, vaak de productfoto of de hero-afbeelding. Interaction to Next Paint (INP) meet hoe snel de pagina reageert op klikken en tikken. Cumulative Layout Shift (CLS) meet hoeveel de pagina verspringt tijdens het laden.
De drempels voor een goede score: LCP binnen 2,5 seconden, INP binnen 200 milliseconden en CLS onder 0,1. Google meet dit op het 75e percentiel van echte bezoekers, via het Chrome User Experience Report (CrUX). Drie kwart van je bezoekers moet de drempel dus halen. INP verving in maart 2024 de oudere First Input Delay; veel shops die op FID goed scoorden, bleken op INP in de problemen te zitten.
Voor SEO zijn Core Web Vitals een van de signalen in het paginabeleving-deel van Google. Relevantie weegt zwaarder: een trage pagina met het beste antwoord kan nog steeds winnen. Voor conversie liggen de verhoudingen anders. Een klant die op een filter tikt en een halve seconde niets ziet gebeuren, haakt af, ongeacht je positie in Google.
De drie Core Web Vitals, en wat ze bij een webshop meestal veroorzaakt
Drempels volgens Google, gemeten op het 75e percentiel van echte bezoekers. Per meetwaarde de oorzaken die we bij webshops het vaakst tegenkomen.
| Meetwaarde | Goed | Slecht | Typische oorzaak in een webshop |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2,5 s | > 4 s | Trage serverrespons, te grote of lazy geladen hero- en productafbeelding, render-blocking CSS |
| INP (Interaction to Next Paint) | ≤ 200 ms | > 500 ms | Zware JavaScript-bundels, tracking- en chatscripts, filters en swatches die de main thread blokkeren |
| CLS (Cumulative Layout Shift) | ≤ 0,1 | > 0,25 | Afbeeldingen zonder afmetingen, cookiebanners en promobalken die inschuiven, webfonts die verspringen |
| TTFB (diagnostisch, geen Core Web Vital) | ≤ 0,8 s | > 1,8 s | Geen full page cache, ongecachete blokken, trage hosting of database |
Plan een vrijblijvend gesprek over je project
Een half uur via video met de mensen die het werk ook echt doen. Kies hieronder een moment dat jou past.
- Direct met het vaste team, geen tussenlagen
- Concrete feedback op je huidige situatie of plannen
- Eerlijk advies, ook als het antwoord "niet doen" is
- Indicatie van kosten en tijdlijn
Plan een gratis Tech Check
Vrijblijvend jouw uitdagingen bespreken
Of bel direct: 0591-239 299
Field data versus lab data: waarom Lighthouse niet de waarheid is
Lighthouse en PageSpeed Insights draaien een test in een gesimuleerde omgeving: één apparaat, één verbinding, één pagina, een lege cache. Dat heet lab data. Het is handig om een fix te testen, maar het is niet wat Google voor de beoordeling gebruikt. Google gebruikt field data: metingen bij echte Chrome-gebruikers, verzameld in CrUX over een periode van 28 dagen.
Die twee wijken vaak sterk af. Een productpagina kan in Lighthouse 95 scoren en in het veld toch een slechte LCP hebben, omdat echte bezoekers via advertenties binnenkomen met parameters die de cache omzeilen. Of omdat een groot deel van je verkeer op oudere Android-toestellen zit. INP kan Lighthouse zelfs helemaal niet meten, omdat er in een labtest niemand klikt. Lighthouse toont Total Blocking Time als benadering.
CrUX heeft ook beperkingen. Het geeft alleen data voor pagina's en sites met voldoende Chrome-verkeer, het loopt 28 dagen achter en het vertelt je niet waarom iets traag is. Na een fix duurt het weken voordat je het effect in Search Console ziet. Voor een webshop die wil weten welke template, welk script of welk apparaat het probleem veroorzaakt, is dat te grof en te traag.
Real user monitoring: meten waar het probleem echt zit
Real user monitoring (RUM) meet Core Web Vitals bij al je bezoekers, in je eigen shop, vanaf de dag dat je het installeert. Per paginatype, per apparaat, per land, per verkeersbron. Zo zie je niet alleen dat je LCP op mobiel te hoog is, maar ook dat het vooral op categoriepagina's speelt, bij bezoekers uit Google Shopping, en dat het element dat te laat laadt de eerste productafbeelding is.
Wij werken daarvoor met RUMvision, en zijn RUMvision Gold Partner. Het voordeel in de praktijk: we meten de nulsituatie, voeren een fix door en zien binnen dagen in plaats van weken of het effect heeft. Voor INP zien we welke interactie traag is en welk script de main thread op dat moment bezet hield. Dat maakt het verschil tussen gokken en repareren.
RUM is ook het eerlijkste antwoord op de vraag wat snelheid oplevert. Je kunt laadtijd naast conversie leggen voor je eigen bezoekers, in plaats van te leunen op studies over andere shops in andere markten.
Hyvä: de grootste stap voor Magento-shops
Bij Magento met het standaard Luma-thema zit het probleem vaak niet in losse fouten, maar in de frontend-architectuur zelf.
Waarom Luma traag is
Luma laadt RequireJS, Knockout en jQuery met een lange keten aan modules. Op mobiel betekent dat veel JavaScript voordat de pagina interactief is, en dat drukt vooral op INP.
Lees verder →Wat Hyvä anders doet
Hyvä vervangt de frontend door Alpine.js en Tailwind CSS. Veel minder JavaScript, kleinere CSS en eenvoudiger templates. De backend, data en URL's blijven gelijk.
Lees verder →Wanneer Hyvä niet genoeg is
Een snelle frontend op een trage server levert nog steeds een slechte LCP op. Full page cache, Varnish en goede hosting blijven nodig. En tien trackingscripts maken ook Hyvä traag.
Lees verder →Van meting naar besluit
We meten eerst waar je huidige shop verliest. Soms is een Hyvä-migratie de beste investering, soms haal je de grootste winst met cache, afbeeldingen en scripts.
Lees verder →Fixes per platform
Dezelfde meetwaarden, andere oorzaken. Dit zijn de ingrepen die we per platform het vaakst doen.
Bij Shopify heb je geen controle over de server en de checkout, maar wel over het thema en de apps. In de praktijk zit daar ook het grootste deel van het probleem. Elke app die een script in je thema injecteert, kost op elke pagina tijd, ook op pagina's waar de app niets doet.
Bij Magento heb je juist alle controle, en dus ook alle verantwoordelijkheid. Hosting, PHP-versie, Varnish, Redis, OpenSearch, indexers: elke laag kan de TTFB opdrijven. Daar hoort hosting bij die op Magento is ingericht.
| Platform | LCP | INP | CLS |
|---|---|---|---|
| Magento 2 (Luma) | Varnish full page cache, ongecachete blokken opsporen, LCP-afbeelding met fetchpriority en zonder lazy loading | JavaScript-bundling herzien, ongebruikte modules uitschakelen, of de stap naar Hyvä | Vaste afmetingen voor afbeeldingen en sliders, minicart en banners met gereserveerde ruimte |
| Magento 2 (Hyvä) | Server en cache op orde, responsieve afbeeldingen in WebP of AVIF, kritieke CSS | Alpine-componenten licht houden, third-party scripts uitstellen | Fonts met font-display en fallback-metrics, vaste hoogtes voor dynamische blokken |
| Shopify | Juiste breedtes via de image_url-filter, hero niet lazy laden, minder apps in de head | App-scripts opruimen, zware thema-JavaScript vervangen door lichtere componenten | Appblokken en reviewwidgets met gereserveerde ruimte, aankondigingsbalk zonder verspringen |
| Laravel en maatwerk | Server-side rendering met caching, CDN voor assets en afbeeldingen | Alleen JavaScript laden waar het nodig is, interacties opsplitsen in kleinere taken | Layout vooraf vastleggen, skeletons met de juiste afmetingen |
Third-party scripts: de stille snelheidskiller
Tag managers, advertentiepixels, chatwidgets, reviewwidgets, heatmaps, A/B-testtools, cookiebanners. Elk script heeft een eigenaar die het belangrijk vindt, en samen kosten ze vaak meer dan het hele thema. Vooral INP lijdt eronder: een script dat tijdens een klik de main thread bezet, maakt elke interactie trager.
We maken per script de afweging zichtbaar: wat kost het in laadtijd en interactie, en wat levert het op. Daarna kiezen we per script: houden, later laden, alleen op specifieke pagina's laden, server-side afhandelen of verwijderen. Dat is geen technische beslissing alleen; het gaat ook over welke marketingdata je echt gebruikt.
Een A/B-testtool die de pagina verbergt tot de test geladen is, is een bekend voorbeeld. Je meet een conversie-effect van een variant, terwijl de tool zelf de conversie op alle varianten drukt.
Snelheid en omzet: de rekenstap voor je eigen shop
Er circuleren veel percentages over wat een seconde snelheid aan conversie oplevert. Ze komen uit andere markten, andere jaren en andere shops. Voor een investeringsbesluit heb je er weinig aan. Wat je wel kunt doen: je eigen bezoekers meten.
Met RUM-data leg je laadtijd en interactiesnelheid naast conversie, per paginatype. Converteren bezoekers met een snelle LCP op categoriepagina's beter dan bezoekers met een trage? Dan weet je wat een verbetering op dat template ongeveer waard is. Vermenigvuldig het verschil met het aantal sessies en je gemiddelde orderwaarde, en je hebt een onderbouwde bovengrens voor wat de fix mag kosten.
Dat voorkomt twee bekende fouten. Weken besteden aan een pagina die nauwelijks verkeer krijgt. En een Lighthouse-score van 100 najagen op de homepage, terwijl je omzet op productpagina's via mobiel binnenkomt.
Checklist: Core Web Vitals per paginatype
Webshops hebben een handvol templates die bijna al het verkeer dragen. Daar begint het werk.
Homepage en landingspagina's
- Hero-afbeelding als LCP-element: niet lazy, met fetchpriority=high en juiste afmetingen
- Geen carrousel die de eerste afbeelding pas na JavaScript toont
- Cookiebanner die geen layout shift veroorzaakt
Categoriepagina's
- Eerste rij productafbeeldingen direct geladen, de rest lazy
- Filters en sorteren zonder lange blokkades van de main thread
- Swatches en quick-view pas laden bij interactie
- Paginering of load more zonder verspringen van de lijst
Productpagina's
- Hoofdafbeelding als LCP, galerij pas daarna
- Variantkeuze en prijsupdate snel genoeg voor een goede INP
- Reviews, aanbevelingen en recent bekeken buiten het kritieke pad
- Vaste ruimte voor levertijd, voorraad en USP's
Server en cache
- Full page cache-hitrate op belangrijke paginatypes, ook met marketingparameters in de URL
- TTFB per paginatype in field data
- Afbeeldingen via CDN in moderne formaten
- Back/forward cache niet geblokkeerd door scripts
Onze aanpak voor Core Web Vitals
Meten, prioriteren, fixen, opnieuw meten. Met het team dat je shop kent.
- 1
Nulmeting in het veld
CrUX-data uit Search Console en PageSpeed Insights, aangevuld met real user monitoring per paginatype, apparaat en verkeersbron.
- 2
Diagnose per template
Per paginatype het LCP-element, de traagste interacties en de bronnen van layout shift. Inclusief een inventaris van alle third-party scripts.
- 3
Prioriteren op impact
Welke fix raakt de meeste bezoekers op de pagina's met de meeste omzet. Geen lijst van zestig losse Lighthouse-adviezen.
- 4
Implementatie
Fixes in thema, templates, scripts, cache en server. In Magento, Hyvä, Shopify of Laravel, door de mensen die het platform dagelijks bouwen.
- 5
Verificatie met RUM
Binnen dagen zien of de fix werkt bij echte bezoekers, en niet pas na 28 dagen in Search Console.
- 6
Bewaken
Alerts op terugval na thema-updates, nieuwe apps of extra marketingscripts. Snelheid gaat geleidelijk achteruit als niemand kijkt.
Wat je opgeleverd krijgt
- Nulmeting van LCP, INP en CLS in field data, per paginatype en apparaat
- Diagnose per template: LCP-element, trage interacties en oorzaken van layout shift
- Inventaris van third-party scripts met hun impact en een advies per script
- Geprioriteerde fixlijst op basis van verkeer en omzet per paginatype
- Doorgevoerde fixes in je thema, templates, cache en serverconfiguratie
- Nameting met real user monitoring naast de nulmeting
- Advies over Hyvä of hosting waar de grootste winst structureel is
- Ingerichte bewaking op terugval na releases
Waarom Coding.nl voor Core Web Vitals
RUMvision Gold Partner
We meten bij echte bezoekers, per template en per apparaat. Daardoor weten we waar het probleem zit voordat we iets aanpassen.
Hyvä Silver Partner
Hyvä Certified en Hyvä Silver Partner. Voor Magento-shops met een trage Luma-frontend kennen we de route naar een snelle frontend van binnenuit.
Fixen, niet alleen rapporteren
Een rapport met Lighthouse-adviezen heb je zo. Wij voeren de fixes zelf door in het platform, en meten daarna of het werkte.
Snelheid tot op de server
Als Hypernode Silver Partner kijken we ook naar hosting, cache en database, niet alleen naar de frontend.
Verder lezen
- ›Core Web Vitals in 2026: wat telt voor e-commerce?
- ›Interaction to Next Paint (INP) — wat e-commerce owners moeten weten
- ›Coding.nl is RUMvision Gold Partner: waarom we meten bij echte bezoekers
- ›Third-party scripts: hoe GTM, chat widgets en tracking pixels je shop vertragen
- ›Hyvä vs Luma: de echte performance cijfers uit productie
- ›Image optimalisatie voor webshops — WebP, AVIF en lazy loading
- ›Shopify performance — 10 ingrepen die direct effect hebben
- ›Magento 2 Full Page Cache configureren: Varnish, Redis en de built-in FPC
- ›Font loading strategie voor e-commerce — FOUT vs FOIT
- ›Paginasnelheid en conversie: wat elke seconde vertraging je kost
Veelgestelde vragen
Weten waar je shop echt traag is?
Vraag een SEO-audit aan. We meten je Core Web Vitals bij echte bezoekers, per paginatype en apparaat, en laten zien welke fixes de meeste omzet raken en wat ze in je platform vragen.