INP op Shopify verbeteren: waar de meeste webshops op zakken en in welke volgorde je het oplost

Het Core Web Vitals-rapport in Search Console springt van groen naar rood, en de meetwaarde die zakt is precies de meetwaarde die niemand echt snapt: INP. De eerste reactie is dan het ergste aannemen. Het theme deugt niet, en alleen een dure herbouw lost het op. Voor de meeste Shopify-webshops klopt dat niet. Wie er toch naar handelt, kiest de duurste aanpak voor een probleem dat meestal veel goedkoper op te lossen is, als je de goede volgorde aanhoudt.

Dat je op INP kunt zakken, komt juist doordat een webshop een van de meest interactieve dingen op het web is. Dit artikel geeft de volgorde van aanpak. Hoe je INP goed meet, hoe je de interactie vindt die je echt de score kost, en hoe je de oplossingen afwerkt: van goedkoop en met veel effect tot het zeldzame geval waarin dieper werk aan het theme echt nodig is. Bijna elke webshop haalt de norm lang voordat hij bij die laatste stap is.

Waarom Shopify-webshops juist op INP zakken

Interaction to Next Paint (INP) is de Core Web Vital die meet hoe snel een pagina zichtbaar reageert op een klik, tik of toetsaanslag. Google noemt 200 milliseconden of minder goed en alles boven 500 milliseconden slecht. Er wordt gemeten bij echte bezoekers, over het hele bezoek, en niet bij één losse interactie. Shopify-webshops zakken er vaker op dan de meeste sites, omdat je in eCommerce ongewoon veel klikt, tikt en kiest.

Die hoeveelheid interactie verklaart alles. INP verving First Input Delay in maart 2024, en die overstap viel hard uit. FID beoordeelde alleen de eerste interactie, INP beoordeelt de slechtste van het hele bezoek. Een webshop bestaat uit niets dan interacties: variantkiezers, aantalknoppen, de winkelwagenknop, cart drawers, collectiefilters, zoeksuggesties, megamenu's, quick view-pop-ups. Elk daarvan draait JavaScript zodra iemand het aanraakt, en elk daarvan kan de trage interactie zijn die je score bepaalt. Daarbovenop komt wat Shopify-webshops eigen is: een stapel apps van derden die elk hun eigen scripts inladen. De main thread die op al die tikken moet reageren, zit dan al vol voordat de klant binnen is. Velddata uit de markt laat zien dat ongeveer 40 procent van de mobiele sites nog steeds op INP zakt, en eCommerce zit aan de moeilijke kant van dat beeld.

Het helpt om te weten wat INP precies meet, want daar hangt de oplossing van af. Elke interactie heeft drie fasen. De wachttijd (input delay): hoe lang de browser moet wachten op een drukke main thread voordat hij de tik überhaupt kan oppakken. De verwerkingstijd (processing time): hoe lang de code van je event handler draait. En de weergavetijd (presentation delay): hoe lang de browser daarna nodig heeft om het resultaat op het scherm te zetten. Een slechte INP-score betekent dat een van die drie fasen uitloopt bij je traagste interactie. Veel pogingen lopen vast omdat mensen blind aan INP sleutelen: willekeurig JavaScript weghalen en er het beste van hopen. De score beweegt pas als je de fase aanpakt die echt te lang duurt, bij de interactie die echt traag is. Daarom gaat het volgende deel over meten, nog voordat je iets aanraakt.

Meet eerst goed, anders los je het verkeerde op

INP meet je niet zoals de meeste mensen snelheid meten. Het is een veldmeting, verzameld bij echte bezoekers die over langere tijd iets doen in je live webshop. Lighthouse of PageSpeed Insights draaien bij het laden van de pagina geeft je dus geen echt INP-cijfer. Labtools laden de pagina, maar ze klikken niet veertig keer op de variantkiezer zoals je klanten doen. Begin bij data van echte bezoekers. Anders optimaliseer je interacties waar niemand last van heeft, en blijft de interactie die wel pijn doet liggen.

Er zijn drie praktische bronnen voor die data, van minst naar meest bruikbaar. Het Core Web Vitals-rapport in Google Search Console vertelt je of je een INP-probleem hebt en bij welke groepen URL's. Daar houdt het op: de oorzaak noemt het niet. PageSpeed Insights, gedraaid op een pagina met veel verkeer, toont de INP uit het Chrome User Experience Report naast de labdiagnose. Het meest bruikbaar voor een webshop is het Web Performance-dashboard van Shopify zelf, in de admin. Dat splitst INP uit per paginatype en apparaat, zodat je meteen ziet of het probleem bijvoorbeeld op productpagina's op mobiel zit, in plaats van te gokken. Shopify gaat in zijn eigen uitleg over INP debuggen met CSS-selectors nog een stap verder: daarmee herleid je een slechte score tot het precieze element waar een bezoeker op klikte.

