Core/Dash Dimension: Input Type (INP)

Dimension: Input Type INP (inpit)

Input Type (INP)-dimensionen registrerer den DOM-eventtype, der udløste den absolut værste interaktion under en brugers besøg på siden. Værdien er det rå eventnavn fra browserens Event Timing API: click, keydown, pointerdown, pointerup, keypress og et par andre.

INP er en worst-case-metrik. Den beregner ikke gennemsnittet af interaktionerne. Den finder den 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 netop det øjeblik. Det er forskellen på at vide, at "INP er 450 ms", og at vide, at "INP er 450 ms, fordi brugeren skrev i dit søgefelt".

Event Timing API'et grupperer relaterede events i en enkelt logisk interaktion. Et tryk på en touchskærm udløser pointerdown, pointerup og click som én gruppe. Den enkelte længste event-handler i den gruppe bestemmer interaktionslatensen. CoreDash registrerer eventtypen for den længste handler, som er den, der gjorde interaktionen langsom.

Hvorfor Input Type betyder noget for INP

Hver inputtype mapper til en anden del af din JavaScript-kodebase. Hvis du ser keydown som den dominerende inputtype på en side med dårlig INP, ved du med det samme, at problemet ligger i dine tastaturhandlere: autocomplete, søg-mens-du-skriver, formularvalidering, der kører ved hvert tastetryk. Hvis du ser click, ligger problemet i dine knap- og linkhandlere: navigationslogik, tilstandsopdateringer, åbning af modaler, analytics-kald, der kører synkront.

Uden denne dimension starter en INP-undersøgelse med profileringssessioner, reproduktionstrin og gætteri om, hvilken interaktion brugeren i 75. percentil forsøgte. Med inputtype-dimensionen springer du direkte til den relevante handler. Tidsbesparelsen er reel.

Inputtype afslører også platformforskelle. Et site med udbredt tastaturnavigation fra power-brugere vil vise en høj andel af keydown-events, der giver dårlig INP. Et produkt, der primært bruges på mobilen, vil vise en dominans af pointerdown. Den samme side, den samme INP-score, den samme rettelse anvendt på forskellige handlere, alt efter hvem dine brugere rent faktisk er.

Inputtyperne

click og pointerdown

Disse er de mest almindelige inputtyper i CoreDash-data og står for cirka 75 % af de værste INP-events. På desktop repræsenterer click, at en museknap slippes. På mobilen udløser et tryk hele kæden: pointerdown udløses først, når fingeren rører skærmen, derefter pointerup, når den løftes, og til sidst click. CoreDash registrerer den event i kæden, der havde den længste handler.

Click-handlere er det primære sted for tungt, synkront JavaScript-arbejde. Et enkelt klik på et navigationselement kan udløse tilstandsopdateringer, DOM-mutationer, analytics-events og en re-rendering – alt sammen i den samme task. Hvert millisekund af synkront arbejde i en click-handler er et millisekund lagt oven i INP.

Løsningen på langsomme click-handlere er at opdele dine tasks. Brug <code>scheduler.yield()</code> til at bryde handleren op i mindre tasks, så browseren kan rendere indimellem. Flyt ikke-kritisk arbejde som analytics-kald ind i en setTimeout med nul forsinkelse, eller udskyd dem helt til requestIdleCallback. Browseren skal kun færdiggøre arbejde, der påvirker det visuelle svar, før næste paint. Alt andet kan vente.

keydown

Tastatur-input står for cirka 15 % af de værste INP-events i CoreDash-data, men det skaber nogle af de mest ekstreme scores. Årsagen er frekvensen: En bruger, der skriver i et søgefelt, udløser keydown ved hvert eneste tastetryk. Hvis din handler tager 200 ms, oplever brugeren 200 ms forsinkelse efter hvert tegn, de indtaster. En søgestreng på 10 tegn bliver til 2 sekunders akkumuleret blokeringstid.

