Core Web Vitals en INP op Shopify: het conversieverlies dat niemand naast de omzet legt

Een PageSpeed-score die van 47 naar 82 stijgt, voelt als een overwinning. Het rapport kleurt groen, het team gaat door naar het volgende en iedereen wacht tot de posities in Google en het aantal toevoegingen aan de winkelwagen meestijgen. Meestal blijft dat uit. Het werk was niet voor niets. Alleen is het getal dat beter werd een schatting uit een testomgeving, en Google heeft nog nooit iemand op dat getal gerankt. De cijfers die je posities bepalen, en die ook bepalen of een bezoeker je product ziet voordat hij weer weg is, worden heel ergens anders gemeten.

Dat gat tussen de score die je optimaliseert en de score die omzet oplevert, is precies wat er misgaat als het over Core Web Vitals op Shopify gaat. Snelheid wordt behandeld als één ding dat je omhoog of omlaag duwt. Zo werkt het niet. Het zijn drie aparte meetwaarden, die elk een ander moment in je funnel raken, en bij de meeste Shopify-webshops gaat er maar één echt mis.

De snelheidsscore die je optimaliseert, is niet wat Google meet

Lighthouse en PageSpeed Insights geven je een labscore: één gesimuleerde paginalading op hardware van Google, onder vaste omstandigheden. Google rankt op velddata. Dat zijn de echte Core Web Vitals, verzameld bij Chrome-gebruikers op echte apparaten en echte netwerken, over een doorlopende periode van 28 dagen, in het Chrome User Experience Report. Een webshop kan een sterke labscore halen terwijl LCP, INP en CLS in het veld nog op rood staan.

Elk van de drie meet iets heel specifieks. Largest Contentful Paint (LCP) meet hoe lang het duurt tot het grootste element in beeld staat. De grens voor “goed” ligt op 2,5 seconden. Interaction to Next Paint (INP) meet hoe snel de pagina reageert als iemand tikt of klikt. Onder de 200 ms is goed, en sinds maart 2024 vervangt INP First Input Delay. Cumulative Layout Shift (CLS) meet hoeveel de lay-out verspringt tijdens het laden. Onder 0,1 is goed.

Dit is het deel dat de meeste handleidingen overslaan. Dezelfde velddata bepaalt allebei de uitkomsten waar het jou om gaat. Google rankt erop, en de data komt uit precies de momenten waarop een bezoeker besluit te blijven, te tikken of weg te gaan. Een groene labscore die niet klopt met de velddata liegt niet tegen je. Hij meet alleen een versie van de pagina die geen echte klant ooit laadt. Core Web Vitals zijn bovendien maar één factor binnen de bredere page experience-signalen van Google. Daarom verschuift een nette score op zichzelf zelden een ranking, en daarom horen ze thuis in het bredere SEO-verhaal van je Shopify-webshop in plaats van als losse knop om aan te draaien. Voordat je iets gaat repareren, is de vraag dus niet “wat is mijn score?” De vraag is “wat zegt mijn velddata per meetwaarde, en welke kost me geld?”

LCP: verlies bij elke bezoeker die nog twijfelt

Largest Contentful Paint is de tijd tot het grootste element boven de vouw helemaal in beeld staat. Bijna altijd is dat je hero-afbeelding of de hoofdfoto van het product. Onder de 2,5 seconden is goed. Op Shopify is dit de meetwaarde waarop webshops het vaakst zakken, en hij raakt de funnel op zijn zwakste plek: de bezoeker die nog niet heeft besloten of je webshop het wachten waard is.

Hier lekt betaald verkeer ongemerkt weg. Je betaalt voor de klik, het advertentieplatform levert de bezoeker af, en LCP bepaalt of die persoon een product ziet of een leeg scherm, in de seconde voordat zijn duim naar de terugknop gaat. Koud verkeer heeft geen geduld in reserve. Een terugkerende klant vergeeft je een trage pagina misschien. Iemand die tien seconden geleden op een Instagram-advertentie tikte niet, en juist dat publiek kopen de meeste groeibudgetten van Shopify-merken in.

