Core/Dash-dimensjon: Input Type (INP)

Dimensjon: Input Type INP (inpit)

Input Type (INP)-dimensjonen registrerer DOM-hendelsestypen som utløste den desidert verste interaksjonen under en brukers sidebesøk. Verdien er det rå hendelsesnavnet fra nettleserens Event Timing API: click, keydown, pointerdown, pointerup, keypress, og en håndfull andre.

INP er en worst-case-metrikk. Den gjennomsnittsberegner ikke interaksjoner. Den finner den ene interaksjonen som tok lengst tid fra inndata til neste opptegning (next paint) og rapporterer den varigheten. Input Type-dimensjonen forteller deg hva brukeren gjorde i det nøyaktige øyeblikket. Det er forskjellen mellom å vite at "INP er 450ms" og å vite at "INP er 450ms fordi brukeren skrev i søkefeltet ditt."

Event Timing API-et grupperer relaterte hendelser til én enkelt logisk interaksjon. Et trykk på en berøringsskjerm utløser pointerdown, pointerup og click som én gruppe. Den lengste hendelseshåndtereren (event handler) innenfor den gruppen bestemmer interaksjonsforsinkelsen. CoreDash registrerer hendelsestypen til den lengste håndtereren, som er den som gjorde interaksjonen treg.

Hvorfor Input Type er viktig for INP

Hver inndatatype (input type) kartlegges til en annen del av JavaScript-kodebasen din. Hvis du ser keydown som den dominerende inndatatypen på en side med dårlig INP, vet du umiddelbart at problemet ligger i tastehåndtererne dine: autofullfør, søk-mens-du-skriver, skjemavalidering som kjører på hvert tastetrykk. Hvis du ser click, er problemet i knappe- og lenkehåndtererne dine: navigasjonslogikk, tilstandsoppdateringer, modalåpninger, analyse-kall som avfyres synkront.

Uten denne dimensjonen starter en INP-undersøkelse med profileringsøkter, reproduksjonstrinn og gjetting på hvilken interaksjon brukeren i 75-persentilen forsøkte på. Med Input Type-dimensjonen hopper du rett til den relevante håndtereren. Tidsbesparelsen er reell.

Input Type avslører også plattformforskjeller. Et nettsted med mye tastaturnavigasjon fra superbrukere vil vise en høy andel keydown-hendelser som driver dårlig INP. Et produkt som primært brukes på mobil vil vise at pointerdown dominerer. Samme side, samme INP-score, samme fiks brukt på forskjellige håndterere avhengig av hvem brukerne dine faktisk er.

Inndatatypene (Input Types)

click og pointerdown

Dette er de vanligste inndatatypene i CoreDash-data, og står for omtrent 75 % av de verste INP-hendelsene. På desktop representerer click at en museknapp slippes. På mobil utløser et trykk hele kjeden: pointerdown avfyres først når fingeren berører skjermen, deretter pointerup når den løftes, og til slutt click på slutten. CoreDash registrerer den hendelsen i den kjeden som hadde den lengste håndtereren.

Klikkhåndterere er den primære plasseringen for tungt synkront JavaScript-arbeid. Et enkelt klikk på et navigasjonselement kan utløse tilstandsoppdateringer (state management), DOM-mutasjoner, analysehendelser og en ny opptegning (re-render) i én og samme oppgave. Hvert millisekund med synkront arbeid i en klikkhåndterer er et millisekund lagt til INP.

Fiksen for trege klikkhåndterere er oppgavedekomponering. Bruk scheduler.yield() for å bryte opp håndtereren i mindre oppgaver, og la nettleseren tegne opp (render) i mellom dem. Flytt ikke-kritisk arbeid som analyse-kall inn i en setTimeout med null forsinkelse, eller utsett dem helt til requestIdleCallback. Nettleseren trenger bare å fullføre arbeid som påvirker den visuelle responsen før neste opptegning. Alt annet kan vente.

keydown

Tastaturinndata står for omtrent 15 % av de verste INP-hendelsene i CoreDash-data, men det produserer noen av de mest ekstreme resultatene. Årsaken er frekvens: en bruker som skriver i et søkefelt avfyrer keydown på hvert eneste tastetrykk. Hvis håndtereren din tar 200ms, opplever brukeren 200ms etterslep etter hvert tegn de skriver. Et søk på 10 tegn blir til 2 sekunder med akkumulert blokkeringstid.

