Interaction to Next Paint (INP)

Interaction to Next Paint (INP) measures how responsive a web page feels by measuring the delay between user interactions and the next rendered visual update. It focuses on the latency of interactions such as clicks, taps, and keyboard input throughout a page visit.

INP evaluates interaction responsiveness by observing eligible user interactions and measuring their interaction-to-paint latency. An interaction can involve multiple events, such as pointerdown, pointerup, and click; the measured latency includes the time spent processing the interaction and waiting for the browser to render the resulting update.

INP is a Core Web Vital intended to represent real-world responsiveness rather than simply measuring whether JavaScript executed quickly. A page can have fast initial loading but still feel sluggish if its main thread becomes busy when users interact with it.

The browser's main thread performs tasks such as JavaScript execution, style calculation, layout, and painting. Long tasks can therefore delay event handling or rendering and increase INP. Common causes include expensive event handlers, large synchronous JavaScript workloads, excessive rendering work, and unnecessary DOM updates.

For a page visit, INP is derived from the observed interaction latencies rather than being a simple average of every interaction. After the visit, the resulting value can be categorized as good, needs improvement, or poor using established thresholds. Developers can investigate slow interactions with browser performance tooling and field data to identify which handlers or rendering work are responsible.

Key points

• INP measures interaction latency until the next visual update.
• It reflects responsiveness across a page visit rather than only initial loading.
• Long main-thread tasks can delay interaction processing and painting.
• Expensive event handlers and rendering work are common sources of poor INP.
• INP is a Core Web Vital with good, needs-improvement, and poor ranges.

Interview questions

How is INP different from FID?

FID focused on the delay from a user's first qualifying input until the browser could begin processing it. INP evaluates interaction latency through the next visual update and considers responsiveness over the visit. As a result, INP captures more of the interaction experience, including delays associated with processing and rendering the response.

What does INP measure?

INP measures how quickly a page responds visually after a user interaction. It considers the latency from an interaction until the browser presents the next rendered update. This makes it a measure of perceived interaction responsiveness rather than initial page-load speed.

Why can a long JavaScript task cause poor INP?

JavaScript normally runs on the browser's main thread along with important rendering work. If a long task occupies that thread, an interaction may have to wait before its handler can run or before the browser can render the result. The longer this blocking period is, the greater the interaction latency can become.

How would you improve a page with poor INP?

I would first identify which interactions have high latency using field or performance data. Then I would inspect the corresponding event handlers and the main-thread work around those interactions. Typical fixes include breaking up long tasks, reducing synchronous JavaScript, deferring nonessential work, and minimizing expensive DOM or rendering operations. I would then measure again to verify that the change improves the actual interaction path.

What kinds of frontend architecture decisions can affect INP?

Architecture affects how much work reaches the main thread during user interactions. Large client-side bundles, synchronous state updates, expensive component trees, unnecessary rerenders, and heavy event handlers can all increase interaction latency. Good architecture keeps interaction-critical work small and schedules nonessential work separately when possible. The important goal is not merely reducing JavaScript size, but controlling the amount and timing of work required to produce the user's visible response.