Dat LCP op Shopify zo vaak onvoldoende scoort, komt door de opbouw van een webshop en niet door slordigheid. De infrastructuur van Shopify is standaard snel: een wereldwijd CDN, automatische conversie naar WebP, lichte basisthema’s. Een benchmark van 1.000 Shopify-webshops kwam uit op een mediane mobiele LCP van rond de 2,26 seconden, vlak onder de grens. Juist die krappe marge is het probleem. Eén extra app die render-blocking JavaScript toevoegt, één hero-afbeelding die op volle resolutie is geüpload in plaats van gecomprimeerd, en de webshop springt van groen naar rood zonder dat iemand iets aan het design heeft veranderd. De twee vaste boosdoeners zijn een LCP-afbeelding die nooit laadprioriteit heeft gekregen, en scripts die eerder laden en de weergave blokkeren.

Waar je ingrijpt bij LCP is dus beperkt en concreet. Zoek uit welk element op je drukst bezochte template echt het LCP-element is. Controleer of het gecomprimeerd en met voorrang wordt geladen in plaats van achter app-scripts in de rij te staan, en ruim op wat er eerder wordt weergegeven. Bij de meeste Shopify-webshops zit er in deze ene meetwaarde meer gemiste omzet dan in de andere twee samen. De volgende twee secties leggen uit waarom, en waar die twee wel degelijk tellen.

INP: verlies bij de bezoeker die al wil kopen

Interaction to Next Paint meet hoe snel de pagina reageert als een bezoeker echt iets doet: op “In winkelwagen” tikt, een variantkiezer opent, een menu uitklapt of een stap verder gaat in de checkout. Onder de 200 ms is goed. INP verving First Input Delay in maart 2024 en is strenger. FID mat alleen de vertraging tot de verwerking begon, terwijl INP de hele rondgang meet tot het scherm is bijgewerkt. LCP kost je bezoekers die nog moeten besluiten of ze blijven. INP kost je de bezoeker die al besloten heeft te kopen.

Daardoor weegt deze meetwaarde voor je omzet veel zwaarder dan zijn aandeel in “snelheid” doet vermoeden. Een trage LCP kost je kijkers, mensen die nooit zeker waren. Een trage INP kost je de tik op “In winkelwagen”. De bezoeker heeft elke eerdere twijfel overwonnen, wil kopen en grijpt naar de knop, en precies op het moment dat er geld van eigenaar zou wisselen, hapert de webshop. Een duurdere plek in de funnel voor vertraging bestaat niet. Toch kijkt algemeen snelheidsadvies hier zelden, omdat het probleem niet opvalt als je alleen je hero-afbeelding doorlicht.

Het mechanisme hangt samen met hoe Shopify-webshops groeien. INP wordt slechter als de main thread op het moment van de interactie bezig is met JavaScript, en op de productpagina stapelen scripts van derden zich het snelst op: reviewwidgets, upsell-apps, chat, trackingpixels, logica voor varianten. Elk daarvan is op zichzelf verdedigbaar. Samen duwen ze de reactie op een tik op een middenklasse-telefoon makkelijk ruim over de 200 ms, en zo’n telefoon heeft het grootste deel van je mobiele bezoekers in de hand.

Waar je ingrijpt is de app-stack op je templates met veel interactie, niet de homepage. Breng in kaart wat er op de productpagina (PDP) en in de checkout wordt uitgevoerd. Zie elk script dat bij een tik afgaat als iets dat rechtstreeks ten koste gaat van de bezoekers die het dichtst bij een aankoop zitten. INP loopt op Shopify op om dezelfde reden dat webshops groeien: meer apps, meer scripts, meer gewicht op het moment dat het meest telt.

CLS: een verlies dat je waarschijnlijk niet lijdt

