Uw website laadt netjes. De foto staat er binnen twee seconden, niets verspringt. Toch klagen klanten dat de site “stroef” voelt. Het menu op de telefoon klapt pas open na een merkbare pauze. Het filter in de webshop hangt even als je een maat kiest. In de zoekwoordenmodus van het contactformulier lijkt het typen achter te lopen.

Dat is geen laadtijdprobleem. Dat is een reactieprobleem, en sinds maart 2024 meet Google het als INP, een van de drie INP Core Web Vitals-waarden waar uw site op beoordeeld wordt. Van de drie is INP het minst bekend en, op WordPress-sites, het vaakst rood. Dit artikel legt uit wat er gemeten wordt, waarom juist WordPress-sites hier last van hebben en wat ertegen helpt.

Wat INP precies meet

INP staat voor Interaction to Next Paint. Elke keer dat een bezoeker klikt, tikt of een toets indrukt, meet de browser hoe lang het duurt voordat het scherm zichtbaar reageert. Niet totdat de actie helemaal klaar is, maar totdat er iets verandert: een menu dat opent, een knop die van kleur wisselt, een spinner die verschijnt.

Aan het eind van het bezoek wordt (ruwweg) de traagste interactie genomen als de INP van die pagina. Onder de 200 milliseconden is goed, tussen 200 en 500 matig, daarboven slecht. Google kijkt naar wat 75 procent van de bezoekers ervaart, dus één trage klik op een oud toestel is geen ramp; structureel trage interacties wel.

INP verving de oudere meetwaarde FID, die alleen de allereerste interactie mat en bijna nooit rood was. INP is strenger omdat het alle interacties meet, ook die diep in het bezoek, als er inmiddels veel scripts actief zijn. Wilt u de drie waarden naast elkaar zien, lees dan eerst de Core Web Vitals in gewone taal.

Waarom een klik traag kan zijn

De browser doet in principe één ding tegelijk op de hoofdthread. Als er op het moment van uw klik een script bezig is, moet uw klik wachten tot dat script klaar is. Daarna wordt uw klik verwerkt, en pas dan wordt het scherm opnieuw getekend. Een trage INP heeft dus drie mogelijke oorzaken:

  1. Wachten. Er draait al iets: een trackingscript, een slider die berekent, een chatwidget die inlaadt. Uw klik staat in de rij.
  2. Verwerken. De handeling zelf is zwaar. Een productfilter dat honderden items opnieuw sorteert, een megamenu dat veel elementen tegelijk opbouwt.
  3. Tekenen. De verandering op het scherm is groot of ingewikkeld, bijvoorbeeld een animatie die de hele pagina beïnvloedt.

In de praktijk is de eerste oorzaak veruit de grootste. Niet uw menu is traag, maar het menu moet wachten op iets anders.

Waarom WordPress-sites hier vaak op zakken

WordPress zelf is niet het probleem. Het probleem is wat er in de loop van de jaren omheen is gegroeid. Een gemiddelde bedrijfssite die wij overnemen, laadt op elke pagina JavaScript van vijftien tot dertig bronnen: het thema, de page builder, een slider, een formulierenplugin, een cookiebanner, Google Analytics, de Facebook-pixel, een chatwidget, een beoordelingsplugin, een pop-upplugin, en dan nog een paar die niemand meer kent.

Elk van die scripts wil iets doen bij het laden, en veel ervan blijven actief tijdens het bezoek. Ze luisteren naar scrollen, naar muisbewegingen, naar klikken. Uw bezoeker tikt op het menu en komt achter in de rij te staan.

Daar komt bij: page builders als Elementor en Divi genereren veel meer HTML dan een handgeschreven thema. Een grotere pagina betekent meer werk voor de browser bij elke verandering, en dat merkt u het eerst op een telefoon van drie jaar oud.

Hoe u de oorzaak vindt

PageSpeed Insights toont INP alleen in de velddata bovenaan, als uw site genoeg bezoekers heeft. De labtest eronder meet INP niet, omdat er geen echte interacties zijn. Wel geeft de labtest een goede indicatie via “Totale blokkeringstijd” (TBT): hoe lang de hoofdthread bezet is tijdens het laden. Een hoge TBT betekent bijna altijd een slechte INP.

Wilt u zien welk script de boosdoener is, kijk dan onder Diagnose naar “Verminder de uitvoeringstijd van JavaScript” en “Verminder de impact van code van derden”. Daar staat per bron hoeveel milliseconden hij kost. Trackingscripts en chatwidgets staan in onze ervaring steevast bovenaan.

Voor een echte meting van interacties gebruikt u Chrome: F12, tabblad Performance, opname starten, op het menu klikken, opname stoppen. U ziet dan precies wat er tussen uw klik en de schermverandering gebeurt. Dat is specialistenwerk, maar het is de enige manier om zeker te weten welk script de vertraging veroorzaakt.

Wat helpt, in volgorde van effect

  • Scripts weghalen die u niet gebruikt. De chatwidget waar niemand op reageert, de pixel van een campagne uit 2022, de beoordelingsplugin die alleen op één pagina nodig is maar overal laadt. Dit is de maatregel met het grootste effect en de minste risico’s.
  • Scripts uitstellen. Laat niet-kritieke scripts pas laden na de eerste interactie of na een paar seconden. Cacheplugins hebben hier een optie voor (“JavaScript uitstellen” of “vertraagde uitvoering”). Test dit zorgvuldig: een verkeerd uitgesteld script breekt een formulier.
  • Scripts per pagina laden. Een formulierenplugin hoort alleen op de contactpagina te laden. Plugins als Perfmatters of Asset CleanUp maken dat mogelijk.
  • Zware onderdelen vervangen. Een slider door één stilstaande afbeelding, een megamenu door een eenvoudiger menu, een live-productfilter door een filter dat de pagina herlaadt.
  • Trackingscripts via een tag manager met vertraging. Google Tag Manager kan scripts laden na een gebeurtenis in plaats van direct.

Merk op dat caching hier weinig helpt. Caching versnelt het leveren van de pagina, niet wat de browser daarna moet doen. Een site met een perfecte cache kan een rampzalige INP hebben.

Wanneer u hulp inschakelt

Ongebruikte plugins verwijderen kunt u zelf, mits u een back-up heeft. Scripts uitstellen en per pagina laden is instellingenwerk waarbij één verkeerd vinkje uw bestelknop uitschakelt, en die schade ziet u pas als een klant belt. Een snelheidsoptimalisatie door een specialist neemt in de regel de hele scriptlaag mee: wat weg kan, wat later mag en wat kritiek is, met een test op een kopie van de site voordat het live gaat.

Een voorbeeld: een kledingwebshop in Breda had een INP van 640 milliseconden op mobiel, vooral op de categoriepagina’s. Oorzaak: een productfilter dat bij elke keuze alle producten opnieuw ophaalde, in combinatie met drie marketingscripts die bij elke scroll actief werden. Het filter werd vervangen door een lichtere variant, twee scripts gingen eruit, één werd vertraagd. Resultaat na een maand velddata: 170 milliseconden.

Het gaat vaak samen met andere problemen. Als uw INP slecht is door een overvloed aan scripts, is de kans groot dat ook het aantal plugins aan een kritische blik toe is. Begin daar: elke plugin die u vandaag verwijdert, is een script dat morgen niet meer in de weg staat als iemand op uw menu tikt.