Core/Dash-dimensie: Input Type (INP)

Dimensie: Input Type INP (inpit)

De dimensie Input Type (INP) registreert het DOM event type dat de allerergste interactie veroorzaakte tijdens het paginabezoek van een gebruiker. De waarde is de onbewerkte eventnaam van de Event Timing API van de browser: click, keydown, pointerdown, pointerup, keypress en een handvol andere.

INP is een worst-case metric. Het neemt geen gemiddelde van interacties. Het zoekt naar de ene interactie die het langst duurde van input tot de volgende weergave (next paint) en rapporteert die duur. De input type-dimensie vertelt u wat de gebruiker op dat exacte moment aan het doen was. Dat is het verschil tussen weten "INP is 450ms" en weten "INP is 450ms omdat de gebruiker in uw zoekveld typte."

De Event Timing API groepeert gerelateerde events in één logische interactie. Een tik op een touchscreen vuurt pointerdown, pointerup en click af als één groep. De langstdurende event-handler binnen die groep bepaalt de interactie-latentie. CoreDash registreert het event type van de langste handler, oftewel degene die de interactie traag maakte.

Waarom Input Type belangrijk is voor INP

Elk input type verwijst naar een ander deel van uw JavaScript-codebase. Als u keydown als het dominante input type ziet op een pagina met een slechte INP, weet u onmiddellijk dat het probleem in uw toetsaanslag-handlers zit: autocomplete, search-as-you-type, formuliervalidatie die bij elke druk op de knop draait. Als u click ziet, zit het probleem in uw knop- en link-handlers: navigatielogica, statusupdates, openen van modals, synchrone analytics-calls.

Zonder deze dimensie begint een INP-onderzoek met profiling-sessies, reproductiestappen en raden welke interactie de gebruiker in het 75e percentiel probeerde uit te voeren. Met de input type-dimensie slaat u dit over en gaat u direct naar de relevante handler. De tijdsbesparing is aanzienlijk.

Input type onthult ook platformverschillen. Een site met veel toetsenbordnavigatie door intensieve gebruikers zal een groot aandeel aan keydown-events tonen die een slechte INP veroorzaken. Bij een product dat voornamelijk op mobiel wordt gebruikt, zal pointerdown domineren. Dezelfde pagina, dezelfde INP-score, maar dezelfde oplossing wordt toegepast op verschillende handlers, afhankelijk van wie uw gebruikers werkelijk zijn.

De Input Types

click en pointerdown

Dit zijn de meest voorkomende input types in CoreDash-data, goed voor grofweg 75% van de slechtste INP-events. Op desktop staat click voor het loslaten van een muisknop. Op mobiel vuurt een tik de volledige keten af: pointerdown vuurt eerst wanneer de vinger het scherm raakt, vervolgens pointerup wanneer deze wordt opgetild, en ten slotte click aan het einde. CoreDash registreert welk event in die keten de langste handler had.

Click-handlers zijn de voornaamste locatie voor zwaar synchroon JavaScript-werk. Een enkele klik op een navigatie-item kan statusbeheerupdates, DOM-mutaties, analytics-events en een herweergave (re-render) activeren, allemaal in dezelfde taak. Elke milliseconde synchroon werk in een click-handler is een milliseconde toegevoegd aan INP.

De oplossing voor trage click-handlers is taakdecompositie. Gebruik <code>scheduler.yield()</code> om de handler in kleinere taken op te splitsen en de browser ertussen te laten renderen. Verplaats niet-kritiek werk zoals analytics-calls naar een setTimeout met nul vertraging, of stel ze volledig uit naar requestIdleCallback. De browser hoeft alleen het werk af te ronden dat de visuele reactie beïnvloedt vóór de volgende weergave. Al het andere kan wachten.

keydown

Toetsenbordinput is goed voor grofweg 15% van de slechtste INP-events in CoreDash-data, maar het produceert enkele van de meest schokkende scores. De reden is frequentie: een gebruiker die in een zoekveld typt, vuurt keydown af bij elke afzonderlijke toetsaanslag. Als uw handler 200ms in beslag neemt, ervaart de gebruiker 200ms vertraging na elk getypt teken. Een zoekopdracht van 10 tekens wordt zo 2 seconden aan opgebouwde blokkeringstijd.