Cumulative Layout Shift meet hoeveel de pagina verschuift tijdens het laden. Een productfoto die verschijnt en de prijs omlaag duwt. Een banner die laat laadt en de knop “In winkelwagen” onder de duim van de bezoeker wegschuift terwijl die tikt. Onder 0,1 is goed. Waar het gebeurt, kost het echt conversie. Een verkeerde tik is een klant die iets in zijn winkelwagen wilde leggen en in plaats daarvan de maattabel opende, of erger, iets bevestigde wat hij niet bedoelde. Een lay-out die verspringt, oogt als een webshop die het niet helemaal onder controle heeft, en vertrouwen herstel je moeilijk binnen één bezoek.

Hier scheidt eerlijk advies zich van een checklist. Bij de meeste Shopify-webshops is CLS al in orde. Dezelfde benchmark die LCP ziet zakken, zet de mediane mobiele CLS van Shopify rond 0,01, ruim binnen de grens en een factor tien eronder. De basisthema’s van Shopify reserveren standaard ruimte voor afbeeldingen en kerncomponenten, en precies die discipline voorkomt verschuivingen. Zolang je webshop geen specifieke symptomen vertoont, zit je gemiste omzet niet in CLS.

De uitzonderingen moet je wel precies kennen, want daar gaat deze meetwaarde echt mis. Maatwerk aan een thema waarbij de vaste afmetingen van afbeeldingscontainers verdwijnen. Apps die na de eerste weergave content boven de vouw invoegen: een cookiebanner, een promobalk, een aankondiging. Webfonts die laat laden en de tekst laten verspringen. Heeft je webshop geen van die patronen, dan verdedig je met werk aan CLS een grens die je allang ruim haalt.

Dit is de eerlijke versie die de meeste handleidingen je niet geven, omdat “fix alle drie” makkelijker te verkopen is dan “één kun je waarschijnlijk laten liggen”. Weten welke meetwaarde je aandacht niet nodig heeft, is net zo waardevol als weten welke wel. Zo besteed je een beperkt ontwikkelbudget aan de meetwaarde die je echt geld kost. Welke dat is, beantwoordt de volgende sectie.

Waarom alle drie tegelijk aanpakken de verkeerde volgorde is

Het standaardadvies is om Core Web Vitals als set te optimaliseren: alle drie naar groen en door. Voor de meeste Shopify-webshops is dat de verkeerde volgorde. De drie meetwaarden gaan niet even vaak mis, en ze zitten niet op hetzelfde punt in de funnel. Wie ze als één klus behandelt, verdeelt een beperkt ontwikkelbudget gelijk over één echte bottleneck en twee meetwaarden die meestal al in orde zijn.

De data laat geen twijfel over welke welke is. Een benchmark van 1.000 Shopify-webshops liet zien dat maar zo’n 48% op mobiel voor alle drie slaagt, en de onvoldoendes zitten bijna allemaal bij LCP. De mediane CLS kwam uit rond 0,01 en de mediane INP rond 153 ms, allebei binnen het goede bereik, terwijl LCP precies op de grens van 2,5 seconden lag. Het beeld dat daaruit volgt, is niet “Shopify-webshops zijn traag”. Het is “Shopify-webshops zakken op één specifieke meetwaarde, en die raakt de bezoeker die nog niets heeft besloten”.

De volgorde volgt dus uit twee vragen, na elkaar. Eén: op welke meetwaarde zak je echt in de velddata? Twee: welk moment in de funnel raakt die meetwaarde? Voor de gemiddelde webshop wijzen beide antwoorden dezelfde kant op. LCP staat het vaakst op rood en raakt koud verkeer, het publiek dat je betaalt om binnen te halen. Daarom komt LCP eerst. Niet omdat een snelheidsdogma dat voorschrijft, maar omdat daar het falen en de omzet samenvallen. INP komt als tweede. Meestal slaagt hij nu nog, maar hij wordt ongemerkt slechter naarmate de app-stack op productpagina’s groeit, en als hij wegzakt, kost hij je de tik met de hoogste koopintentie in de hele funnel. CLS komt als laatste, want bij de meeste webshops haal je die grens al.

