Je opent Search Console en ziet bij Core Web Vitals een melding over INP: "langer dan 200 ms". Dat klinkt technisch, maar het gaat over iets heel concreets: hoe snel je site reageert als iemand klikt, tikt of typt. Ik leg uit wat die melding betekent, waarom ze nu opduikt en hoe ik zo'n probleem aanpak.

Wat INP precies meet

Interaction to Next Paint, kort INP, is een stabiele Core Web Vital die meet hoe snel een pagina reageert, op basis van gegevens uit de Event Timing API. Dat staat in de uitleg op web.dev. INP kijkt naar alle interacties van een bezoeker op de pagina en rapporteert één waarde waar alle, of bijna alle, interacties onder bleven.

Het is belangrijk om te weten wat meetelt en wat niet:

  • Wel: klikken met de muis, tikken op een touchscreen en een toets indrukken, op een fysiek of een schermtoetsenbord.
  • Ook: interacties in iframes, zoals op afspelen klikken in een ingesloten video.
  • Niet: hoveren, zoomen en scrollen.

Per 50 interacties wordt de traagste genegeerd. Omdat de meeste paginabezoeken er niet meer dan 50 hebben, krijg je in de praktijk meestal de slechtste interactie te zien. Een pagina kan ook geen INP-waarde hebben, bijvoorbeeld als de bezoeker alleen scrolde of als het om een bot zoals een crawler ging.

Waarom meten over de hele levensduur van de pagina? Volgens gebruiksgegevens van Chrome brengt een bezoeker 90% van zijn tijd op een pagina door nadat die geladen is. Een snelle laadtijd zegt dus niet alles.

De grenswaarden worden gemeten op het 75e percentiel van echte bezoeken, apart voor mobiel en desktop:

  • 200 milliseconden of minder: goed
  • meer dan 200 tot en met 500 milliseconden: verbetering nodig
  • meer dan 500 milliseconden: slecht

Waarom dit nu speelt

INP is niet nieuw. Het werd in mei 2022 als experimentele metriek geïntroduceerd en op 12 maart 2024 werd het officieel een Core Web Vital, ter vervanging van First Input Delay (FID), zo meldt de lanceringspost op web.dev. Sindsdien beoordeelt PageSpeed Insights INP in plaats van FID. Ontwikkelaars hadden tot 9 september 2024 om tools die FID-gegevens ophaalden aan te passen.

De documentatie van Google Search Central noemt drie Core Web Vitals: LCP voor het laden (streef naar minder dan 2,5 seconden), INP voor de reactiesnelheid (streef naar minder dan 200 milliseconden) en CLS voor de visuele stabiliteit. Een site die vroeger netjes scoorde op FID, kan op INP dus een probleem tonen, ook al is er aan de site zelf niets veranderd.

Hoe je het rapport in Search Console leest

Het Core Web Vitals-rapport groepeert URL's per status (Slecht, Verbetering nodig, Goed), per metriek (CLS, INP, LCP) en per URL-groep, een verzameling vergelijkbare pagina's. Het rapport gebruikt echte gebruikersgegevens uit het Chrome User Experience Report (CrUX).

Een paar dingen die vaak verwarring geven:

  • "Group INP" betekent dat 75% van de paginaverzoeken in de afgelopen 28 dagen die reactietijd of minder had.
  • De slechtste metriek bepaalt de status. Een goede INP met een slechte CLS geeft toch "slecht".
  • De status geldt voor de hele groep, niet voor één losse pagina.
  • Mobiel en desktop worden apart beoordeeld. Goed op mobiel betekent niet automatisch goed op desktop, en omgekeerd.

Waar de vertraging vandaan komt

Een interactie bestaat uit drie delen. Eerst is er de invoervertraging tot de event handlers starten, onder meer door lange taken op de main thread. Dan draaien de event handlers zelf. Daarna volgt nog een vertraging tot het volgende frame op het scherm verschijnt.

Volgens de handleiding over INP optimaliseren kunnen lange taken die ontstaan bij het laden en uitvoeren van scripts interacties tijdens het laden vertragen. Anders gezegd: hoe meer werk de browser bij het openen van de pagina moet verwerken, hoe groter de kans dat een klik even blijft hangen.

Wat je concreet doet, in deze volgorde

  1. Open het Core Web Vitals-rapport en noteer welke URL-groepen een slechte INP hebben, apart voor mobiel en desktop. Zo weet je welk soort pagina het probleem heeft, bijvoorbeeld je productpagina's of je contactformulier.
  2. Begin met veldgegevens. Komt je site in aanmerking voor CrUX, dan vind je de INP-gegevens in PageSpeed Insights. Eigen metingen bij echte gebruikers (RUM) geven meer detail: welke interactie traag is, of die tijdens of na het laden gebeurde, en welk deel van de interactie de vertraging veroorzaakt.
  3. Zoek daarna in een lab-omgeving de oorzaak. Speel die trage interactie na en kijk wat er op de main thread gebeurt.
  4. Pak de oorzaak aan. Vermijd lange taken bij het laden van scripts. Splits event callbacks op en geef de main thread vaak de kans om ander werk te doen, bijvoorbeeld met setTimeout, want de callback draait dan in een nieuwe taak. Zo toont het scherm sneller visuele feedback. Werk dat niet nodig is voor het volgende frame, schuif je naar een latere taak. Houd daarnaast de DOM klein, vermijd grote, complexe layouts en beperk de stijlberekeningen.
  5. Denk je dat het opgelost is, klik dan op de detailpagina van het probleem in het rapport op "Start Tracking". Volg daarna je verkeer en de INP-waarden van de groep op. Omdat het rapport met de afgelopen 28 dagen werkt, zie je het effect niet meteen.

Wanneer je het uitbesteedt

De eerste stap kan je zelf: het rapport lezen en zien welke pagina's het betreft. Vanaf stap drie wordt het technisch. Je moet een performanceprofiel kunnen lezen, weten welk script een lange taak veroorzaakt en code kunnen aanpassen zonder dat je formulier of winkelmandje stukgaat. Draait je site op een thema of plugins die je niet zelf beheert, dan kan de oorzaak in code zitten waar je als ondernemer liever niet aankomt.

Dat soort werk doe ik als onderdeel van onderhoud en beveiliging: meten, de oorzaak zoeken, oplossen en daarna de 28 dagen opvolgen tot de groep weer goed staat. Twijfel je hoe ernstig je melding is, neem dan contact op met je Search Console-gegevens erbij, dan kijk ik mee.