Core/Dash Dimensie: Input Type (INP)

Dimensie: Input Type INP (inpit)

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

INP is een worst-case-metriek. Het middelt interacties niet. Het vindt de ene interactie die het langst duurde van input tot de volgende paint en rapporteert die duur. De Input Type-dimensie vertelt je wat de gebruiker op dat exacte moment aan het doen was. Dat is het verschil tussen weten dat "INP 450ms is" en weten dat "INP 450ms is omdat de gebruiker in je zoekveld typte."

De Event Timing API groepeert gerelateerde events in een enkele logische interactie. Een tik op een touchscreen triggert pointerdown, pointerup en click als één groep. De langste individuele eventhandler binnen die groep bepaalt de interactielatency. CoreDash registreert het eventtype van de langste handler: degene die de interactie traag maakte.

Waarom Input Type belangrijk is voor INP

Elk input type mapt naar een ander deel van je JavaScript-codebase. Als je keydown ziet als het dominante input type op een pagina met een slechte INP, weet je meteen dat het probleem in je toetsaanslaghandlers zit: autocomplete, search-as-you-type of formuliervalidatie die bij elke toetsaanslag draait. Als je click ziet, ligt het probleem in je knop- en linkhandlers: navigatielogica, state-updates, het openen van modals of analytics-calls die synchroon vuren.

Zonder deze dimensie begint een INP-onderzoek met profileringssessies, reproductiestappen en gissen naar welke interactie de gebruiker op het 75e percentiel probeerde uit te voeren. Met de Input Type-dimensie ga je direct naar de relevante handler. De tijdwinst is reëel.

Input type laat ook platformverschillen zien. Een site met veel toetsenbordnavigatie door power users zal een groot aandeel keydown-events tonen die zorgen voor een slechte INP. Een product dat voornamelijk op mobiel wordt gebruikt, zal gedomineerd worden door pointerdown. Dezelfde pagina, dezelfde INP-score, dezelfde fix toegepast op verschillende handlers, afhankelijk van wie je gebruikers daadwerkelijk zijn.

De inputtypes

click en pointerdown

Dit zijn de meest voorkomende inputtypes in de data van CoreDash, goed voor ongeveer 75% van de slechtste INP-events. Op desktop vertegenwoordigt click het loslaten van de muisknop. Op mobiel triggert een tik de volledige keten: pointerdown vuurt eerst wanneer de vinger het scherm raakt, daarna pointerup wanneer deze omhoog gaat, en tot slot click. CoreDash registreert welk event in die keten de langste handler had.

Click-handlers zijn de belangrijkste plek voor zwaar synchroon JavaScript-werk. Een enkele click op een navigatie-item kan state-management-updates, DOM-mutaties, analytics-events en een re-render triggeren, allemaal binnen dezelfde taak. Elke milliseconde aan synchroon werk in een click-handler is een milliseconde die wordt opgeteld bij de INP.

De oplossing voor trage click-handlers is taakdecompositie. Gebruik <code>scheduler.yield()</code> om de handler op te breken in kleinere taken en de browser tussendoor te laten renderen. Verplaats niet-kritiek werk zoals analytics-calls naar een setTimeout met een vertraging van nul, of stel ze volledig uit met requestIdleCallback. De browser hoeft voor de volgende paint alleen het werk te voltooien dat invloed heeft op de visuele respons. Al het andere kan wachten.

keydown

Toetsenbord-input is goed voor ongeveer 15% van de slechtste INP-events in de data van CoreDash, maar veroorzaakt enkele van de meest extreme scores. De reden is frequentie: een gebruiker die in een zoekveld typt, triggert keydown bij elke afzonderlijke toetsaanslag. Als je handler 200ms duurt, ervaart de gebruiker 200ms vertraging na elk getypt karakter. Een zoekopdracht van 10 tekens wordt zo 2 seconden aan opgebouwde blokkeringstijd.

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

De standaardoplossingen zijn debouncing en offloading. Debounce je zoekhandler zodat deze pas vuurt nadat de gebruiker stopt met typen, meestal na 200 tot 300 milliseconden. Voor complexere verwerkingen, zoals fuzzy search in een grote lokale dataset, verplaats je de berekening naar een Web Worker zodat de main thread vrij blijft om het volgende frame te renderen na elk keydown-event.

pointerup

Pointer up-events vertegenwoordigen ongeveer 8% van de slechtste INP-gevallen in de data van CoreDash. pointerup vuurt aan het einde van een touch- of click-reeks, na pointerdown. Sommige frameworks en UI-bibliotheken binden hun primaire "click"-gedrag aan pointerup in plaats van click, waardoor de handler naar een eerder moment in de interactie-lifecycle verschuift.

Wanneer pointerup naar voren komt als het dominante inputtype, is het onderzoek hetzelfde als bij click-handlers: achterhaal welke JavaScript er in de handler draait en scheid het werk dat de volgende paint moet blokkeren van het werk dat kan worden uitgesteld. Het onderscheid met click is meestal een beslissing op framework-niveau, niet op applicatieniveau, dus de oplossing kan liggen in het aanpassen van hoe de componentenbibliotheek omgaat met interaction binding.

Debugging-workflow

1. Filter op inputtype in CoreDash: Open de INP-uitsplitsing voor een falende URL en controleer welk inputtype de slechtste interacties domineert. Als één type verantwoordelijk is voor meer dan de helft van je slechte INP-events, begin dan daar. De verdeling vertelt je waar je je profileringstijd aan moet besteden.
2. Reproduceer met de juiste interactie: Open Chrome DevTools, schakel Performance-profiling in en voer exact het type interactie 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 je gebruikers interactie hebben. Neem de trace op en identificeer de long tasks in de main thread die direct na het input-event vuren.
3. Pas de typespecifieke fix toe en verifieer: Voeg voor keydown-problemen debouncing toe en profileer opnieuw. Voeg voor click-problemen scheduler.yield()-calls toe op logische breekpunten in de handler. Deploy naar een testomgeving, gebruik WebPageTest met interaction scripting of het Chrome DevTools Performance-paneel, en bevestig dat de taakduur daalt voordat je live gaat.

Vuistregels voor engineers

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

Input Type is een routeringssignaal. Het vertelt je niet wat er traag is, het vertelt je waar je moet zoeken. Zodra je weet of je gebruikers klikken, typen of tikken wanneer de INP faalt, wordt elke volgende stap in het onderzoek sneller en gerichter.