De les die je hieruit meeneemt: een Core Web Vitals-project is geen snelheidsproject. Het is een kwestie van triage. De webshop die zijn velddata opent, de ene meetwaarde vindt die tekortschiet en vraagt wat die op zijn plek in de funnel kost, gaat beter converteren dan de webshop die dezelfde uren besteedt aan drie getallen naar groen slepen zonder te weten welke er echt lekte. Je inzet volgt de meetwaarde waarop je zakt en het geld dat daarachter ligt. De rest is onderhoud.

Wat je controleert, en in welke volgorde

Zo wordt de triage uit de vorige sectie een reeks stappen die je kunt aflopen. De volgorde telt zwaarder dan de losse fixes, want elke stap vertelt je of de volgende überhaupt de moeite waard is.

1. Haal eerst je velddata op, niet je Lighthouse-score. Open het Core Web Vitals-rapport in Google Search Console, of de CrUX-data in PageSpeed Insights, en lees de cijfers van echte gebruikers per meetwaarde en per template. Alleen dit overzicht klopt met waar Google op rankt en met wat bezoekers ervaren. De labscore is een hulpmiddel voor de diagnose later, niet het scorebord.
   
   

2. Zoek je LCP-element op de templates die het verkeer binnenhalen. Meestal zijn dat de productpagina en de landing pages waar het meeste advertentiebudget naartoe gaat. Stel vast wat het grootste element echt is, of het gecomprimeerd en met laadprioriteit wordt geladen, en of app-scripts eerder worden weergegeven en de weergave blokkeren. Hier vinden de meeste webshops hun grootste lek.
   
   

3. Leg de app-stack naast INP op pagina’s met veel interactie. Kijk naar wat er op de PDP en in de checkout wordt uitgevoerd, niet op de homepage. Elk script dat bij een tik afgaat, gaat rechtstreeks ten koste van je bezoekers met de hoogste koopintentie. Kruipt INP in de velddata richting 200 ms, dan is de app-stack op deze templates bijna altijd de oorzaak.
   
   

4. Controleer of CLS al in orde is voordat je er iets aan uitgeeft. Kijk naar het cijfer uit het veld. Ligt het rond 0,01 en heb je geen laat ladende banners of afbeeldingen zonder vaste afmetingen, laat het dan liggen en steek die moeite in de stappen hiervoor.
   
   

5. Meet opnieuw in de velddata als er een volle periode voorbij is. CrUX rapporteert over een doorlopende periode van 28 dagen, dus een fix die je vandaag live zet, laat pas na weken zijn echte effect in het veld zien. Wie de labscore de volgende ochtend ziet springen en de klus als klaar beschouwt, concludeert “we hebben het opgelost”, terwijl de meetwaarde in het veld en de conversieratio geen millimeter bewegen.
   
   

Het onderliggende patroon: de meeste van deze beperkingen erf je van eerdere beslissingen. Welk thema, hoeveel apps, of afbeeldingen ooit prioriteit kregen. Voorkomen is goedkoper dan achteraf repareren. Dat is de gedachte achter een build waarin performance voorop staat: het LCP-element, het scriptbudget en de gereserveerde ruimte in de lay-out liggen vast voordat de webshop live gaat, in plaats van dat je ze achteraf moet doorlichten terwijl er al conversie weglekt. Het is ook de standaard waarmee wij als eCommerce-bureau nieuwe Shopify-webshops bouwen: scriptbudget en beeldprioriteit liggen vast voordat er één pagina live gaat. Ben je al live, dan is de volgorde hierboven je inhaalslag, zo uitgevoerd dat de meetwaarde die tekortschiet en de omzet die ervan afhangt als eerste aan de beurt zijn.

Veelgestelde vragen

Optimaliseert Shopify Core Web Vitals automatisch? 

Deels. Shopify regelt de serverkant goed: een wereldwijd CDN, automatische conversie naar WebP en lichte basisthema’s geven elke webshop een snel vertrekpunt. Wat Shopify niet doet, is je beschermen tegen wat je er zelf bovenop zet. De apps, scripts van derden, aanpassingen aan je thema en te grote afbeeldingen die je toevoegt, duwen een webshop van groen naar rood. Het platform legt een stevige basis; de problemen komen bijna altijd van wat de webshop er zelf aan toevoegt.

