Interaction to Next Paint (INP)

Jeremy Wagner

Browser Support

• 96
• 96
• x
• x

Source

Note: Interaction to Next Paint (INP) is a stable Core Web Vital metric that assesses responsiveness using data from the Event Timing API. INP observes the latency of all interactions a user has made with the page, and reports a single value which all (or nearly all) interactions were beneath. A low INP means the page was consistently able to respond quickly to all—or the vast majority—of user interactions.

Chrome usage data shows that 90% of a user's time on a page is spent after it loads, Thus, careful measurement of responsiveness throughout the page lifecycle is important. This is what the INP metric assesses.

Good responsiveness means that a page responds quickly to interactions. When a page responds to an interaction, the browser presents visual feedback in the next frame that it paints. Visual feedback tells you if, for example, an item you add to an online shopping cart is indeed being added, whether a mobile navigation menu has opened, if a login form's contents are being authenticated by the server, and so forth.

Some interactions naturally take longer than others, but for especially complex interactions, it's important to quickly present some initial visual feedback to tell the user that something is happening. The next frame that the browser will paint is the earliest opportunity to do this.

Therefore, the intent of INP is not to measure all the eventual effects of an interaction—such as network fetches and UI updates from other asynchronous operations)—but the time that the next paint is being blocked. By delaying visual feedback, users may get the impression that the page is not responding quickly enough, and INP was developed to help developers measure this part of the user experience.

In the following video, the example on the right gives immediate visual feedback that an accordion is opening. Poor responsiveness is demonstrated in example on the left, and how it can create poor user experiences.

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

This guide explains how INP works, how to measure it, and points to resources for improving it.

What is INP?

INP is a metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers.

Details on how INP is calculated

INP is calculated by observing all the interactions made with a page. For most sites the interaction with the worst latency is reported as INP.

However, for pages with large numbers of interactions, random hiccups can result in an unusually high-latency interaction on an otherwise responsive page. The more interactions that occur on a given page, the more likely this is to happen.

To give a better measure of the actual responsiveness for pages with a high number of interactions, we ignore one highest interaction for every 50 interactions. The vast majority of page experiences don't have over 50 interactions, so the worst interaction is most often reported. The 75th percentile of all page views is then reported as usual, which further removes outliers to give a value that the vast majority of users experience or better.

An interaction is a group of event handlers that fire during the same logical user gesture. For example, "tap" interactions on a touchscreen device include multiple events, such as pointerup, pointerdown, and click. An interaction can be driven by JavaScript, CSS, built-in browser controls (such as form elements), or a combination thereof.

An interaction's latency consists of the single longest duration of a group of event handlers that drive the interaction, from the time the user begins the interaction to the moment the browser is next able to paint a frame.

Key point: For more details on how INP is measured, read the "What's in an interaction?" section.

What is a good INP score?

Pinning labels such as "good" or "poor" on a responsiveness metric is difficult. On one hand, you want to encourage development practices that prioritize good responsiveness. On the other hand, you must account for the fact that there's considerable variability in the capabilities of devices people use to set achievable development expectations.

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

• An INP below or at 200 milliseconds means a page has good responsiveness.
• An INP above 200 milliseconds and below or at 500 milliseconds means a page's responsiveness needs improvement.
• An INP above 500 milliseconds means a page has poor responsiveness.

Good INP values are 200 milliseconds or less. Poor values are greater than 500 milliseconds.

What's in an interaction?

The life of an interaction. An input delay occurs until event handlers start running, possibly caused by factors such as long tasks on the main thread. The interaction's event handler callbacks then run, and a delay occurs before the next frame is presented.

The primary driver of interactivity is often JavaScript, though browsers do provide interactivity through controls not powered by JavaScript, such as checkboxes, radio buttons, and controls powered by CSS.

As the purposes of INP, only the following interaction types are observed:

• Clicking with a mouse.
• Tapping on a device with a touchscreen.
• Pressing a key on either a physical or onscreen keyboard.

Key point: Users may also interact with the page in other ways, like hovering, zooming, or scrolling. These interactions are not observed for the purposes of INP. However, some variations of these interactions may include gestures like clicks, taps, or key presses that INP does measure.

Interactions happen in the main document or in iframes embedded in the document—for example clicking play on an embedded video. End users won't be aware what is in an iframe or not, therefore, INP within iframes are needed to measure the user experience for the top level page. Because JavaScript Web APIs don't have access to the contents of iframes, this may show as a difference between CrUX and RUM

Interactions can consist of multiple events. For example, a keystroke includes the keydown, keypress, and keyup events. Tap interactions contain pointerup and pointerdown events. The event with the longest duration within the interaction is what contributes to the interaction's total latency.

A depiction of an interaction with multiple event handlers. The first part of the interaction receives an input when the user clicks down on a mouse button. However, before they release the mouse button, a frame is presented. When the user releases the mouse button, another series of event handlers must run before the next frame is presented.

The page's INP is calculated when the user leaves the page. The result is a single value that is representative of the page's overall responsiveness throughout its lifecycle. A low INP means that a page was reliably responsive to user input.

How is INP different 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 on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers, and finally up until the browser has painted the next frame.

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

What if no INP value is reported?

It's possible for a page to return no INP value. This can happen for a number of reasons, including the following:

• The page was loaded, but the user never clicked, tapped, or pressed a key on their keyboard.
• The page loaded, but the user interacted with it using gestures that aren't measured, such as scrolling or hovering over elements.
• The page is being accessed by a bot such as a search crawler or headless browser that has not been scripted to interact with the page.

How to measure INP

INP can be measured both in the field and in the lab, to the extent that you can simulate realistic user interactions.

