INP Interaction Profiler Guide: Read Interaction Delays Like a Detective
A page can load quickly and still feel slow. The visitor clicks a button, and nothing happens for a moment. They type in a field, and characters appear late. They open a menu, and it stutters into view. These are interaction problems, and they are measured by Interaction to Next Paint, or INP, which records the time from a visitor's action until the browser paints the next frame showing the result. Good INP is under 200 milliseconds; above 500 milliseconds, the page feels unresponsive.
The INP Interaction Profiler tool summarises pasted interaction timing data: the individual interaction times, their distribution, and which interactions are worst. Understanding INP starts with its three parts. Input delay is the time between the visitor's action and the browser starting to handle it, often because the main thread is busy with other work. Processing time is the time the page's code takes to respond, such as running an event handler. Presentation delay is the time to render the result, including layout and painting. A slow interaction can be slow in any one part, and the fix depends entirely on which part is responsible.
An important caveat runs through this guide: lab measurements and field data describe different things. A lab test simulates a few interactions in controlled conditions, while field data records what real visitors actually do on real devices. A page can show good lab INP and poor field INP, because real visitors interact in ways the lab never tried: they click during heavy script execution, on slower phones, with more content on screen. Both measurements are useful, but field data is the verdict, and lab data is the diagnostic tool used to chase it.
A worked example you can follow
Suppose a profiler summary lists five click interactions with times of 80, 120, 160, 240 and 900 milliseconds. The average is 80 plus 120 plus 160 plus 240 plus 900, which equals 1500, divided by 5, which equals 300 milliseconds. The median, the middle value when sorted, is 160 milliseconds. The worst is 900 milliseconds. INP, in field reporting, is closer to a high percentile than an average: it reflects the poor experiences, not the typical one, because a page that responds well nine times and badly once still feels broken on that once. If the 900-millisecond interaction is a real visitor pattern rather than an outlier, it dominates the verdict even though the median looks acceptable.
Break that 900-millisecond interaction into parts. Suppose input delay is 500 milliseconds, processing is 250 milliseconds, and presentation is 150 milliseconds, totalling 900. The diagnosis is clear: input delay is the largest part, at 500 divided by 900, or about 55.6 percent, which points to a busy main thread, such as a long script running when the visitor clicked. Splitting that script's work into smaller tasks, deferring non-essential work, or moving work off the interaction path would attack the dominant part. Optimising presentation from 150 to 100 milliseconds, by contrast, would save only 50 milliseconds off a 900-millisecond problem, barely noticeable.
After fixing, re-profile with the same interactions and compare like with like. A fix that helps the 900-millisecond case but hurts the common case is not a clear win, and the profiler's distribution view reveals that trade-off. The JavaScript Bundle Analyzer tool helps find the heavy scripts behind input delay, and the Core Web Vitals Budget Calculator tool turns thresholds into budgets for the whole page.
Common mistakes to avoid
The first mistake is averaging interactions and declaring victory while the worst ones stay bad. The second is optimising the wrong part: speeding up rendering when the delay is input delay wastes effort. The third is testing only in the lab and ignoring field data, where real interaction patterns live. The fourth is measuring interactions nobody performs, while the interactions visitors actually use go unmeasured. The fifth is treating a single bad interaction as noise when it represents a real pattern, such as every first click after page load.
For the wider performance picture, see Website SEO Audit Guide. Profile real interactions, break them into parts, fix the largest part, and let field data confirm the improvement. Responsiveness is measured one interaction at a time, and the slow ones are the ones visitors remember.
The long-task problem behind input delay
Input delay, the largest part of many slow interactions, usually traces back to long tasks: stretches of JavaScript that run without yielding, blocking the main thread for 50 milliseconds or more. While a long task runs, the browser cannot respond to clicks, taps or keystrokes, so those inputs queue up and their delay grows by the remaining time of the task. A task lasting 600 milliseconds that starts just before a visitor clicks produces an input delay of nearly 600 milliseconds for that click, regardless of how fast the click handler itself would have been. The visitor experiences a frozen page, and the profiler shows input delay dominating the interaction.
Breaking long tasks into smaller pieces is the standard remedy. A task that processes a thousand items in one loop can process them in chunks of fifty, yielding to the browser between chunks so pending inputs can be handled. Work that does not affect the current interaction can be deferred until the browser is idle, or moved to a background thread where the platform supports it. Scripts that are not needed for the current page can be loaded lazily, so they never occupy the main thread during the interactions that matter. Each of these changes the shape of main-thread work from long blocking stretches to short interruptible ones, and the profiler's input-delay figure is the measure that shows whether the change worked.
Testing for long tasks requires realistic conditions. A fast developer machine with a small dataset may never produce a long task, while a mid-range phone with a full dataset produces them constantly. Profiling with throttled processing power and realistic data reveals the tasks that real visitors meet, and fixing those tasks, rather than the ones visible on a fast machine, is what improves field INP. The lab-to-field gap for INP is largely a gap between fast test hardware and ordinary visitor hardware, and closing it starts with testing on hardware that resembles the audience.