Core/Dash Dimension: Input Type (INP)

Dimension: Input Type INP (inpit)

The Input Type (INP) dimension records the DOM event type that triggered the single worst interaction during a user's page visit. The value is the raw event name from the browser's Event Timing API: click, keydown, pointerdown, pointerup, keypress, and a handful of others.

INP is a worst-case metric. It does not average interactions. It finds the one interaction that took longest from input to next paint and reports that duration. The input type dimension tells you what the user was doing at that exact moment. That is the difference between knowing "INP is 450ms" and knowing "INP is 450ms because the user typed into your search field."

The Event Timing API groups related events into a single logical interaction. A tap on a touchscreen fires pointerdown, pointerup, and click as one group. The single longest event handler within that group determines the interaction latency. CoreDash records the event type of the longest handler, which is the one that made the interaction slow.

Why Input Type Matters for INP

Every input type maps to a different part of your JavaScript codebase. If you see keydown as the dominant input type on a page with poor INP, you know immediately that the problem is in your keystroke handlers: autocomplete, search-as-you-type, form validation running on every key press. If you see click, the problem is in your button and link handlers: navigation logic, state updates, modal opens, analytics calls firing synchronously.

Without this dimension, an INP investigation starts with profiling sessions, reproduction steps, and guessing which interaction the 75th percentile user was attempting. With the input type dimension, you skip straight to the relevant handler. The time savings are real.

Input type also reveals platform differences. A site with heavy keyboard navigation from power users will show a high proportion of keydown events driving poor INP. A product used primarily on mobile will show pointerdown dominating. The same page, the same INP score, the same fix applied to different handlers depending on who your users actually are.

The Input Types

click and pointerdown

These are the most common input types in CoreDash data, accounting for roughly 75% of worst-INP events. On desktop, click represents a mouse button release. On mobile, a tap fires the full chain: pointerdown fires first when the finger touches the screen, then pointerup when it lifts, then click at the end. CoreDash records whichever event in that chain had the longest handler.

Click handlers are the primary location of heavy synchronous JavaScript work. A single click on a navigation item can trigger state management updates, DOM mutations, analytics events, and a re-render all in the same task. Each millisecond of synchronous work in a click handler is a millisecond added to INP.

The fix for slow click handlers is task decomposition. Use <code>scheduler.yield()</code> to break the handler into smaller tasks and let the browser render between them. Move non-critical work like analytics calls into a setTimeout with zero delay, or defer them entirely to requestIdleCallback. The browser only needs to complete work that affects the visual response before the next paint. Everything else can wait.

keydown

Keyboard input accounts for roughly 15% of worst-INP events in CoreDash data, but it produces some of the most egregious scores. The reason is frequency: a user typing in a search field fires keydown on every single keystroke. If your handler takes 200ms, the user experiences 200ms of lag after every character they type. A 10-character search query becomes 2 seconds of accumulated blocking time.

The common culprits are search-as-you-type implementations that fire synchronous API requests or run expensive DOM diffing on every keystroke, and form validation that re-checks the entire form on each key press. These patterns work fine at small scale and collapse under real user conditions.

The standard fixes are debouncing and offloading. Debounce your search handler so it only fires after the user pauses typing, typically 200 to 300 milliseconds. For more complex processing like fuzzy search across a large local dataset, move the computation to a Web Worker so the main thread remains free to render the next frame after each keydown event.

pointerup

Pointer up events represent approximately 8% of worst-INP cases in CoreDash data. pointerup fires at the end of a touch or click sequence, after pointerdown. Some frameworks and UI libraries bind their primary "click" behavior to pointerup rather than click, which moves the handler earlier in the interaction lifecycle.

When pointerup shows up as the dominant input type, the investigation is the same as for click handlers: find what JavaScript runs in the handler and separate the work that must block the next paint from work that can be deferred. The distinction from click is usually a framework-level decision, not an application-level one, so the fix may involve adjusting how the component library handles interaction binding.

Debugging Workflow

1. Filter by input type in CoreDash: Open the INP breakdown for a failing URL and check which input type dominates the worst interactions. If one type accounts for more than half your bad INP events, start there. The distribution tells you where to spend your profiling time.
2. Reproduce with the right interaction: Open Chrome DevTools, enable Performance profiling, and perform the exact interaction type shown in CoreDash. A keydown-dominated page should be tested by typing. A click-dominated page should be tested with mouse clicks on the elements your users interact with. Record the trace and identify the long tasks in the Main thread that fire immediately after the input event.
3. Apply the type-specific fix and verify: For keydown issues, add debouncing and re-profile. For click issues, add scheduler.yield() calls at logical breakpoints in the handler. Deploy to a test environment, use WebPageTest with interaction scripting or Chrome DevTools Performance panel, and confirm the task duration drops before shipping.

Engineering Rule of Thumb

• keydown dominates your bad INP: Add debouncing to all search and autocomplete handlers. 200ms delay is the standard starting point. If the computation is expensive even at that delay, move it off the main thread with a Web Worker.
• click or pointerdown dominates: Your handlers are doing too much synchronous work before the browser can paint. Audit every click handler on the failing URL. Remove synchronous analytics calls. Break multi-step logic with scheduler.yield() between steps.
• pointerup dominates: Check if your framework is binding interaction logic to pointerup instead of click. The fix is usually the same as for click handlers, but the entry point in the codebase is different.
• Mixed distribution with no clear winner: The problem is not one interaction type. Profile the three slowest individual interactions across all types and address them in order of impact. Do not optimize in the abstract.

Input Type is a routing signal. It does not tell you what is slow. It tells you where to look. Once you know whether your users are clicking, typing, or tapping when INP breaks, every subsequent investigation step becomes faster and more targeted.