Core/Dash-dimensjon: Inputtype (INP)

Dimensjon: Inputtype INP (inpit)

Dimensjonen Inputtype (INP) registrerer DOM-hendelsestypen som utløste den aller verste interaksjonen under et brukerbesøk på siden. Verdien er det rå hendelsesnavnet fra nettleserens Event Timing API: click, keydown, pointerdown, pointerup, keypress og noen få andre.

INP er en metrikk for verste tilfelle. Den beregner ikke gjennomsnitt av interaksjoner. Den finner den ene interaksjonen som tok lengst tid fra input til neste paint, og rapporterer denne varigheten. Inputtype-dimensjonen forteller deg nøyaktig hva brukeren gjorde i det øyeblikket. Det er forskjellen på å vite at «INP er 450 ms» og å vite at «INP er 450 ms fordi brukeren skrev i søkefeltet ditt».

Event Timing API 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 enkeltstående hendelseshåndtereren i denne gruppen bestemmer interaksjonslatensen. CoreDash registrerer hendelsestypen til den lengste håndtereren, altså den som gjorde interaksjonen treg.

Hvorfor inputtype er viktig for INP

Hver inputtype kan knyttes til en bestemt del av JavaScript-kodebasen din. Hvis du ser keydown som den dominerende inputtypen på en side med dårlig INP, vet du umiddelbart at problemet ligger i tastetrykkhåndtererne dine: autofullfør, søk-mens-du-skriver, eller skjemavalidering som kjører ved hvert tastetrykk. Hvis du ser click, ligger problemet i knapp- og lenkehåndtererne dine: navigasjonslogikk, tilstandsoppdateringer, åpning av modaler, eller analysekall som kjører synkront.

Uten denne dimensjonen starter en INP-undersøkelse med profileringsøkter, reproduksjonstrinn og gjetting på hvilken interaksjon brukeren på 75. persentil prøvde å utføre. Med inputtype-dimensjonen går du rett til den relevante håndtereren. Tidsbesparelsen er reell.

Inputtypen avdekker også plattformforskjeller. Et nettsted med mye tastaturnavigasjon fra superbrukere vil ha en høy andel keydown-hendelser som gir dårlig INP. Et produkt som hovedsakelig brukes på mobil, vil vise at pointerdown dominerer. Samme side, samme INP-score, men ulike håndterere må fikses avhengig av hvem brukerne dine faktisk er.

Inputtypene

click og pointerdown

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

Click-håndterere er der det meste av tungt, synkront JavaScript-arbeid foregår. Et enkelt klikk på et navigasjonselement kan utløse tilstandsoppdateringer, DOM-mutasjoner, analysehendelser og en ny rendering – alt i én og samme oppgave. Hvert millisekund med synkront arbeid i en click-håndterer er et ekstra millisekund lagt til INP.

Løsningen for trege click-håndterere er å dele opp oppgavene. Bruk <code>scheduler.yield()</code> til å dele håndtereren inn i mindre oppgaver, slik at nettleseren kan rendre innimellom. Flytt ikke-kritisk arbeid som analysekall til 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 paint. Alt annet kan vente.

keydown

Tastatur-input står for omtrent 15 % av de verste INP-hendelsene i CoreDash-dataene, men det gir noen av de mest ekstreme resultatene. Årsaken er frekvens: En bruker som skriver i et søkefelt, utløser keydown ved hvert eneste tastetrykk. Hvis håndtereren din tar 200 ms, opplever brukeren 200 ms forsinkelse etter hver karakter som testes inn. Et søk på 10 tegn gir dermed 2 sekunder med akkumulert blokkeringstid.

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

Standardløsningene er debouncing og avlastning. Bruk debouncing på søkehåndtereren slik at den bare kjører når brukeren tar en pause i skrivingen, typisk etter 200 til 300 millisekunder. Ved mer kompleks databehandling, som fuzzy-søk i et stort lokalt datasett, bør du flytte beregningen til en Web Worker slik at main thread holdes ledig til å rendre neste ramme etter hver keydown-hendelse.

pointerup

Pointer up-hendelser utgjør omtrent 8 % av de verste INP-tilfellene i CoreDash-dataene. pointerup utløses på slutten av en berørings- eller klikksekvens, etter pointerdown. Enkelte rammeverk og UI-biblioteker knytter den primære «klikk»-oppførselen til pointerup i stedet for click, noe som flytter håndtereren tidligere i interaksjonslivssyklusen.

Når pointerup dukker opp som den dominerende inputtypen, er undersøkelsen den samme som for click-håndterere: Finn ut hvilken JavaScript som kjører i håndtereren, og skill arbeidet som må blokkere neste paint fra arbeid som kan utsettes. Skillet fra click er vanligvis en avgjørelse på rammeverksnivå, ikke applikasjonsnivå. Løsningen kan derfor kreve at du justerer hvordan komponentbiblioteket håndterer binding av interaksjoner.

Arbeidsflyt for feilsøking

1. Filtrer etter inputtype i CoreDash: Åpne INP-fordelingen for den trege nettadressen (URL), og sjekk hvilken inputtype som dominerer de verste interaksjonene. Hvis én type står for over halvparten av de dårlige INP-hendelsene, starter du der. Fordelingen forteller deg hvor du bør bruke tid på profilering.
2. Reproduser med riktig interaksjon: Åpne Chrome DevTools, aktiver Performance-profilering, og utfør nøyaktig den interaksjonstypen som vises i CoreDash. En side dominert av keydown bør testes ved å skrive. En side dominert av click bør testes med museklikk på elementene brukerne interagerer med. Ta opp sporingen og identifiser long tasks i main thread som utløses umiddelbart etter input-hendelsen.
3. Implementer den spesifikke løsningen og verifiser: Legg til debouncing og profiler på nytt ved keydown-problemer. For click-problemer legger du inn kall til scheduler.yield() ved logiske avbruddspunkter i håndtereren. Deploy til et testmiljø, bruk WebPageTest med interaksjonsskripting eller Performance-panelet i Chrome DevTools, og bekreft at oppgavens varighet reduseres før utrulling.

Tekniske tommelfingerregler

• keydown dominerer den dårlige INP-en: Legg til debouncing på alle søke- og autofullfør-håndterere. En forsinkelse på 200 ms er et vanlig utgangspunkt. Hvis beregningen er tung selv med denne forsinkelsen, må du flytte den bort fra main thread med en Web Worker.
• click eller pointerdown dominerer: Håndtererne dine gjør for mye synkront arbeid før nettleseren kan tegne (paint). Gå gjennom alle click-håndterere på den trege nettadressen. Fjern synkrone analysekall. Del opp flertrinnslogikk med scheduler.yield() mellom trinnene.
• pointerup dominerer: Sjekk om rammeverket ditt binder interaksjonslogikk til pointerup i stedet for click. Løsningen er vanligvis den samme som for click-håndterere, men inngangspunktet i kodebasen er et annet.
• Blandet fordeling uten tydelig vinner: Problemet skyldes ikke én enkelt interaksjonstype. Profiler de tre tregeste enkeltinteraksjonene på tvers av alle typer, og løs dem i rekkefølge etter effekt. Ikke optimaliser på generelt grunnlag.

Inputtype er et rutesignal. Den forteller deg ikke hva som er tregt, men hvor du skal lete. Når du vet om brukerne klikker, skriver eller trykker når INP svikter, blir hvert neste steg i undersøkelsen raskere og mer målrettet.