How to Investigate Slow Interactions With INP

By Vincent Schmalbach

For search engine optimization (SEO), Interaction to Next Paint (INP) is a Google Core Web Vital, a measure of how quickly a page shows a visible response after someone clicks, taps, or presses a key. A slow INP means at least one interaction took too long to show its next frame. The metric does not identify the cause.

To investigate, use field data to find affected pages and device groups, then record the relevant interaction in Chrome DevTools. The timing breakdown shows whether the browser was busy before the interaction, took too long to run its event handlers, or took too long to render the next frame. INP helps assess page responsiveness, but a single lab result does not predict search rankings.

What INP measures

INP measures the time from a qualifying user action until the browser presents the next frame. One logical interaction, such as a tap, can involve several events. INP groups their timing to reflect the interaction as a whole. It covers clicks, taps, and key presses; scrolling and hovering alone do not count. The INP definition explains how the metric evaluates interactions during a page visit and selects a representative slow interaction, accounting for outliers on pages with many interactions.

The interaction’s latency has three parts:

The phases add up to the interaction’s latency. They narrow the search, but they do not prove a cause. The INP optimization guidance explains how to use the breakdown to focus your investigation.

Google’s field thresholds classify INP of 200 milliseconds or less as good, over 200 through 500 milliseconds as needing improvement, and over 500 milliseconds as poor. The assessment uses the 75th percentile of page visits, reported separately for mobile and desktop. A slow local interaction is worth investigating, but it does not by itself establish a poor field score.

Find the affected pages in field data

Start with real-user data to decide where to investigate. The Chrome User Experience Report (CrUX) and PageSpeed Insights can show field INP for an origin and, when data is available, a specific page. CrUX uses Chrome user experiences that meet its eligibility rules over a rolling 28-day period. Check whether a result represents a page or the whole origin, and note its device segment and collection period before comparing it with another result. The CrUX methodology describes its eligibility and reporting scope.

If you collect real-user monitoring data directly, record enough context to connect slow interactions to a page and user action. Useful details include the route, device category, interaction type, target, and phase timings. Google’s web-vitals attribution build exposes phase information and additional clues where supported. Treat those clues as leads: attribution does not automatically identify the root cause.

A missing INP value does not mean every interaction was fast. A visit with no qualifying click, tap, or key press may produce no INP measurement. Also, code running in the main page, outside an iframe, cannot inspect the contents of cross-origin iframes. But interactions inside iframes can contribute to the user experience measured by CrUX. Check for embedded content when your own measurements and CrUX appear to disagree.

Record the interaction in Chrome DevTools

Once field data identifies a page or device group, reproduce the user journey in Chrome DevTools’ Performance panel. Record the page and perform the specific action, such as opening a menu, submitting a form, or typing into a search field. If users interact while the page is loading, include that state in the recording; a test performed only after the page becomes idle can miss the delay.

The Performance panel’s Interactions track shows recorded interactions and their timing phases. Select the slow interaction, then inspect the Main track to see what the browser was doing before, during, and after it. The Performance panel reference explains how to inspect the recording.

If the issue is difficult to reproduce on your computer, use CPU throttling to simulate a slower processor and see how JavaScript work affects the page. Treat the throttled trace as a diagnostic comparison, not a precise reproduction of every user’s device. Test the relevant page state and user flow, since a click on an idle page may not match the conditions behind a field problem.

Follow the phase that takes the most time

When input delay dominates, inspect the work that ran before the event handlers began. A long JavaScript task can occupy the browser’s main thread and make it wait to process a new action. Startup script evaluation can do the same. So can a timer or another interaction. Before attributing the delay to a task in the recording, check whether it was running when the user acted. The input delay guidance explains how prior main-thread work can hold up an interaction.

When processing duration dominates, inspect the handler work in the Main track. Look for costly JavaScript and repeated calculations. Also check for synchronous work and DOM updates that do more than the interaction requires. A single user action can trigger multiple event callbacks, so inspect the whole interaction rather than assuming one obvious callback accounts for all its processing time.

When presentation delay dominates, inspect what happens after the handlers finish. Style recalculation, layout, and paint can hold up the next frame. A handler that changes styles and immediately reads layout values can force the browser to calculate layout before it can continue. Large DOM updates and work in frame-related callbacks can also contribute. The manual lab diagnosis guidance shows how to connect this phase to rendering activity.

Check that the trace explains the field result

A lab trace helps explain one interaction under the conditions you tested. Field data shows whether real visits experience slow INP across the measured population. Use field data to identify a problem among real visits, and use a lab trace to investigate a tested interaction. A clean local trace does not rule out a field problem if the device or user flow differs. Poor field INP alone does not identify a code-level cause. See why lab and field data differ.

Compare the field pattern with the trace. If field data points to mobile visits on a particular route and a menu interaction, record that route and interaction under conditions that resemble the affected device group. If the trace reproduces the same phase pattern, inspect the corresponding browser work and test a change against the trace. Then check whether field measurements improve as new data accumulates.

A long task is a clue, not proof. It supports a diagnosis when it overlaps the interaction and the phase timing fits the explanation. The Event Timing API also does not expose a complete record of every brief event by default: the W3C specification sets a default duration threshold of 104 milliseconds and rounds durations to 8-millisecond increments. Code that collects event timings can request a lower threshold for future entries, but it cannot recover events that were not captured.

Also distinguish the next frame from the completion of an asynchronous action. INP ends when the browser presents the frame after the interaction. A button can show a pressed state or spinner promptly while a network request and its later result remain slow. That later wait matters to the user, but INP alone does not measure its full duration. Measure the completion separately when that is the issue you need to resolve.

Key Takeaways

• Start with field data: Identify affected pages and device groups before selecting an interaction to reproduce.
• Use the phase breakdown: Separate input delay, handler processing, and presentation delay before changing code.
• Inspect timing in context: A long task or a named interaction target is only a clue unless the trace connects it to the delay.
• Compare field and lab evidence: Field data shows real-user patterns; a DevTools trace helps explain a tested case.
• Measure the right endpoint: INP measures the next frame; a later network-driven action may still be running after that frame.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com