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.
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.
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 paints the next frame.
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.
What's in an interaction?
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.
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.
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 through a variety of tools.
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.
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. If you don't have field data, however, 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.
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.