De meest voorkomende boosdoeners zijn search-as-you-type-implementaties die bij elke toetsaanslag synchrone API-verzoeken afvuren of dure DOM-diffing uitvoeren, en formuliervalidatie die het hele formulier bij elke druk op een toets opnieuw controleert. Deze patronen werken prima op kleine schaal, maar bezwijken onder echte gebruikersomstandigheden.

De standaardoplossingen zijn debouncing en offloading. Debounce uw zoek-handler zodat deze pas afvuurt nadat de gebruiker stopt met typen, doorgaans 200 tot 300 milliseconden. Voor complexere verwerkingen zoals fuzzy search in een grote lokale dataset, verplaatst u de berekening naar een Web Worker, zodat de hoofdthread vrij blijft om het volgende frame na elk keydown-event te renderen.

pointerup

Pointer up-events vertegenwoordigen ongeveer 8% van de slechtste INP-gevallen in CoreDash-data. pointerup vuurt aan het einde van een aanraak- of klikreeks af, na pointerdown. Sommige frameworks en UI-bibliotheken koppelen hun primaire "klik"-gedrag aan pointerup in plaats van aan click, waardoor de handler vroeger in de levenscyclus van de interactie wordt geplaatst.

Wanneer pointerup opduikt als het dominante input type, is het onderzoek hetzelfde als voor click-handlers: zoek uit welk JavaScript er in de handler draait en scheid het werk dat de volgende weergave moet blokkeren van het werk dat kan worden uitgesteld. Het onderscheid met click is meestal een beslissing op framework-niveau, niet op applicatie-niveau, dus de oplossing kan het aanpassen inhouden van de manier waarop de componentenbibliotheek omgaat met interactie-binding.

Debugging Workflow

1. Filter op input type in CoreDash: Open de INP-breakdown voor een falende URL en controleer welk input type de slechtste interacties domineert. Als één type goed is voor meer dan de helft van uw slechte INP-events, begin dan daar. De verdeling vertelt u waar u uw profiling-tijd aan moet besteden.
2. Reproduceer met de juiste interactie: Open Chrome DevTools, schakel Performance profiling in en voer exact het interactietype uit dat in CoreDash wordt getoond. Een door keydown gedomineerde pagina moet worden getest door te typen. Een door click gedomineerde pagina moet worden getest met muisklikken op de elementen waarmee uw gebruikers interageren. Neem de trace op en identificeer de lange taken in de hoofdthread (Main thread) die onmiddellijk na het input-event afvuren.
3. Pas de type-specifieke oplossing toe en verifieer: Voeg voor keydown-problemen debouncing toe en voer opnieuw een profilering uit. Voor click-problemen voegt u scheduler.yield()-aanroepen toe op logische breekpunten in de handler. Implementeer naar een testomgeving, gebruik WebPageTest met interactiescripting of het Chrome DevTools Performance-paneel, en bevestig dat de taakduur daalt voordat u deze naar productie verzendt.

Vuistregel voor Engineers

• keydown domineert uw slechte INP: Voeg debouncing toe aan alle zoek- en autocomplete-handlers. 200ms vertraging is het standaard startpunt. Als de berekening zelfs met die vertraging duur is, verplaats deze dan weg van de hoofdthread met een Web Worker.
• click of pointerdown domineert: Uw handlers doen te veel synchroon werk voordat de browser kan weergeven (paint). Controleer elke click-handler op de falende URL. Verwijder synchrone analytics-calls. Breek logica uit meerdere stappen op met scheduler.yield() tussen de stappen in.
• pointerup domineert: Controleer of uw framework interactielogica bindt aan pointerup in plaats van aan click. De oplossing is meestal hetzelfde als voor click-handlers, maar het toegangspunt in de codebase is anders.
• Gemengde verdeling zonder duidelijke winnaar: Het probleem is niet één interactietype. Profileer de drie traagste individuele interacties over alle typen heen en pak ze aan in volgorde van impact. Optimaliseer niet in het abstracte.

Input Type is een richtingssignaal. Het vertelt u niet wat traag is. Het vertelt u wáár u moet kijken. Zodra u weet of uw gebruikers klikken, typen of tikken wanneer INP verslechtert, wordt elke volgende stap in het onderzoek sneller en gerichter.