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 interaktion som tog längst tid från inmatning till nästa uppritning (next paint) och rapporterar den varaktigheten. Dimensionen inmatningstyp talar om vad användaren gjorde i just det ögonblicket. Det är skillnaden mellan att veta "INP är 450 ms" och att veta "INP är 450 ms eftersom användaren skrev i ditt sökfält."

Event Timing API 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 interaktionsfördröjningen. CoreDash registrerar händelsetypen för den längsta hanteraren, vilket är den som gjorde interaktionen långsam.

Varför inmatningstyp är viktigt för INP

Varje inmatningstyp är kopplad till en specifik del av din JavaScript-kodbas. Om du ser att keydown är den dominerande inmatningstypen på en sida med dåligt INP, vet du omedelbart 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, modalfönster som öppnas, analysanrop (analytics) som körs synkront.

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

Inmatningstypen avslöjar även plattformsskillnader. En webbplats med omfattande tangentbordsnavigering från avancerade användare kommer att visa en hög andel keydown-händelser som driver upp ett dåligt INP. En produkt som främst används på mobila enheter kommer att domineras av pointerdown. Samma sida, samma INP-poäng, men samma åtgärd tillämpas 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 sämsta INP-händelserna. På desktop representerar click att en musknapp släpps upp. På mobila enheter utlöser ett tryck hela kedjan: pointerdown utlöses först när fingret vidrör skärmen, sedan pointerup när det lyfts, och till sist click i slutet. CoreDash registrerar den händelse i den kedjan som hade den längsta hanteraren.

Klickhanterare är den primära platsen för tungt synkront JavaScript-arbete. Ett enda klick på ett navigeringsobjekt kan utlösa tillståndshanteringsuppdateringar, DOM-mutationer, analyshändelser och en omrendering – allt i samma uppgift. Varje millisekund av synkront arbete i en klickhanterare är en millisekund som läggs till i INP.

Lösningen för långsamma klickhanterare är uppgiftsuppdelning. 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, så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 innan nästa uppritning (next paint). Allt annat kan vänta.

keydown

Tangentbordsinmatning står för ungefär 15 % av de sämsta INP-händelserna i CoreDash-data, men det ger upphov till några av de mest flagranta resultaten. Anledningen är frekvensen: 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 till 2 sekunder av ackumulerad blockeringstid.

De vanligaste bovarna är sök-medan-du-skriver-implementationer som skickar synkrona API-förfrågningar eller kör dyra DOM-diffar vid varje tangenttryckning, samt formulärvalidering som omkontrollerar hela formuläret vid varje nedtryckt tangent. Dessa mönster fungerar bra i liten skala, men kollapsar under verkliga användarförhållanden.

Standardåtgärderna är debouncing och avlastning. Tillämpa debouncing på din sökhanterare så att den endast utlöses efter att användaren slutat skriva, typiskt sett efter 200 till 300 millisekunder. För mer komplex bearbetning, som fuzzy-sökning över en stor lokal datamängd, flytta beräkningen till en Web Worker så att huvudtråden (main thread) förblir ledig för att rendera nästa bildruta efter varje keydown-händelse.

pointerup

Pointer up-händelser representerar cirka 8 % av de sämsta INP-fallen 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 istället för click, vilket flyttar hanteraren tidigare i interaktionslivscykeln.

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

Felsökningsarbetsflöde

1. Filtrera efter inmatningstyp i CoreDash: Öppna INP-uppdelningen för en underkänd URL och kontrollera vilken inmatningstyp som dominerar de värsta 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 talar om för dig var du ska lägga din profileringstid.
2. Reproducera med rätt interaktion: Öppna Chrome DevTools, aktivera prestandaprofilering (Performance) och utför exakt den interaktionstyp 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 (trace) och identifiera de långa uppgifterna i huvudtråden (Main thread) 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 i en testmiljö, använd WebPageTest med interaktionsskript eller fliken Performance i Chrome DevTools, och bekräfta att uppgiftens varaktighet minskar innan du publicerar.

Tumregel för utvecklare

• keydown dominerar ditt dåliga INP: Lägg till debouncing på alla sök- och autoslutförandehanterare. En fördröjning på 200 ms är en bra standardutgångspunkt. Om beräkningen är resurskrävande ä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 kan rita upp (paint). Granska varje klickhanterare 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. Åtgärden är vanligtvis densamma som för klickhanterare, men ingångspunkten i kodbasen är en annan.
• Blandad fördelning utan någon tydlig vinnare: Problemet ligger inte i en enda interaktionstyp. Profilera de tre långsammaste enskilda interaktionerna över alla typer och åtgärda dem i ordning efter påverkan. Optimera inte abstrakt.

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 väl vet om dina användare klickar, skriver eller trycker (tapping) när INP brister, blir varje efterföljande undersökningssteg snabbare och mer målinriktat.