INP phases
The three places a tap can lose time: waiting for the main thread, running its handlers, and getting the next frame onto the screen.
See it
What it is
The INP phases split an interaction into input delay, while the main thread is too busy to begin the event callbacks; processing time, while those callbacks run; and presentation delay, while the browser finishes style, layout, paint, and any other work needed for the next frame. Together they explain why a click, tap, or key press felt late, and which of the three is eating the 200ms an interaction gets before INP calls it a fail.
Use the split before rewriting an event handler. Long input delay usually means unrelated main-thread work was already in the way. Long processing time indicts the callbacks and state updates. Long presentation delay points toward a large render, expensive layout, or too much work queued before paint.
Gotcha: one human tap can produce pointerdown, pointerup, and click events, so one callback is not necessarily the whole interaction. Moving expensive work into requestAnimationFrame can merely move time from processing into presentation delay. The number improves only when the next useful frame arrives sooner.
Ask AI for it
Diagnose this page's slow interactions by INP phase. Add the 'web-vitals/attribution' build and use onINP to capture input delay, processing duration, presentation delay, interaction type, and target for the worst reproducible tap, click, and key press. Fix the dominant phase: split unrelated long tasks to reduce input delay, shorten the event callbacks to reduce processing time, or reduce React renders, style recalculation, and layout to reduce presentation delay. Paint the pressed or pending state first and use scheduler.yield() before non-urgent work when supported. Re-run the same interaction under the same Chrome DevTools CPU throttle and report all three phase values before and after.