Understanding Interaction Next Paint (INP) Metric

The Interaction Next Paint (INP) is a stable Core Web Vitals metric that evaluates a page’s responsiveness using data from the Event Timing API. Officially, it became an Essential Web Metrics metric on March 12 of 2024. The INP observes the latency of all click, touch, and keyboard interactions with a page over its lifespan and reports the longest duration, disregarding outliers. A low INP signifies that the page is capable of quickly responding to most user interactions.

Good responsiveness means a page swiftly responds to interactions. When a page responds to an interaction, the browser provides visual feedback in the next rendering frame to indicate the interaction was successful. For example, it may provide feedback on whether an item has been successfully added to an online shopping cart, if a mobile navigation menu has opened, or if the content of a login form is being authenticated with the server.

Some natural interactions take longer than others, but for particularly complex interactions, it’s important to provide initial visual feedback quickly to inform the user that something is happening. Time to Next Paint is the first opportunity to do this. Thus, the goal of the INP is to measure not all eventual effects of the interaction (such as network fetches and UI updates from asynchronous operations) but the time until the next paint is blocked. Delaying visual feedback makes users think the page isn’t responding to their actions.

The goal of the INP is to minimize the time from when a user initiates an interaction until the next frame is painted, for most interactions the user initiates.

An example of poor versus good responsiveness. On the left, long tasks block accordion opening. This causes the user to click multiple times, thinking the experience is broken. When the main thread catches up, it processes delayed inputs, causing the accordion to open and close unexpectedly. On the right, a more responsive page quickly and smoothly opens the accordion.

A note on how INP is calculated: an interaction is a group of event handlers triggered during the same logical user gesture. For example, “touch” interactions on a touchscreen device include multiple events like pointerup, pointerdown, and click. An interaction can be driven by JavaScript, CSS, built-in browser controls like form elements, or a combination of these things.

The latency of an interaction consists of the longest duration of a group of event handlers driving the interaction, from when the user initiates the interaction until the next frame with visual feedback is presented.

What’s a Good INP Score?

To ensure you’re providing user experiences with good responsiveness, a good threshold to measure is the 75th percentile of page loads recorded in the field, segmented by mobile and desktop devices:

• An INP equal to or less than 200 milliseconds means your page has good responsiveness.
• An INP between 200 milliseconds and 500 milliseconds means your page’s responsiveness needs improvement.
• An INP greater than 500 milliseconds means your page has poor responsiveness.

Good INP values are 200 milliseconds or less, bad values are greater than 500 milliseconds, and any values in between need improvement.

What’s in an Interaction?

A diagram depicting an interaction on the main thread. The user inputs while long tasks are running. The input is delayed until tasks are completed, after which pointerup, mouseup, and click event handlers are executed, and then rendering and painting work begins until the next frame is presented.

The life of an interaction. An input delay lasts until event handlers are initiated, possibly caused by factors like long tasks on the main thread. Then, interaction event handlers are executed, and another delay occurs before the next frame is presented.

The primary driver of interactivity is often JavaScript, although browsers also provide interactivity through non-JavaScript-driven controls such as checkboxes, radio buttons, and CSS-driven controls.

For INP purposes, only the following types of interactions are considered:

• Mouse clicks.
• Touches on a touchscreen device.
• Key presses on a physical or on-screen keyboard.

Scrolling and mouse hovering are not considered in INP. However, keyboard scrolling (spacebar, page up, page down, etc.) involves a key press, which may trigger other events that INP does measure. Any resulting scrolling is not accounted for in INP calculation.

Interactions can consist of multiple events. For example, a key press includes the keydown, keypress, and keyup events, and touch interactions include pointerup and pointerdown events. The event with the longest duration within the interaction is chosen as the interaction’s latency.

A depiction of a more complex interaction containing two interactions. The first is a mousedown event, which produces one frame before the mouse button is released, triggering more work until another frame is presented as a result.

When the user presses the mouse button to click, the browser handles the interaction and presents a frame of visual feedback. When the user releases the mouse button, other event handlers are executed before the browser can present another frame.

INP is calculated when the user leaves the page, resulting in a single value representative of the overall responsiveness of the page throughout its lifecycle. A low INP value means a page is reliably responsive to user input.

How Does INP Differ from First Input Delay (FID)?

INP is the successor metric to First Input Delay (FID). While both are responsiveness metrics, FID only measured the input delay of the first interaction on a page. INP improves upon FID by considering all interactions on the page, from input delay to the time it takes to execute event handlers and until the next frame is painted.

These differences mean both INP and FID are different types of responsiveness metrics. While FID was a load responsiveness metric designed to evaluate the user’s first impression on the page, INP is a more reliable indicator of overall responsiveness, regardless of when in a page’s life interactions occur.

What If an INP Value Isn’t Reported?

A page may fail to return an INP value. This can happen for several reasons, including:

• The page loaded, but the user never interacted with it.
• The page loaded, but the user interacted with it using unmeasured gestures, such as scrolling or hovering over elements.
• The page is being accessed by a bot, such as a search crawler or headless browser, which hasn’t been programmed to interact with the page.

How to Measure INP?

INP can be measured both in the field and in the lab using a variety of tools.

In the Field

Ideally, your journey to optimizing INP begins with field data. At its best, Real User Monitoring (RUM) field data not only provides you with a page’s INP value but also contextual data highlighting which specific interaction was responsible for the INP value, whether the interaction occurred during or after page load, the interaction type (click, key press, or touch), and other valuable information.

In the Lab

Typically, Chrome tools that report data from labs run Lighthouse.