Key point: The best way to measure your website's INP is by gathering metrics from actual users in the field. If you're accustomed to relying on lab data for assessing performance, take some time to read Why lab and field data can be different (and what to do about it).

In the field

Ideally, your journey in optimizing INP will start with field data. At its best, field data from Real User Monitoring (RUM) will give you not only a page's INP value, but also contextual data that highlights what specific interaction was responsible for the INP value itself, whether the interaction occurred during or after page load, the type of interaction (click, keypress, or tap), and other valuable timings that can help you identify which part of the interaction was affecting responsiveness.

Read to learn more: Find slow interactions in the field.

If your website qualifies for inclusion in the Chrome User Experience Report (CrUX), you can quickly get field data for INP via CrUX in PageSpeed Insights (and other Core Web Vitals). At a minimum, you can get an origin-level picture of your website's INP, but in some cases, you can also get URL-level data.

However, while CrUX can tell you if there is a problem, it can't tell you what caused the problem. A RUM solution can help you uncover more details about pages, users, or user interactions that are experiencing responsiveness issues. Being able to attribute INP to individual interactions avoids guesswork and wasted effort.

In the lab

Optimally, you'll want to start testing in the lab once you have field data that suggests a page has slow interactions. Field data will make the work of reproducing problematic interactions in the lab a much more straightforward task.

It's entirely possible, however, that you don't have field data. While INP can be measured in some lab tools, the resulting INP value for a page during lab testing will be dependent on what interactions are performed during the measurement period. User behaviors can be unpredictable and highly variable, meaning that your testing in the lab may not surface problem interactions in the same fashion that field data can. Additionally, some lab tools won't report a page's INP because they only observe the loading of a page without any interactions. In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it's not a substitute for INP in and of itself.

Even though there are limitations in lab tools when it comes to assessing a page's INP, there are some strategies for reproducing slow interactions in the lab. Strategies include following common user flows and testing interactions along the way, as well as interacting with the page as it loads—when the main thread is often busiest—in order to identify slow interactions during that crucial part of the user experience.

Read to learn more: Manually diagnose slow interactions in the lab.

How to improve INP

A collection of guides on optimizing INP is available to guide you through the process of identifying slow interactions in the field, and using lab data to help you identify causes and optimize them.

Changelog

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this Changelog.

If you have feedback for these metrics, provide it in the web-vitals-feedback Google group.

Test your knowledge

What is the primary goal of the INP metric?

To measure the time it takes for the first content of a page to be displayed.

Incorrect - This describes First Contentful Paint

To quantify the visual stability of a page and minimize unexpected layout shifts.

Incorrect - This describes Cumulative Layout Shift

To assess the time it takes for a page to become fully interactive.

Incorrect - This is related to Time to Interactive, but INP specifically focuses on responsiveness to user input

To minimize the time from when a user initiates an interaction until the next frame is painted, for all or most interactions the user initiates.

Correct!

Which of the following interaction types are observed for the purposes of calculating INP? (Select all that apply.)

Clicking with a mouse.

Correct!

Scrolling the page with a mouse wheel or trackpad.

Incorrect - INP does not consider scrolling

Tapping on a touchscreen.

Correct!

Hovering the mouse cursor over elements.

Incorrect - INP does not consider hovering

Pressing a key on a keyboard.

Correct!

Zooming in or out on the page.

Incorrect - INP does not consider zooming

How is the "latency" of an interaction defined for INP?

The amount of time for the browser to process the event handlers of an interaction.

Incorrect - This only accounts for the processing duration, not the input delay or time to present the next frame

The average time it takes for all interactions on a page to produce a visual response.

Incorrect - INP focuses on the longest interaction, not the average

The time it takes for the browser to start processing the event handlers associated with an interaction.

Incorrect - This only accounts for the input delay, not the processing and rendering time

The time from the start of the interaction to the moment the next frame is fully presented.

Correct!

What is the difference between INP and FID?

INP measures the time it takes for the first content of a page to be displayed, while FID measures the responsiveness to user input.

Incorrect - This describes First Contentful Paint, not INP

INP considers the full duration of all interactions, while FID only measures the input delay of the first interaction.

Correct!

INP and FID measure different timestamps at which a page becomes interactive.

Incorrect - INP and FID are measures of how quickly the page responds to interactions, irrespective of when the interactions occur

There is no difference; INP and FID are just two different names for the same metric.

Incorrect - They do have distinct definitions

Under what circumstances might INP data be unavailable for a page in tools like PageSpeed Insights?

The page is using a custom performance measurement library that doesn't report INP data.

Incorrect - INP is automatically measured using web platform APIs and doesn't rely on pages self-reporting their performance through custom libraries.

There isn't enough interaction data from Chrome users to calculate a meaningful INP value in the CrUX dataset.

Correct!

Users interacted with the page solely through scrolling and hovering, which are not considered for INP.

Correct!

The page is built using a framework that automatically optimizes for INP, so there's no need to report it.

Incorrect - Frameworks can help with INP, but the metric is still relevant and reported if data is available

What is the most effective strategy for reproducing slow interactions in a lab environment?

Simulating a high-end device with a slow and unreliable network connection to create challenging conditions.

Incorrect - While network can play a role, device capabilities are more likely to expose slow interactions

Testing interactions only after the page has fully loaded and is idle.

Incorrect - This might miss interactions that are slow during load

Interacting with the page during load and following common user flows to identify potential bottlenecks.

Correct!

Focusing on complex, edge-case interactions that are unlikely to be encountered by most users.

Incorrect - Common user flows are more relevant for identifying typical INP issues

✨ This quiz was generated by Gemini 1.5 and reviewed by humans. Share your feedback