Core/Dash Dimension: Inmatningstyp (INP)

Dimension: Inmatningstyp INP (inpit)

Dimensionen Inmatningstyp (INP) registrerar den DOM-händelsetyp som utlöste den enskilt sämsta interaktionen under en användares sidbesök. Värdet är det råa händelsenamnet från webbläsarens Event Timing API: click, keydown, pointerdown, pointerup, keypress och en handfull andra.

INP är ett mätvärde för värsta tänkbara scenario. Det beräknar inte ett genomsnitt av interaktioner. Det hittar den enda interaktionen som tog längst tid från inmatning till nästa rendering (paint) och rapporterar den varaktigheten. Dimensionen inmatningstyp berättar vad användaren gjorde i exakt det ögonblicket. Det är skillnaden mellan att veta att "INP är 450 ms" och att veta att "INP är 450 ms för att användaren skrev i ditt sökfält."

Event Timing API:et grupperar relaterade händelser till en enda logisk interaktion. Ett tryck på en pekskärm utlöser pointerdown, pointerup och click som en grupp. Den enskilt längsta händelsehanteraren inom den gruppen avgör interaktionens latens. CoreDash registrerar händelsetypen för den längsta hanteraren, vilket är den som gjorde interaktionen långsam.

Varför inmatningstyp spelar roll för INP

Varje inmatningstyp kartläggs mot en specifik del av din JavaScript-kodbas. Om du ser keydown som den dominerande inmatningstypen på en sida med dålig INP, vet du direkt att problemet ligger i dina tangenttryckningshanterare: autoslutförande, sök-medan-du-skriver, formulärvalidering som körs vid varje tangenttryckning. Om du ser click, ligger problemet i dina knapp- och länkhanterare: navigeringslogik, tillståndsuppdateringar, öppnande av modaler, analysanrop som utlöses synkront.

Utan denna dimension börjar en INP-undersökning med profileringssessioner, reproduktionssteg och gissningar om vilken interaktion den 75:e percentilanvändaren försökte utföra. Med dimensionen inmatningstyp hoppar du direkt till den relevanta hanteraren. Tidsbesparingen är påtaglig.

Inmatningstyp avslöjar också plattformsskillnader. En webbplats med tung tangentbordsnavigering från avancerade användare kommer att visa en hög andel keydown-händelser som driver dålig INP. En produkt som främst används på mobil kommer att visa att pointerdown dominerar. Samma sida, samma INP-poäng, samma åtgärd tillämpad på olika hanterare beroende på vilka dina användare faktiskt är.

Inmatningstyperna

click och pointerdown

Dessa är de vanligaste inmatningstyperna i CoreDash-data och står för ungefär 75 % av de händelser som har sämst INP. På dator representerar click att en musknapp släpps. På mobil utlöser ett tryck hela kedjan: pointerdown utlöses först när fingret rör vid skärmen, sedan pointerup när det lyfts, och till sist click i slutet. CoreDash registrerar vilken händelse i den kedjan som hade den längsta hanteraren.

Click-hanterare är den primära platsen för tungt synkront JavaScript-arbete. Ett enda klick på ett navigeringsobjekt kan utlösa uppdateringar av tillståndshantering, DOM-mutationer, analyshändelser och en omrendering i en och samma uppgift. Varje millisekund av synkront arbete i en click-hanterare är en millisekund adderad till INP.

Lösningen för långsamma click-hanterare är nedbrytning av uppgifter. Använd <code>scheduler.yield()</code> för att dela upp hanteraren i mindre uppgifter och låta webbläsaren rendera mellan dem. Flytta icke-kritiskt arbete, som analysanrop, till en setTimeout med noll fördröjning, eller skjut upp dem helt till requestIdleCallback. Webbläsaren behöver bara slutföra det arbete som påverkar den visuella responsen före nästa rendering. Allt annat kan vänta.

keydown

Tangentbordsinmatning står för ungefär 15 % av de händelser som har sämst INP i CoreDash-data, men de producerar några av de allra sämsta poängen. Anledningen är frekvens: en användare som skriver i ett sökfält utlöser keydown vid varje enskild tangenttryckning. Om din hanterare tar 200 ms, upplever användaren 200 ms lagg efter varje tecken de skriver. En sökfråga på 10 tecken blir 2 sekunder av ackumulerad blockeringstid.