Waarom stijgt mijn PageSpeed-score, maar mijn ranking en conversie niet? 

Omdat de PageSpeed-score een schatting uit het lab is, op basis van één gesimuleerde paginalading, terwijl Google rankt op velddata: echte Core Web Vitals van Chrome-gebruikers over een doorlopende periode van 28 dagen. Een groene labscore die niet klopt met je velddata, meet een pagina die geen echte klant laadt. De cijfers die je ranking echt bepalen, vind je in het Core Web Vitals-rapport van Search Console.

Welke Core Web Vital is het belangrijkst voor een Shopify-webshop? 

Voor de meeste webshops: LCP. Benchmarkdata laat zien dat Shopify-webshops vooral op LCP zakken, terwijl CLS en INP meestal binnen het goede bereik blijven. LCP raakt bovendien koud, betaald verkeer: de bezoeker die je geld kost om binnen te halen en die het minste geduld heeft. Fix de meetwaarde waarop je echt zakt, op het moment in de funnel dat hij raakt, voordat je aankomt aan de meetwaarden die al goed zijn.

Is INP hetzelfde als de oude FID-meetwaarde? 

Nee. INP verving First Input Delay in maart 2024 en is strenger. FID mat alleen de vertraging voordat de pagina een interactie begon te verwerken. INP meet de hele rondgang tot het scherm is bijgewerkt, en vangt daardoor vertraging op die FID miste. Vooral op productpagina’s, waar meerdere app-scripts om de main thread vechten.

Hoe lang duurt het voordat een Core Web Vitals-fix zichtbaar is? 

In de velddata: weken. CrUX rapporteert over een doorlopende periode van 28 dagen, dus een fix die je vandaag live zet, telt pas volledig mee in de meetwaarde die Google gebruikt als die periode is bijgetrokken. De labscore verandert meteen. Daarom zien teams een sprong in het lab van de ene op de andere dag aan voor een opgelost probleem, terwijl de meetwaarde in het veld rood blijft.

De belangrijkste punten

• De score die je optimaliseert en de score waarop Google rankt, zijn niet dezelfde. Lighthouse is een schatting uit het lab; rankings en conversie draaien op velddata van echte Chrome-gebruikers over 28 dagen.

• De drie Vitals kosten je conversie op verschillende momenten in de funnel. LCP kost je bezoekers die nog niet hebben besloten te blijven. INP kost je de bezoeker die al naar “In winkelwagen” grijpt. CLS kost je verkeerde tikken en vertrouwen.

• Bij de meeste Shopify-webshops gaat alleen LCP echt mis. CLS ligt standaard rond 0,01 en INP rond 153 ms, terwijl LCP op de grens van 2,5 seconden balanceert.

• Bepaal de volgorde op basis van waar het misgaat en wat dat kost, niet op basis van een checklist. Fix de meetwaarde waarop je zakt, op het moment in de funnel dat hij raakt, voordat je grenzen verdedigt die je al haalt.

• Een Core Web Vitals-project is een kwestie van triage, geen snelheidsproject.

De neiging om “alle drie op groen” te krijgen is sterk, omdat dat als af voelt. Het is ook de meest voorkomende manier waarop Shopify-teams echte ontwikkeluren besteden en daarna de conversieratio vlak zien blijven. Het getal in het rapport is niet het doel. Het moment in de funnel onder elke meetwaarde is dat wel. Een webshop die zijn velddata leest, de ene Vital vindt die tekortschiet en vraagt wat dat op die plek in de funnel kost, werkt aan zijn omzet. Een webshop die drie getallen naar groen sleept zonder te weten welke er lekte, werkt voor een scorebord. Bewaar dit artikel voor je volgende performance-sprint, en leg de velddata op tafel voordat iemand Lighthouse opent.