De typiske syndere er søg-mens-du-skriver-implementeringer, der udløser synkrone API-kald eller kører tung DOM-diffing ved hvert tastetryk, samt formularvalidering, der tjekker hele formularen igen ved hvert tryk. Disse mønstre fungerer fint i mindre målestok, men bryder sammen under reelle brugerforhold.

Standardløsningerne er debouncing og offloading. Debounce din søge-handler, så den først udløses, når brugeren holder en pause i skrivningen, typisk efter 200 til 300 millisekunder. Ved mere kompleks databehandling, som f.eks. fuzzy-søgning i et stort lokalt datasæt, bør du flytte beregningen til en Web Worker, så main threaden forbliver fri til at rendere næste frame efter hvert keydown-event.

pointerup

Pointer up-events repræsenterer cirka 8 % af de værste INP-tilfælde i CoreDash-data. pointerup udløses i slutningen af en touch- eller click-sekvens, efter pointerdown. Nogle frameworks og UI-biblioteker binder deres primære "click"-adfærd til pointerup i stedet for click, hvilket flytter handleren tidligere hen i interaktionens livscyklus.

Når pointerup fremstår som den dominerende inputtype, er undersøgelsen den samme som for click-handlere: Find ud af, hvilket JavaScript der kører i handleren, og adskil det arbejde, der absolut skal blokere næste paint, fra det arbejde, der kan udskydes. Forskellen fra click er normalt en beslutning på framework-niveau, ikke på applikationsniveau, så løsningen kan indebære at justere, hvordan komponentbiblioteket håndterer interaktionsbinding.

Debugging-workflow

1. Filtrer efter inputtype i CoreDash: Åbn INP-opdelingen for en fejlende URL, og tjek, hvilken inputtype der dominerer de værste interaktioner. Hvis én type står for mere end halvdelen af dine dårlige INP-events, så start der. Fordelingen fortæller dig, hvor du skal bruge din profileringstid.
2. Reproducer med den rigtige interaktion: Åbn Chrome DevTools, aktiver Performance-profilering, og udfør præcis den interaktionstype, der vises i CoreDash. En side domineret af keydown bør testes ved at skrive. En side domineret af click bør testes med museklik på de elementer, dine brugere interagerer med. Optag en trace, og identificer de long tasks i main threaden, der kører umiddelbart efter input-eventen.
3. Anvend den typespecifikke rettelse, og verificer: Ved keydown-problemer skal du tilføje debouncing og profilere igen. Ved click-problemer skal du tilføje scheduler.yield()-kald ved logiske breakpoints i handleren. Deploy til et testmiljø, brug WebPageTest med interaktionsscripting eller Chrome DevTools' Performance-panel, og bekræft, at task-varigheden falder, før du shipper.

Tommelfingerregler for udviklere

• keydown dominerer din dårlige INP: Tilføj debouncing til alle søge- og autocomplete-handlere. En forsinkelse på 200 ms er det typiske udgangspunkt. Hvis beregningen er tung, selv med den forsinkelse, skal du flytte den væk fra main threaden med en Web Worker.
• click eller pointerdown dominerer: Dine handlere udfører for meget synkront arbejde, før browseren kan painte. Gennemgå alle click-handlere på den fejlende URL. Fjern synkrone analytics-kald. Opdel logik i flere trin med scheduler.yield() mellem trinnene.
• pointerup dominerer: Tjek, om dit framework binder interaktionslogik til pointerup i stedet for click. Løsningen er normalt den samme som for click-handlere, men indgangspunktet i kodebasen er et andet.
• Blandet fordeling uden en klar vinder: Problemet er ikke begrænset til én interaktionstype. Profiler de tre langsomste enkelte interaktioner på tværs af alle typer, og tag fat på dem i rækkefølge efter deres indvirkning. Optimer ikke i blinde.

Input Type er et routing-signal. Det fortæller dig ikke, hvad der er langsomt. Det fortæller dig, hvor du skal kigge hen. Når du først ved, om dine brugere klikker, taster eller tapper, når INP fejler, bliver hvert efterfølgende undersøgelsestrin hurtigere og mere målrettet.