Interaktion till nästa färg (INP)

Interaktion till nästa målning mäter hur snabbt en sida reagerar visuellt på användarinmatning och rapporterar ett värde som representerar de värsta interaktionslatenserna som upplevts under ett besök. Den ersatte första inmatningsfördröjning som ett svarsmått för Core Web Vitals i mars 2024, och förändringen var betydande: där det äldre måttet bara registrerade fördröjningen innan bearbetningen började vid den första interaktionen, mäter detta hela varaktigheten från inmatning via bearbetning till nästa bildruta som målas, över alla interaktioner i sessionen.

Den skillnaden är viktig eftersom det tidigare måttet var ett bra val för många webbplatser. En sida kunde registrera en utmärkt fördröjning vid första inmatningen samtidigt som den förblev långsam hela tiden, eftersom måttet ignorerade hur lång tid det tog för händelsehanteraren att köra och hur lång tid det sedan tog för webbläsaren att rendera resultatet, och eftersom det bara tittade på en interaktion. Webbplatser som verkade responsiva med det gamla måttet gör det ofta inte med det nya, särskilt applikationer med en sida och alla gränssnitt med tung klientsideslogik.

Det rapporterade värdet härleds från de längsta observerade interaktionerna, med en tillåtelse för extremvärden på sidor med många interaktioner, och Googles publicerade tröskelvärde behandlar 200 millisekunder eller mindre som bra vid den sjuttiofemte percentilen av verkliga användarupplevelser. Eftersom det fångar hela vägen från inmatning till ritning kan dåliga poäng uppstå vid flera punkter: långa uppgifter på huvudtråden som blockerar webbläsaren från att hantera händelsen, händelsehanterare som utför överdrivet mycket arbete synkront, layoutförstöring orsakad av sammanflätade läs- och skrivstilar och dyr rendering efter tillståndsändringar.

Diagnosen pekar vanligtvis på JavaScript-körning snarare än nätverksförhållanden, vilket skiljer denna mätmetrik från laddningsmått. Vanliga orsaker inkluderar stora monolitiska paket som körs på huvudtråden, tredjepartsskript som kör godtyckligt arbete under interaktion, omrenderingar av ramverk som berör mycket mer av trädet än vad ändringen kräver och hanterare som utför synkron beräkning som kan skjutas upp eller flyttas från huvudtråden. Långa uppgifter är den underliggande mekanismen i de flesta fall, eftersom webbläsaren inte kan svara på inmatning medan en uppgift körs.

Åtgärd följer diagnosen. Att dela upp långa uppgifter i mindre delar med explicit yielding låter webbläsaren hantera inmatning mellan dem. Att skjuta upp icke-nödvändigt arbete till efter den visuella uppdateringen, så att användaren ser ett svar omedelbart, åtgärdar det vanligaste mönstret. Att minska mängden JavaScript som skickas, granska tredjepartsskript för huvudtrådskostnader, virtualisera långa listor och flytta tung beräkning till en arbetare åtgärdar var och en specifika orsaker. Att ge omedelbar visuell feedback för långsamma operationer förbättrar inte det uppmätta värdet men förändrar hur fördröjningen upplevs.

Tredjepartsskript förtjänar särskild granskning eftersom de är en vanlig orsak och ligger utanför teamets direkta kontroll. Chattwidgetar, samtyckeshanterare, analysbibliotek, personaliseringsverktyg och reklamskript körs alla på huvudtråden och kan uppta den just under de ögonblick en besökare försöker interagera. Att granska huvudtrådskostnaden för varje tredje part, helst genom att mäta sidan med och utan den, ger en konkret lista över vad varje leverantör kostar i responsivitetstermer. Den siffran gör avvägningen diskussionsbar med de team som begärde varje verktyg, vilket vanligtvis är en mer produktiv väg än att försöka optimera applikationskoden kring ett skript som förbrukar det mesta av den tillgängliga budgeten.

Eftersom mätvärdet styrs av applikationskod snarare än av tillgångsleverans, kräver förbättringar vanligtvis ingenjörsarbete snarare än konfiguration. I praktiken ligger det i gränslandet mellan webbprestanda och produktutveckling, och det är särskilt viktigt för interaktiva handels- och bokningsgränssnitt, där icke-responsiva filtreringar, konfigurationer och interaktioner i varukorgen producerar övergivna kunder som visas i analyser som vanligt bortfall utan uppenbar orsak.