De vanlige synderne er søk-mens-du-skriver-implementasjoner som avfyrer synkrone API-forespørsler eller kjører kostbar DOM-diffing på hvert tastetrykk, og skjemavalidering som sjekker hele skjemaet på nytt for hvert tastetrykk. Disse mønstrene fungerer fint i liten skala, men kollapser under reelle brukerforhold.

De standard fiksene er debouncing og avlastning. Bruk debounce på søkehåndtereren din slik at den kun avfyres etter at brukeren tar en pause i skrivingen, typisk 200 til 300 millisekunder. For mer kompleks prosessering som fuzzy-søk på tvers av et stort lokalt datasett, flytt beregningen til en Web Worker slik at hovedtråden forblir ledig til å tegne opp neste bilde (frame) etter hver keydown-hendelse.

pointerup

Pointer up-hendelser representerer omtrent 8 % av worst-case INP-tilfeller i CoreDash-data. pointerup avfyres på slutten av en berørings- eller klikksekvens, etter pointerdown. Noen rammeverk og UI-biblioteker binder sin primære "klikk"-oppførsel til pointerup i stedet for click, noe som flytter håndtereren tidligere i interaksjonslivssyklusen.

Når pointerup dukker opp som den dominerende inndatatypen, er undersøkelsen den samme som for klikkhåndterere: finn ut hvilken JavaScript som kjører i håndtereren og separer arbeidet som må blokkere neste opptegning (next paint) fra arbeid som kan utsettes. Forskjellen fra click er vanligvis en beslutning på rammeverksnivå, ikke på applikasjonsnivå, så fiksen kan innebære å justere hvordan komponentbiblioteket håndterer interaksjonsbinding.

Feilsøkingsarbeidsflyt

1. Filtrer etter Input Type i CoreDash: Åpne INP-nedbrytningen for en feilende URL og sjekk hvilken inndatatype som dominerer de verste interaksjonene. Hvis én type står for mer enn halvparten av dine dårlige INP-hendelser, start der. Fordelingen forteller deg hvor du bør bruke profileringstiden din.
2. Reproduser med riktig interaksjon: Åpne Chrome DevTools, aktiver Performance-profilering, og utfør nøyaktig den interaksjonstypen som vises i CoreDash. En keydown-dominert side bør testes ved å skrive. En click-dominert side bør testes med museklikk på elementene brukerne dine samhandler med. Ta opp sporingen og identifiser de lange oppgavene i hovedtråden som avfyres umiddelbart etter inndatahendelsen.
3. Bruk den typespesifikke fiksen og verifiser: For keydown-problemer, legg til debouncing og profiler på nytt. For click-problemer, legg til scheduler.yield()-kall på logiske brytepunkter i håndtereren. Distribuer til et testmiljø, bruk WebPageTest med interaksjonsskripting eller Chrome DevTools Performance-panelet, og bekreft at oppgavens varighet faller før du lanserer.

Tommelfingerregel for utviklere

• keydown dominerer din dårlige INP: Legg til debouncing på alle søke- og autofullfør-håndterere. 200ms forsinkelse er det standard startpunktet. Hvis beregningen er kostbar selv ved den forsinkelsen, flytt den vekk fra hovedtråden med en Web Worker.
• click eller pointerdown dominerer: Håndtererne dine gjør for mye synkront arbeid før nettleseren kan tegne opp. Revider hver klikkhåndterer på den feilende URL-en. Fjern synkrone analyse-kall. Bryt opp flertrinnslogikk med scheduler.yield() mellom trinnene.
• pointerup dominerer: Sjekk om rammeverket ditt binder interaksjonslogikk til pointerup i stedet for click. Fiksen er vanligvis den samme som for klikkhåndterere, men inngangspunktet i kodebasen er annerledes.
• Blandet fordeling uten en klar vinner: Problemet er ikke én interaksjonstype. Profiler de tre tregeste individuelle interaksjonene på tvers av alle typer og adresser dem i rekkefølge etter innvirkning. Ikke optimaliser i det abstrakte.

Input Type er et rutingsignal. Det forteller deg ikke hva som er tregt. Det forteller deg hvor du skal lete. Når du vet om brukerne dine klikker, skriver eller trykker når INP bryter sammen, blir hvert påfølgende undersøkelsestrinn raskere og mer målrettet.