Meten heeft hier een beperkt doel, en dat mag je gewoon hardop zeggen: vind de ene slechtste interactie, op het paginatype waar het pijn doet, en stel vast welke van de drie fasen te lang duurt. Wijst het admin-rapport of de CrUX-data je bijvoorbeeld naar de variantkiezer op mobiele productpagina's, speel het dan na in Chrome DevTools. Open het Performance-paneel, neem op terwijl je precies die interactie uitvoert en lees de Interactions-track. Die deelt de interactie op in wachttijd, verwerking en weergave, en recente versies van DevTools markeren welke interactie als INP gerapporteerd zou worden. Die trace is je diagnose. Alles in het volgende deel is geordend naar de fase die in de trace te lang duurt. Dat is het verschil tussen een ingreep die de score beweegt en een week scripts weghalen die niets verandert. Shopify is er sinds het de overstap van FID naar INP voor het eerst aankondigde duidelijk over: deze meetwaarde begint bij velddata, en de webshops die slagen beginnen daar ook.

De volgorde van aanpak: eerst de fase bepalen, dan het goedkoopste eerst

Zodra de trace laat zien welke fase te lang duurt, vallen de oplossingen in een duidelijke volgorde: goedkoop en met veel effect eerst. Het idee daarachter is simpel. De meeste INP-problemen op Shopify zijn wachttijdproblemen, veroorzaakt door een overvolle main thread. En de goedkoopste manier om die te ontlasten, is code die je niet nodig hebt niet meer laten draaien. Je werkt dus van wat je kunt weghalen naar wat je moet herschrijven. Aan de diepere opbouw van het theme kom je pas als de eerdere stappen niet genoeg waren.

De tabel hieronder is de beslisboom, platgeslagen tot een volgorde. Kijk welke fase je trace aanwijst en begin bij de hoogste rij die van toepassing is.

De eerste twee rijen lossen bij meer Shopify-webshops het probleem op dan alles daaronder bij elkaar. De meest voorkomende oorzaak is gewoon te veel JavaScript van derden dat te vroeg laadt. Een app weghalen waarvan je vergeten was dat je hem had, kost niets en werkt meteen. De overgebleven scripts uitstellen, zodat een chatwidget of reviewplatform pas laadt als de pagina al reageert en niet vecht met de eerste tikken, is meestal een aanpassing in het theme of de tag manager. Geen herbouw. Eén chatscript kan op elke pagina ruim een tiende seconde blokkade op de main thread veroorzaken. Dit is dus zelden werk in de marge.

Bij rij drie en vier verdient een developer zijn geld, maar ook dat zijn aanpassingen, geen nieuw theme. Laat de trace zien dat de verwerking lang duurt bij een onderdeel van het theme zelf, dan doet de handler van dat onderdeel te veel synchroon werk. De oplossing: inkorten, debouncen, of werk dat niet dringend is van het kritieke pad halen, bijvoorbeeld door tussen stukken werk de main thread even vrij te geven. Rij vijf en zes gaan over de weergavefase. Die is minder vaak de boosdoener: de interactie dwingt de browser dan om te veel tegelijk opnieuw te tekenen. En om het maar duidelijk te zeggen: je loopt zelden de hele tabel af. Je meet, je komt uit bij de rij waar je fase naar wijst, je lost dat op en je meet opnieuw voordat je aan de volgende begint. Vaak is de score al in orde twee of drie rijen eerder dan je dacht.

Opnieuw meten, en wanneer een nieuw theme echt het antwoord is

De volgorde van aanpak is een lus, geen eenmalige ronde, en die lus is het eigenlijke draaiboek. Los de rij op waar je trace naar wees en meet opnieuw voordat je iets anders aanraakt. Performancewerk zit vol ingrepen die goed lijken en niets opleveren. Twee dingen maken de lus trager dan mensen verwachten, en wie ze kent, raakt minder snel in paniek. Ten eerste is INP een veldmeting over een voortschrijdend venster van achtentwintig dagen. Een oplossing die je vandaag live zet, zie je pas terug in Search Console of CrUX als er in de weken daarna genoeg data van echte bezoekers is binnengekomen. Controleer de oplossing daarom direct in een DevTools-trace en wacht daarna tot de velddata het bevestigt. Ten tweede schuift INP mee met je webshop. Eén nieuwe app of één nieuw script kan een voldoende score ongemerkt weer onvoldoende maken. Daarom hoort monitoring in je draaiboek, en is het geen eenmalige schoonmaak.

