What is the Interaction to Next Paint?
INP is a new Core Web Vitals metric per March 2024 that represents a page's overall interaction latency by identifying one of the single longest interactions that occur when a user visits the page. INP is the interaction with the longest latency for pages with less than 50 interactions. INP is usually the 98th percentile of interaction latency for pages with a lot of interactions.
A set of related input events that fire during the same logical user gesture is referred to as an interaction.
In terms of INP, only these specific types of interactions are taken into account:
- Clicking with a mouse.
- Tapping on a device with a touchscreen.
- Pressing a key on either a physical or onscreen keyboard.
How to measure the Interaction to Next Paint
INP will be measured as the single longest interaction latency on a page if there are less than 50 interactions total. INP is calculated as the 98th percentile of interaction latency if there are more interactions.
The time between when a user interacts with a page (for example, by tapping, clicking, or pressing a key) and when the next frame appears is known as interaction latency (meaning the user sees something different on their screen and gets the feedback that their interaction has triggered the change). The following phases are included in this period:
- Input Delay: If your input delay is high, then other tasks were still running when users interacted with your webpage.
- Processing Time: A long processing time means that your event handler for the current action was slow due to your code.
- Presentation Delay: When the presentation delay is high, then you have a render delay issue.
INP breakdown
With RUMvision, you can easily see which of the above three things contribute to a high INP value. When you know this, you can debug much easier and therefore work faster toward a solution and better Core Web Vitals.
With this insights you'll be able to debug the INP and optimize your Core Web Vitals along with it:
- Pinpoint web performance issues on your website or webshop.
- Reproduce them using by looking at characteristics.
- Create a fix and annotate it in RUMvision.
- And see numbers improve right away, without Google's delay.
Hovering and scrolling are not considered in the calculation of INP. However, keyboard-based scrolling (such as using the space bar, page up, page down, etc.) can lead to a keystroke, potentially triggering events that are indeed measured by INP. Nevertheless, the consequent scrolling itself isn't included in the INP computation
What is a good INP score?
Assessing responsiveness metrics like INP can be a challenge. While it's crucial to promote development strategies that prioritize optimal responsiveness, it's equally important to take into account the wide range of device capabilities people use, which can set practical development goals.
To ensure optimal user experience in terms of responsiveness, it's advisable to use the 75th percentile of page load records in real-world conditions This is according to Google's Core Web Vitals thresholds. When you're using RUMvision you're using the 80th percentile by default.
- An INP of 200 milliseconds or less indicates that your page has a good INP value
- An INP exceeding 200 milliseconds but not more than 500 milliseconds suggests that the responsiveness of your page could be improved.
- An INP over 500 milliseconds signifies that the responsiveness of your page is bad and needs improvement to pass for the Core Web Vitals assessment.
Differences between FID and INP
INP evaluates all interactions on a page, whereas FID only considers the initial interaction. FID measures only the input delay of that first interaction, not the time required to execute event handlers or the delay until the next frame is presented.
As FID is also a metric for load responsiveness, the idea is that a page leaves a positive first impression if the initial interaction during the load phase experiences minimal or no noticeable input delay.
A better metric for measuring responsiveness
The INP goes beyond the initial impression. By examining all interactions, it provides a comprehensive evaluation of responsiveness. This makes INP a more dependable gauge of total responsiveness compared to FID.
Why does the FID get replaced by the INP?
FID may not be the best choice. At present, nearly 95% of about 17 million origins meet the FID benchmark and are easily passing the Core Web Vitals, yet there is a significant percentage beyond the remaining 5% that employ numerous Third Parties and JavaScript in general. This suggests that merely tracking the initial interaction - as FID does - doesn't provide a comprehensive understanding of JavaScript's overall impact. Consequently, it underscores the necessity to monitor delays across various interactions during a page's lifespan.
Will every page visit report an INP event?
There could be situations where a page does not yield an INP value, which could be due to several reasons:
- The user did not engage in any clicking, tapping, or keyboard pressing actions after the page loaded.
- The user interacted with the page through gestures that didn't include clicking, tapping, or keyboard use. For instance, actions like scrolling or hovering over elements are not considered in the calculation of INP.
- The page is being visited by a bot, like a search crawler or a headless browser, that hasn't been programmed to interact with the page.
Device memory impacting the INP
When you have a webshop you get a lot of different visitors. Everyone comes in under different circumstances. This could be their Internet speed, location, but also their device memory.
A higher number of GBs of device memory will allow tasks such as Javascript to be processed more easily. So if you have a lot of visitors on, say, an 8GB phone then you will more easily pass the Core Web Vitals and the INP.
The image below shows how user conditions impact the INP (on the right of the visitor footprint). You can see that user's on a device with 8GB device memory have a faster INP than those on 2GB and 4GB.
How to measure the INP?
To measure the Core Web Vitals, and therefore nowadays the INP, you can use lab and field tools. A field tool represents, as in the visitor footprint, how all your users experience the INP. With a lab tool you test in your own local environment, so this is most likely not representative.
Measure INP with field data
- Google Pagespeed Insights
- Chrome User Experience Report
- Via BigQuery in the CrUX dataset's interaction_to_next_paint table.
- CrUX API via interaction_to_next_paint.
- CrUX Dashboard.
- Real user monitoring with RUMvision
- Know your audience
- INP per device memory
- Filters and dimensions such as pageview type
- INP breakdown
Measure INP with lab data
- Google Lighthouse
- Via Pagespeed Insights (best to use, simulated device)
- Via DevTools (results are based on your device)
- Web Vitals extension
Optimize Interaction to Next Paint
Now that the INP is a Core Web Vital, you probably want to work even faster to maintain the SEO benefits and also understand that a good INP contributes to a good user experience. Unlike the Largest Contentful Paint, the INP is a little more difficult to optimize because you have to get a very good understanding first.
What is causing a bad INP?
Before you can address the issue of sluggish interactions, you'll require data to determine whether your website's INP is subpar or requires enhancement. After acquiring this information, you can transition into the lab to commence the diagnosis of the slow interactions, and gradually develop a solution.
Ideally, your journey in optimizing INP will start with field (RUM) data.
Measuring the INP with RUM data
Field data obtained from a Real User Monitoring (RUM) provider will not only deliver the INP value of a page, but also contextual data pinpointing the exact interaction that contributed to the INP value. This includes details such as whether the interaction took place during or after the page loaded, the nature of the interaction (click, keypress, or tap), among other insightful details.
On the screenshot below you can see which specific element is responsible for a slow interaction. The screenshot below that one shows what INP phases are responsible for the high INP value. With this information you have a head start on optimizing your INP.
What if you don't have access to RUM data?
If you're not using a RUM tool for field data, you can use the Chrome User Experience Report (CrUX) via PageSpeed Insights, as suggested by the INP field data guide. While CrUX offers extensive metric summaries, including INP, it lacks the detailed context provided by a RUM provider. Hence, we recommend using a RUM provider, or devising your own RUM solution to complement CrUX data.
You could also start with looking at the lab data tools listed above.
Conclusion
To conclude, optimizing the responsiveness of your website or webshop is critical for user satisfaction and engagement. INP, as a Core Web Vitals metric, is a comprehensive measure of interaction latency, considering all the user interactions such as clicks, taps, and keypresses.
The best way to diagnose and address issues related to INP is by leveraging field data from a Real User Monitoring (RUM) provider, which gives valuable insights into the exact interactions causing high INP values. If a RUM provider isn't available, Chrome User Experience Report (CrUX) via PageSpeed Insights can be utilized, although it doesn't provide as detailed context.
Remember, a good INP score (200 milliseconds or less) ensures snappy and smooth interactions, encouraging users to stay longer and make purchases. Factors like device memory can impact INP and should be taken into consideration when aiming for optimal Core Web Vitals.
Ultimately, keeping track of INP and continuously striving to improve it will lead to better overall website performance, enhanced user experience, and improved SEO rankings.
