Core/Dash Dimension: Input Type (INP)

Dimension: Input Type INP (inpit)

Input Type (INP)-dimensionen registrerer den DOM-hændelsestype, der udløste den enkelte værste interaktion under en brugers sidebesøg. Værdien er det rå hændelsesnavn fra browserens Event Timing API: click, keydown, pointerdown, pointerup, keypress og en håndfuld andre.

INP er en worst-case metrik. Den beregner ikke et gennemsnit af interaktioner. Den finder den ene interaktion, der tog længst tid fra input til næste paint, og rapporterer den varighed. Input type-dimensionen fortæller dig, hvad brugeren gjorde i det nøjagtige øjeblik. Det er forskellen mellem at vide "INP er 450ms" og at vide "INP er 450ms, fordi brugeren tastede i dit søgefelt".

Event Timing API'et grupperer relaterede hændelser i en enkelt logisk interaktion. Et tryk på en touchskærm udløser pointerdown, pointerup og click som en samlet gruppe. Den enkelte længste hændelseshåndtering inden for den gruppe bestemmer interaktionsforsinkelsen. CoreDash registrerer hændelsestypen for den længste håndtering, som er den, der gjorde interaktionen langsom.

Hvorfor Input Type betyder noget for INP

Hver input type kortlægges til en forskellig del af din JavaScript-kodebase. Hvis du ser keydown som den dominerende input type på en side med dårlig INP, ved du med det samme, at problemet ligger i dine tastetrykshåndteringer: autofuldførelse, søg-mens-du-taster, formularvalidering, der kører ved hvert tastetryk. Hvis du ser click, er problemet i dine knap- og linkhåndteringer: navigationslogik, tilstandsopdateringer, åbning af modaler, analytiske kald, der affyres synkront.

Uden denne dimension starter en INP-undersøgelse med profilering af sessioner, reproduktionstrin og gæt på, hvilken interaktion den 75. percentil-bruger forsøgte sig med. Med input type-dimensionen kan du springe direkte til den relevante håndtering. Tidsbesparelsen er reel.

Input type afslører også platformsforskelle. Et site med tung tastaturnavigation fra superbrugere vil vise en høj andel af keydown-hændelser, der driver dårlig INP. Et produkt, der primært bruges på mobil, vil vise pointerdown som dominerende. Den samme side, den samme INP-score, den samme rettelse anvendt på forskellige håndteringer afhængigt af, hvem dine brugere rent faktisk er.

Input typerne

click og pointerdown

Disse er de mest almindelige input typer i CoreDash-data og tegner sig for cirka 75% af de værste INP-hændelser. På desktop repræsenterer click, at en museknap slippes. På mobil udløser et tryk hele kæden: pointerdown affyres først, når fingeren rører skærmen, derefter pointerup, når den løftes, og derefter click til sidst. CoreDash registrerer, hvilken hændelse i den kæde, der havde den længste håndtering.

Klik-håndteringer er det primære sted for tungt synkront JavaScript-arbejde. Et enkelt klik på et navigationselement kan udløse tilstandsstyringsopdateringer, DOM-mutationer, analytiske hændelser og en re-render, alt sammen i den samme task. Hvert millisekund af synkront arbejde i en klik-håndtering er et millisekund lagt til INP.

Løsningen på langsomme klik-håndteringer er task-nedbrydning. Brug <code>scheduler.yield()</code> til at bryde håndteringen op i mindre tasks og lad browseren render mellem dem. Flyt ikke-kritisk arbejde, som analytiske kald, ind i en setTimeout med nul forsinkelse, eller udskyd dem helt til requestIdleCallback. Browseren behøver kun at fuldføre arbejde, der påvirker den visuelle respons før næste paint. Alt andet kan vente.

keydown

Tastaturinput tegner sig for cirka 15% af de værste INP-hændelser i CoreDash-data, men det producerer nogle af de mest grelle scores. Årsagen er hyppighed: en bruger, der taster i et søgefelt, udløser keydown ved hvert eneste tastetryk. Hvis din håndtering tager 200ms, oplever brugeren 200ms forsinkelse efter hvert tegn, de taster. En søgestreng på 10 tegn bliver til 2 sekunders akkumuleret blokeringstid.

