Vind en herstel Interaction to Next Paint (INP) problemen

Vind en herstel Interaction to Next Paint (INP) problemen

In ons vorige artikel spraken we over de Interaction to Next Paint. Als je de basisprincipes wilt nalezen is dit een geweldige plek om te beginnen!

In dit artikel zal ik me concentreren op het identificeren van de verschillende Interaction To Next Paint problemen en vervolgens uitleggen hoe je ze kunt oplossen!

INP TIP: meestal zal de INP veel slechter zijn wanneer een gebruiker interactie heeft met de pagina tijdens de opstartfase van het laden van de pagina. Daarom is het bij het debuggen van de INP zinvol om zowel alle interacties als de laadstatus van de pagina te loggen!

Stap 1: Controleer de INP in Search Console

"De eerste stap naar herstel is toegeven dat je een probleem hebt". Dus voordat we iets doen om de Interaction to Next Paint te repareren, laten we er zeker van zijn dat we echt een probleem hebben met de Interaction to Next Paint.

Log in op je Google Search Console. Klik in het linkermenu op Core Web Vitals en selecteer Mobiel of Desktop (tip: meestal zijn INP-problemen op mobiel, dus begin met mobiel)

Hier zie je een overzicht van alle Core Web Vitals gerelateerde problemen die momenteel op je site zijn. Als een van deze problemen INP-gerelateerd is, hebben we bevestigd dat er een probleem is!

Stap 2: Identificeer Interaction to Next Paint problemen

Google Search Console geeft je geen informatie behalve URL-groepen om uit te zoeken wat de problemen met de Interaction to Next Paint veroorzaakt. Dus meestal zie ik ontwikkelaars er gewoon blind in gaan. Ze beginnen met het verwijderen van ongebruikte JavaScript (altijd een goed idee) en het opbreken van de main thread (ook een goed idee), maar dat lost de INP bijna nooit volledig op.

Daarom zullen we bij het verbeteren van de INP precies moeten weten wat er aan de hand is.

Welke elementen veroorzaken bij interactie een slechte INP-score. Meestal wordt een slechte INP-score niet veroorzaakt door één enkel element, maar door een combinatie van problemen. We moeten ze één voor één aanpakken, beginnend bij de ergste en naar boven werken.
Wanneer gebeuren deze interacties? Gebeuren ze tijdens de opstartfase van het laden van de pagina of gebeuren ze zelfs wanneer de hoofdpagina
Waar gebeuren deze interacties? Gebeuren ze op elke pagina of gebeuren ze alleen op een paar geselecteerde pagina's.
Hoe kunnen we deze interacties repliceren? Je bent er inmiddels misschien achter gekomen dat het moeilijk is om INP-problemen te repliceren. Daarom moeten we onszelf voorbereiden op succes door apparaatkenmerken na te bootsen met een slechte INP-score.

Stel RUM-tracking in

Om al deze vragen te beantwoorden, moeten we echte gebruikers gaan volgen en eventuele problemen loggen die zich kunnen voordoen met de Interaction to Next Paint. Er zijn verschillende manieren om RUM-tracking in te schakelen. De eerste is door gebruik te maken van de Web Vitals bibliotheek en de resultaten naar je eigen analytics backend te sturen. Het voordeel van deze methode is dat het goedkoop en flexibel is. Het nadeel is dat het misschien veel extra werk is.

Een goed alternatief voor het verzenden van je Core Web Vitals-gegevens naar je eigen backend is door gebruik te maken van een van de vele RUM-tools die er zijn. Wij hebben Core/Dash ontwikkeld speciaal voor deze use cases. Core/Dash is een goedkope, snelle en effectieve RUM-tool die gewoon de klus klaart! Natuurlijk zijn er veel RUM oplossingen en die zullen ook de klus klaren (tegen een hogere prijs echter)

Vind trage interacties per element die een hoge INP veroorzaken

Het eerste dat moet worden gedaan, is de 'traagste' interacties vinden die de slechtste Time to First Byte scores veroorzaken. Lijst je pagina's gewoon op 'INP metric by Elements' in CoreDash en je krijgt je traagste interacties. Klik op de eerste regel om je statistieken te filteren op deze interacties.

Vind wanneer slechte INP-interacties plaatsvinden

Sorteer vervolgens de gefilterde URL's op laadstatus. Dit geeft je meer inzicht in de hoofdoorzaak van de INP. In dit geval gebeurt de hoge INP wanneer de DOM-inhoud is geladen. Dit betekent dat scripts zijn geparseerd, maar asynchrone scripts en de subbronnen van de pagina zijn nog niet geladen. In dit geval wordt de INP veroorzaakt door vroege klikken wanneer de pagina nog niet volledig is geladen!

Ga door met het klikken op de laadstatus met de hoogste impact om nog een filter te maken!

Vind URL's die verantwoordelijk zijn voor hoge INP-scores

Ten slotte, wanneer we hebben gefilterd op de elementen met de langzaamste interactie en de juiste laadstatus, zullen we kijken naar de URL's waar de INP het slechtst is. In dit geval gebeurt dit duidelijk op een specifieke set pagina's.

Vind apparaatkenmerken

Ten slotte, wanneer we trage interacties, laadstatus en url's hebben geïdentificeerd die een hoge Interaction to Next Paint veroorzaken, zullen we kijken naar welke soorten bezoekers de slechtste INP-scores veroorzaken. We zouden kijken naar Apparaatgeheugen, Bandbreedte, Schermgrootte enz. Zodra we deze kenmerken hebben geïdentificeerd, kunnen we overgaan tot het repliceren en loggen van het probleem!

Stap 3: repliceer en debug interacties die een hoge INP-score veroorzaken

Zodra we alle informatie hebben die we nodig hebben, kunnen we diep in de onderliggende problemen van de Interaction to Next Paint duiken.

