What the INP Interaction Profiler does
This profiler reads Event Timing entries from your own page - captured with a short console snippet or taken from a saved DevTools Performance trace - finds the slowest clicks, taps and key presses, and splits each one into input delay, processing time and presentation delay, so you know whether to fix a busy main thread, a slow handler or an expensive render.
It works on one recorded session, so the number it shows is a lab estimate of Interaction to Next Paint for that session. Field INP - the figure Google assesses - is the 75th percentile across many real visits, and this page never presents one as the other. Everything is parsed in your browser tab.
How to use it
- Open the page you want to test in Chrome or Edge and open DevTools (F12). For realistic numbers, set CPU throttling to 4x in the Performance panel.
- Copy the snippet above, paste it into the Console and press Enter. It starts observing event, layout-shift and LCP entries.
- Use the page the way a visitor would - open the menu, type in search, change options, add to basket - especially while it is still loading.
- Run
a2zDump()in the Console. The JSON is copied to your clipboard; paste it into the box here. Alternatively save a Performance recording ("Save trace") and drop the file. - Press Analyse. Start with the slowest interaction and the phase that dominates it.
Reading the results
An interaction's latency is the longest duration among the events it caused (pointerdown, pointerup, click, keydown and so on), measured from the input until the next frame is painted. Browsers round event durations to 8 ms.
The session INP estimate is the slowest interaction, except that one highest interaction is ignored for every 50, as web.dev describes. With fewer than 50 interactions it is simply the worst one.
Input delay is time waiting for the main thread before any handler ran. Processing is time spent in event handlers. Presentation delay is the time to calculate styles, lay out and paint the next frame. The three add up to the latency of the event that set it.
Under 200 ms is within the good threshold, 200-500 ms needs improvement and above 500 ms is poor - but those thresholds apply to field p75, so treat a lab session as a pointer to problems, not a verdict.
Worked example: a product page session with a slow add-to-basket button
The sample session records nine interactions. The slowest is the click on button.add-to-cart: 424 ms, made of 14 ms input delay, 318 ms processing and 92 ms presentation delay. With fewer than 50 interactions nothing is ignored, so the session INP estimate is 424 ms - in the needs-improvement band if field data looked like this.
Processing dominates, so the fix is in the click handler: show the "added" state first, then yield to the browser before updating the mini-basket, sending analytics and re-rendering recommendations.
The second slowest is a keydown in input#search at 264 ms, where 182 ms is input delay: the main thread was still busy with a long task when the key was pressed. Breaking up that task, or debouncing the search suggestions, is a different fix from the first - which is why the phase split matters.
Formulas and scoring rules
- Interaction latency
latency = max(duration of every event entry with the same interactionId)- Phases (of the entry that sets the latency)
input delay = processingStart - startTime; processing = processingEnd - processingStart; presentation = startTime + duration - processingEnd- Session INP estimate
sort latencies high to low; INP = latency at position floor(n / 50) (0-based)One highest interaction is ignored per 50 interactions.- Trace timing
time_ms = (event ts - navigationStart ts) / 1000Chrome trace timestamps are in microseconds.
Getting data from a DevTools trace
Recent versions of Chrome write EventTiming begin/end pairs into Performance recordings, carrying the event type, duration, interaction id and processing times. The profiler pairs them and re-bases the times on the trace's navigationStart. If your recording has no EventTiming events - older Chrome, or a Lighthouse run with no user input - the page says so rather than showing an empty result as a pass.
Traces can be large. Files up to 60 MB and three million events are accepted; above that, record a shorter session around the interaction you care about.
Limitations: what the result does not prove
- One session on one device is lab data. Field INP depends on your visitors' devices and behaviour; use CrUX or real-user monitoring for the number Google assesses.
- The snippet records event entries of 16 ms or longer (the smallest threshold browsers allow), and only interactions made after it was pasted, plus any the browser had buffered.
- Element names come from the snippet's description of the event target (tag, id and first classes). Nodes removed from the page may show no target.
- It tells you which phase is slow, not which line of code. Use the Performance panel's flame chart or Long Animation Frames to find the script responsible.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- web.dev - Interaction to Next Paint - checked 19 Sep 2026
- web.dev - Web Vitals and thresholds - checked 19 Sep 2026
- web.dev - Optimize Interaction to Next Paint
- W3C Event Timing API
Frequently asked questions
Why does my interaction have three phases?
Every interaction waits for the main thread (input delay), runs its event handlers (processing) and then waits for the browser to render the next frame (presentation delay). Each has a different fix, so knowing which one is large saves you optimising the wrong thing.
Is the session INP estimate the same as my INP in Search Console?
No. Search Console and PageSpeed Insights show field INP: the 75th percentile across real visits over 28 days. This page shows the worst interaction of one recorded session. It is useful for finding slow interactions, not for predicting your field score.
Which events count towards INP?
Clicks, taps and key presses - the discrete interactions that carry an interactionId. Hovering, scrolling and zooming do not count, so a slow scroll handler will not show up here even though it can still make the page feel sluggish.
How do I reduce a long input delay?
Input delay means the main thread was busy with something else. Break long tasks into chunks that yield back to the browser (for example with scheduler.yield or setTimeout), load third-party scripts later, and avoid heavy hydration or parsing while visitors can already interact.
Is the console snippet safe to run on a production page?
It only registers PerformanceObservers and builds a JSON object in memory. It makes no network requests and stores nothing. The data leaves the page only when you run a2zDump() and paste the clipboard contents yourself.
Why do the durations look rounded to multiples of 8?
Browsers round Event Timing durations to 8 ms to limit timing attacks. Differences smaller than that are noise; look at interactions that are clearly over 200 ms.
Last reviewed by the A2Z.Tools team against the sources listed above.
