What Is Interaction To Next Paint (INP)

Interaction to Next Paint (INP) is an upcoming web performance metric that will replace First Input Delay (FID) in March 2024. INP measures a website’s overall responsiveness to user interactions throughout the entire lifespan of a user’s visit. While FID only looks at the first interaction on a page, INP samples all user interactions to provide a more comprehensive view of responsiveness.

What Is INP?

INP measures the time from when a user initiates an interaction like clicking, tapping, or pressing a key to the time when the browser can respond to that interaction by painting the next frame. A lower INP value indicates better responsiveness, as it suggests the website consistently provides quick visual feedback in response to interactions.

INP calculates a single value that represents a website’s overall responsiveness. It does this by recording the latency of all observed interactions and reporting the longest duration, excluding outliers. Interactions considered include clicks, taps, and key presses. Hovering and scrolling are not factored into INP.

INP measures interactions in both the main document and any embedded iframes, as users do not differentiate between them. However, JavaScript APIs may not have access to iframe content, which can cause differences between CrUX and RUM data for pages with iframes.

Each interaction may involve multiple events. For example, a click includes pointer down, pointer up, and click events. INP uses the longest event duration to represent the interaction latency. The final INP value reflects the longest observed interaction latency that occurred before the user left the page.

How INP Differs From FID

While FID focuses solely on responsiveness during page load by measuring input delay on the first interaction, INP provides a comprehensive view of responsiveness throughout the entire user journey. Since users spend most of their time on a page after it finishes loading, INP offers a more realistic assessment of overall interactivity.

FID also only measures input delay – the time from the interaction to when event handlers start executing. INP captures the full duration from interaction start to the next paint, including any time running event handlers and rendering the updated UI.

What Is A Good INP Score?

Pinning a “good” or “bad” label on responsiveness metrics can be tricky. Hardware capabilities vary widely amongst devices people use. However, for reference, INP benchmarks based on 

Chrome data suggest:

INP below or equal to 200ms indicates good responsiveness

INP above 200ms but below or equal to 500ms needs improvement

INP above 500ms indicates poor responsiveness

Measuring INP

INP can be measured both in the field using real user data and in controlled lab environments. Field data provides the most accurate view of real-world responsiveness.

Measuring INP in the Field

Real user monitoring (RUM) solutions offer the most insightful INP data by capturing values alongside contextual details like the specific interaction responsible and whether it occurred during page load.

The Chrome User Experience Report (CrUX) provides quick, high-level INP data for sites meeting the inclusion criteria. PageSpeed Insights integrates CrUX data to display field values for INP and other Core Web Vitals. However, CrUX lacks the granularity to identify issues. RUM provides the detail needed to pinpoint and fix slow interactions.

Measuring INP in the Lab

When real user data is unavailable, simulating user journeys and interactions in a controlled environment can approximate INP values. Focus on flows with many interactions and test during page load when main thread contention often causes sluggishness. Comparing lab and field data can reveal gaps between simulated and real user experiences.

What Causes Poor INP Scores?

Several factors can degrade INP and responsiveness.

JavaScript tasks blocking the main thread – This is the most common culprit. JavaScript shares a single thread with painting and user interactions. Long tasks block this thread and prevent handling input or updating the UI.

Throttled network and devices – Slow networks and underpowered devices delay resource loading and introduce lag when handling user input.

Badly timed/implemented animations – Complex CSS animations and transitions that occur while handling user input can block rendering.

Expensive layout operations – Forced synchronous layouts or manipulating DOM nodes during input can freeze the UI.

Unoptimised images – Large, unoptimised images delay loading and main thread operations.

Third-party scripts – Unoptimised third-party code can introduce blocking tasks and bloat page resources.

Improving INP

Here are some techniques to optimise INP.

• Minimise main thread work – Defer non-essential work until later. Load third-party code lazily.
• Use web workers for heavy tasks – Offload expensive computations to background threads.
• Implement virtual scrolling – Only render visible content. Reuse DOM elements.
• Reduce image sizes and use advanced loading techniques – Employ responsive images, new formats like AVIF, and lazy loading.
• Preload key resources – Use <link rel=preload> to fetch important assets early.
• Use passive event listeners – Avoid blocking input handling with touch and wheel listeners.
• Optimise third-party scripts – Lazy load or defer unneeded third-party code.
• Monitor INP in production – Fix regressions when they happen by tracking INP in the field.
• Set performance budgets – Prevent regressions by setting targets for INP and other metrics.
• Test on slow networks and devices – Experience low-end hardware limitations firsthand.
• Analyse user flows – Identify pain points in journeys with many interactions.
• Prioritise optimising post-load – Most time is spent after the load finishes, so keep enhancing.

Conclusion

INP provides a comprehensive measure of overall website responsiveness that considers the entire user journey beyond just the initial page load. By sampling all user interactions instead of just the first, INP offers a more realistic assessment of interactivity.

Field data is ideal for accurately measuring real-world INP. Lab testing can also approximate values in the absence of field data. An INP below 200ms provides good responsiveness, while over 500ms indicates poor interactivity.

Optimising INP involves minimising main thread activity, managing resources effectively, and continuously monitoring and improving real user experiences. Given the metric’s broad scope, improving INP requires holistic performance practices beyond just optimising page load speed.