De typiske syndere er søg-mens-du-taster-implementeringer, der affyrer synkrone API-anmodninger eller kører dyr DOM-diffing ved hvert tastetryk, samt formularvalidering, der gentjekker hele formularen ved hvert tastetryk. Disse mønstre fungerer fint i lille skala, men bryder sammen under virkelige brugerforhold.

Standardrettelserne er debouncing og offloading. Debounce din søgehåndtering, så den kun affyres, efter brugeren holder pause med at taste, typisk 200 til 300 millisekunder. Til mere kompleks behandling som fuzzy-søgning på tværs af et stort lokalt datasæt, bør du flytte beregningen til en Web Worker, så main thread forbliver fri til at render den næste frame efter hver keydown-hændelse.

pointerup

Pointer up-hændelser repræsenterer cirka 8% af de værste INP-tilfælde i CoreDash-data. pointerup affyres i slutningen af en berørings- eller kliksekvens, efter pointerdown. Nogle frameworks og UI-biblioteker binder deres primære "klik"-adfærd til pointerup i stedet for click, hvilket flytter håndteringen tidligere i interaktionens livscyklus.

Når pointerup dukker op som den dominerende input type, er undersøgelsen den samme som for klik-håndteringer: find ud af, hvilket JavaScript der kører i håndteringen, og adskil det arbejde, der absolut skal blokere for næste paint, fra arbejde, der kan udskydes. Forskellen fra click er normalt en beslutning på framework-niveau, ikke en beslutning på applikationsniveau, så rettelsen kan indebære at justere, hvordan komponentbiblioteket håndterer interaktionsbinding.

Fejlfindingsworkflow

1. Filtrer efter input type i CoreDash: Åbn INP-nedbrydningen for en fejlende URL og tjek, hvilken input type der dominerer de værste interaktioner. Hvis én type tegner sig for mere end halvdelen af dine dårlige INP-hændelser, så start der. Fordelingen fortæller dig, hvor du skal bruge din profileringstid.
2. Reproducer med den rigtige interaktion: Åbn Chrome DevTools, aktivér Performance-profilering, og udfør den nøjagtige interaktionstype vist i CoreDash. En keydown-domineret side bør testes ved at taste. En click-domineret side bør testes med museklik på de elementer, dine brugere interagerer med. Optag tracen og identificer de lange tasks i Main thread, der affyres umiddelbart efter inputhændelsen.
3. Anvend den type-specifikke rettelse og bekræft: For keydown-problemer, tilføj debouncing og re-profiler. For click-problemer, tilføj scheduler.yield()-kald ved logiske brydepunkter i håndteringen. Deploy til et testmiljø, brug WebPageTest med interaktionsscripting eller Chrome DevTools Performance-panelet, og bekræft, at task-varigheden falder før du udgiver.

Tommelfingerregel for udvikling

• keydown dominerer din dårlige INP: Tilføj debouncing til alle søge- og autofuldførelseshåndteringer. 200ms forsinkelse er et standardudgangspunkt. Hvis beregningen er dyr selv ved den forsinkelse, så flyt den væk fra main thread med en Web Worker.
• click eller pointerdown dominerer: Dine håndteringer udfører for meget synkront arbejde, før browseren kan paint. Gennemgå hver klik-håndtering på den fejlende URL. Fjern synkrone analytiske kald. Bryd flertrinslogik op med scheduler.yield() mellem trinnene.
• pointerup dominerer: Tjek om dit framework binder interaktionslogik til pointerup i stedet for click. Rettelsen er normalt den samme som for klik-håndteringer, men startpunktet i kodebasen er anderledes.
• Blandet fordeling uden en klar vinder: Problemet er ikke én interaktionstype. Profiler de tre langsommeste individuelle interaktioner på tværs af alle typer og håndtér dem i rækkefølge efter deres indvirkning. Optimer ikke i det abstrakte.

Input Type er et rutesignal. Det fortæller dig ikke, hvad der er langsomt. Det fortæller dig, hvor du skal lede. Når du ved, om dine brugere klikker, taster eller trykker (tapper), når INP bryder sammen, bliver hvert efterfølgende undersøgelsestrin hurtigere og mere målrettet.