Zet jezelf op voor succes: repliceer de INP-falende omstandigheden

Het volgende dat we moeten doen, is proberen de falende INP opnieuw te creëren. Dit doen we door de omstandigheden na te bootsen waarin de INP mogelijk faalt.

Gebruik het Chrome Performance Panel: Open de Chrome developer tools (Ctrl-Shift-i) en selecteer het performance panel. In de bovenste balk kun je de CPU Throttle selecteren (zet deze op 4x vertraging om een normaal mobiel apparaat te emuleren), de Network Throttle (selecteer de snelle 3g preset om je gemiddelde mobiele apparaat na te bootsen) en stel de hardware concurrency in op 4 of 8 om je gemiddelde mobiel na te bootsen.

Om Chrome te laden met minder beschikbaar geheugen (hoewel het verlagen van de netwerk- en CPU-instelling vaak de klus zal klaren!) start Chrome op in een docker container en wijs minder geheugen toe.

Herlaad de pagina, interageer en controleer de INP met de Core Web Vitals visualizer

De volgende stap om de oorzaak van de slechte INP-scores te vinden, is door de omstandigheden te simuleren en te bevestigen dat de INP-scores inderdaad zo slecht zijn als gerapporteerd.

Herlaad pagina en klik op het juiste element op het juiste moment

Debug de INP met een performance trace

Dit is het moment waar je je op hebt voorbereid in de vorige stappen. Het is tijd om erachter te komen waarom een bepaalde interactie de slechte Interaction To Next Paint score veroorzaakt.

Open de Chrome Developer Console opnieuw (Ctrl-Shift-i), navigeer naar het Performance panel en klik deze keer op het circulaire pijl-pictogram om de pagina te herladen en te beginnen met opnemen (of gebruik de Ctrl-Shift-E sneltoets).

Open de Chrome Developer Console opnieuw (Ctrl-Shift-i), navigeer naar het Performance panel en klik deze keer op het circulaire pijl-pictogram om de pagina te herladen en te beginnen met opnemen (of gebruik de Ctrl-Shift-E sneltoets).

Stap 3: Herstel INP-problemen

We zijn nu op een punt waar we weten welke interactie onze slechte INP veroorzaakt en we hebben geanalyseerd wat er precies gebeurt tijdens deze langzame interactie. Dit betekent dat het tijd is om de Interaction to Next Paint te repareren. De Interaction to Next Paint kan worden opgesplitst in 3 fasen: 'input delay', 'processing time' en 'presentation delay'.

Elke fase van de interaction to next paint moet anders worden behandeld!

Minimaliseer Input Delay:

Input delay is de tijd tussen de interactie met de pagina tot wanneer de event callback begint te lopen. Hoewel er altijd enige input delay is (zelfs browsers hebben tijd nodig om de callbacks te plannen), zijn er een paar dingen om te overwegen:

1. Vermijd lange taken (long tasks). Wanneer een taak wordt uitgevoerd, blokkeert deze de main thread en laat de event callbacks wachten. Dit is vooral belangrijk bij het optimaliseren van vroege klikken (aangezien de meeste scripts op dat moment zullen worden uitgevoerd). 
2. Wees voorzichtig bij het maken van nieuwe taken. Bijvoorbeeld terugkerende taken via setTimeout() of taken die waarschijnlijk vóór het INP-event zullen plaatsvinden, zoals callbacks op het mouseover event.
3. Meet en beoordeel vroege interactie. Wanneer een interactief element vroeg wordt gepresenteerd (bijvoorbeeld een site zoekelement) en wordt bestuurd door JavaScript dat later laadt, zal elke interactie met het element geen onmiddellijke lay-outupdate activeren. Prioriteer ofwel de functionaliteit of verberg/schakel het element uit voordat het goed werkt.
4. Gebruik web workers om JavaScript buiten de main thread van de browser uit te voeren. Web workers zorgen ervoor dat scripts buiten de main thread kunnen draaien. Dit voorkomt dat de main thread blokkeert en INP input delay problemen veroorzaakt
   
5. Laad nice-to-have scripts van derden tijdens browser idle tijd.  Sommige scripts zijn kritieker dan andere. Het is zinvol om deze scripts te prioriteren en minder belangrijke scripts te laden tijdens browser idle tijd. Bijvoorbeeld een chatscript

Minimaliseer processing time

1. Verwijder onnodige code. Onnodige code is ofwel oudere code die nog steeds draait of nieuwe code die niet nodig is op deze specifieke pagina maar nog steeds CPU-tijd in beslag neemt. Dit is veruit de gemakkelijkste manier om de INP onmiddellijk te verbeteren.
2. Stel code uit (defer) die niet hoeft te draaien voor de volgende paint. Splits code op in kritieke code die vóór de INP moet draaien en niet-kritieke code (bijvoorbeeld analytics verzenden) en plan dat na het INP-event met de requestIdleCallback() methode. 
3. Optimaliseer code die vóór de paint moet draaien. Controleer je code en herschrijf langzame of ineffectieve delen.
4. Geef directe feedback. Geef bij gecompliceerde of mogelijke langzame taken directe feedback voordat de hoofdcode wordt uitgevoerd.

Minimaliseer Presentation Delay

1.  Houd de DOM klein en simpel. In feite zal het voor een browser veel gemakkelijker zijn om een pagina met weinig en simpele niet-geneste DOM-elementen (html nodes) te renderen dan om een pagina met veel geneste DOM-nodes te renderen.
   
2. Gebruik content-visibility om off-screen content lui te renderen (lazy-render).  Content-visibility zal het renderen van zichtbare delen van de pagina versnellen door het renderen van off-screen content uit te stellen door die off-screen content just-in-time te renderen.