Er is een eerlijke grens, en die moet je benoemen, juist omdat dit hele artikel ertegen pleit om er als eerste naar te grijpen. Soms werkt een webshop de volledige volgorde af: apps opgeruimd, scripts van derden uitgesteld, handlers ingekort, lange taken opgeknipt. En toch zakt hij nog. Dan zit de beperking in de opbouw van het theme zelf: een opgeblazen, zwaar aangepaste build waarin de interactielogica overal doorheen loopt. Dat is het zeldzame geval waarin dieper werk aan het theme, of een herbouw op een lichtere basis, echt het antwoord is en geen reflex. Het punt van de volgorde is dat je die conclusie hebt verdiend. Je hebt data die laat zien dat de goedkopere oplossingen niet genoeg waren. Je hebt dus geen herbouwbudget uitgegeven aan een probleem dat twee uitgestelde scripts hadden opgelost. Kom je daar uit, schakel dan een Shopify Plus-bureau in dat de herbouw afbakent op basis van dezelfde data, en niet op basis van een nieuwe gok. INP is één onderdeel van het bredere verhaal van Core Web Vitals en vindbaarheid, en vraagt dezelfde discipline: eerst meten, in volgorde oplossen, opnieuw meten en blijven opletten.

Veelgestelde vragen

Wat is een goede INP-score? 

Google noemt een INP van 200 milliseconden of minder goed, 200 tot 500 voor verbetering vatbaar en boven 500 slecht. Er wordt gemeten op het 75e percentiel van echte interacties. Omdat INP je slechtste relevante interactie van het hele bezoek rapporteert, kan één traag onderdeel zoals een variantkiezer een verder snelle webshop laten zakken.

Kunnen Shopify-apps een slechte INP veroorzaken? 

Ja, en ze zijn de meest voorkomende oorzaak. Elke app kan JavaScript inladen dat op de main thread draait. Reviewwidgets, chat, pop-ups, analytics en retargetingpixels zijn vaste boosdoeners. Eén chatscript kan op elke pagina ruim een tiende seconde blokkade veroorzaken. Daarom is apps doorlichten en uitstellen de eerste stap in de volgorde van aanpak.

Kan ik INP verbeteren zonder mijn theme opnieuw te bouwen? 

Bijna altijd. De meeste INP-problemen op Shopify komen door te veel JavaScript van derden dat te vroeg laadt. Dat los je op door ongebruikte apps te verwijderen en de overgebleven scripts uit te stellen, niet met een nieuw theme. Een herbouw is alleen nodig in het zeldzame geval dat de volgorde van aanpak is uitgeput en bewezen is dat de opbouw van het theme zelf de beperking is.

Waarom is mijn INP niet beter geworden na de oplossing? 

Of je hebt een fase of interactie aangepakt die niet de gerapporteerde was, en daarom moet je eerst de slechtste interactie meten. Of de oplossing werkt wel, maar de velddata loopt nog achter. INP wordt gemeten over een voortschrijdend venster van achtentwintig dagen. Controleer de wijziging dus meteen in een DevTools-trace en reken erop dat Search Console in de weken daarna volgt.

De belangrijkste punten

• Shopify-webshops zakken op INP omdat ze vol interacties zitten. Variantkiezers, cart drawers, filters, zoeken en de scripts van elke app vechten om één main thread, en INP beoordeelt die op de slechtste interactie.

• Meet bij echte bezoekers, niet in het lab. Gebruik Search Console, de velddata in PageSpeed Insights en het Web Performance-rapport in de Shopify-admin om de slechtste interactie te vinden en te zien welke van de drie fasen te lang duurt.

• Werk de volgorde af, goedkoopste eerst. Licht je apps door en verwijder wat je niet gebruikt, stel scripts van derden uit, pak daarna de handlers van het theme aan, knip lange taken op en maak de weergave lichter. Met de eerste twee rijen zijn de meeste webshops er al.

• Een nieuw theme is het laatste redmiddel, geen reflex. Kom daar pas op uit als bewezen is dat de stappen in volgorde niet genoeg waren, met data die de uitgave rechtvaardigt.

• INP schuift mee, dus blijf het volgen. Velddata loopt over een venster van achtentwintig dagen, en één nieuw script kan een voldoende weer tenietdoen. Neem opnieuw meten op in je draaiboek.

INP oplossen is minder een technisch raadsel dan een kwestie van volgorde. De webshops die slagen hebben niet de beste developers. Ze hebben de slechtste interactie gemeten voordat ze iets aanraakten, en werkten de oplossingen af van goedkoop naar diep, in plaats van meteen naar een herbouw te grijpen. Zet de volgorde van aanpak in het performancedraaiboek van je team en doorloop hem elke keer op dezelfde manier als een score wegzakt. Bewaar dit artikel ernaast, zodat de volgende rode status in Search Console een checklist is en geen paniekactie.