De vanligaste bovarna är sök-medan-du-skriver-implementationer som utlöser synkrona API-anrop eller kör kostsam DOM-diffing vid varje tangenttryckning, samt formulärvalidering som kontrollerar hela formuläret på nytt vid varje nedtryckning. Dessa mönster fungerar bra i liten skala, men kollapsar under verkliga användarförhållanden.

Standardlösningarna är "debouncing" och avlastning. Tillämpa debouncing på din sökhanterare så att den bara utlöses efter att användaren pausat sitt skrivande, vanligtvis 200 till 300 millisekunder. För mer komplex bearbetning, som fuzzy-sökning över ett stort lokalt dataset, flytta beräkningen till en Web Worker så att huvudtråden förblir fri för att rendera nästa bildruta efter varje keydown-händelse.

pointerup

Pointer up-händelser representerar ungefär 8 % av fallen med sämst INP i CoreDash-data. pointerup utlöses i slutet av en touch- eller klicksekvens, efter pointerdown. Vissa ramverk och UI-bibliotek binder sitt primära "klick"-beteende till pointerup i stället för click, vilket flyttar hanteraren till en tidigare punkt i interaktionslivscykeln.

När pointerup dyker upp som den dominerande inmatningstypen är undersökningen densamma som för click-hanterare: hitta vilket JavaScript som körs i hanteraren och separera det arbete som måste blockera nästa rendering från arbete som kan skjutas upp. Skillnaden från click är oftast ett beslut på ramverksnivå, inte applikationsnivå, så åtgärden kan innebära att man justerar hur komponentbiblioteket hanterar interaktionsbindning.

Felsökningsarbetsflöde

1. Filtrera efter inmatningstyp i CoreDash: Öppna INP-nedbrytningen för en underkänd URL och kontrollera vilken inmatningstyp som dominerar de sämsta interaktionerna. Om en typ står för mer än hälften av dina dåliga INP-händelser, börja där. Fördelningen berättar för dig var du ska lägga din profileringstid.
2. Reproducera med rätt interaktion: Öppna Chrome DevTools, aktivera Performance-profilering och utför den exakta interaktionstypen som visas i CoreDash. En keydown-dominerad sida bör testas genom att skriva. En click-dominerad sida bör testas med musklick på de element som dina användare interagerar med. Spela in spårningen och identifiera de långa uppgifterna i huvudtråden som utlöses omedelbart efter inmatningshändelsen.
3. Tillämpa den typspecifika åtgärden och verifiera: För keydown-problem, lägg till debouncing och profilera om. För click-problem, lägg till scheduler.yield()-anrop vid logiska brytpunkter i hanteraren. Driftsätt till en testmiljö, använd WebPageTest med interaktionsskript eller Chrome DevTools Performance-panel, och bekräfta att uppgiftens varaktighet sjunker innan du lanserar.

Tumregler för utvecklare

• keydown dominerar din dåliga INP: Lägg till debouncing för alla sök- och autoslutförandehanterare. En fördröjning på 200 ms är standardutgångspunkten. Om beräkningen är kostsam även vid den fördröjningen, flytta den bort från huvudtråden med en Web Worker.
• click eller pointerdown dominerar: Dina hanterare utför för mycket synkront arbete innan webbläsaren hinner rendera. Granska varje click-hanterare på den underkända URL:en. Ta bort synkrona analysanrop. Bryt upp flerstegslogik med scheduler.yield() mellan stegen.
• pointerup dominerar: Kontrollera om ditt ramverk binder interaktionslogik till pointerup istället för click. Lösningen är oftast densamma som för click-hanterare, men ingångspunkten i kodbasen är annorlunda.
• Blandad fördelning utan någon tydlig vinnare: Problemet är inte en enda interaktionstyp. Profilera de tre långsammaste enskilda interaktionerna över alla typer och åtgärda dem i ordning efter deras påverkan. Optimera inte i abstraktion.

Inmatningstyp är en riktningssignal. Den talar inte om för dig vad som är långsamt. Den talar om för dig var du ska leta. När du vet om dina användare klickar, skriver eller trycker när INP brister, blir varje efterföljande undersökningssteg snabbare och mer målinriktat.