What is Interaction to Next Paint (INP)?

There’s a new metric for measuring how a page measuring how responsive your website feels to users, and it’s called Interaction to Next Paint, or INP. If you follow web performance metrics, you’ve probably seen the discussion around this Core Web Vital since Google adopted it in March 2024. Understanding INP isn’t about ticking another SEO box. It’s about improving how people experience your site when they click, tap, or type.

Here’s what this guide covers. We’ll look at how INP works, how it differs from other web vitals you might already know, and practical ways to ways to measure and improve this metric. Whether you’re a developer fighting sluggish interactions or a business owner trying to understand why visitors bounce, this article gives you the tools to handle INP.

Understanding INP fundamentals

Let’s start with the basics. INP changes how we think about web performance measurement. Traditional metrics focus on loading speed, but INP measures how quickly your site responds when someone tries to interact with it.

Definition and core concepts

Interaction to Next Paint measures the time between when a user initiates an interaction (like clicking a button or typing in a form) and when the browser presents the next visual update on screen. Think of it as response time in a conversation: you ask a question, and INP measures how long it takes to get a visual acknowledgment that you’ve been heard.

What makes INP useful is its scope. It doesn’t just look at one interaction. It evaluates every interaction during a user’s session and reports the worst case (technically the 98th percentile, but more on that later). This gives you a realistic picture of what your slowest users experience, not just the ones who hit your site during off-peak hours.

From my experience working with various websites, this metric reveals hidden bottlenecks that other measurements miss entirely. A site might load quickly but feel sluggish when you actually use it, and that’s exactly what INP captures.

INP vs other web vitals

Here’s where it gets interesting. You’ve probably heard of First Input Delay (FID), which INP is replacing as a Core Web Vital. But the difference between these two metrics is like comparing a snapshot to a full movie.

FID only measured the delay before the browser started processing the first interaction, essentially just the input delay portion. It was like timing how long someone takes to pick up the phone when you call, but ignoring how long the conversation lasts. INP measures the whole interaction from start to finish, including processing time and rendering the visual response.

The threshold difference tells a story too. FID aimed for under 100ms, while INP allows up to 200ms for a “good” score. This isn’t because Google got more lenient. It’s because INP measures more of the interaction process, which makes it harder to optimise.

Browser event processing mechanics

Let me walk through what happens when someone clicks that “Add to Cart” button on your site. The browser’s event processing pipeline runs through several distinct phases, and understanding this explains why some interactions feel snappy while others make users want to throw their devices out the window.

When an interaction occurs, the browser goes through three phases: input delay, processing time, and presentation delay. Input delay is the time between the user’s action and when the browser can start processing it, which happens when the main thread is busy with other tasks. Processing time covers the actual execution of event handlers, including any JavaScript that needs to run. Presentation delay is the time needed to render and paint the visual changes to the screen.

Here’s something that surprised me when I first started optimising for INP: sometimes the processing phase is very fast, but the presentation delay kills your score. This happens when you trigger expensive DOM manipulations or force the browser to recalculate layouts and styles. It’s like having a sports car with flat tyres. All that processing power means nothing if you can’t get the results to the screen efficiently.

INP measurement and calculation

Let’s get into how INP actually works under the hood. Understanding the measurement methodology tells you what you’re optimising for and why certain improvements work while others don’t.

Event duration components

Think of INP measurement like timing a relay race with three legs. Each component adds to the total duration, and weakness in any single area can wreck your overall performance.

The first component, input delay, measures how long the browser waits before it can start processing your interaction. This delay usually happens when the main thread is blocked by long-running JavaScript tasks. I’ve seen sites where this delay alone accounts for 80% of their INP score, usually because of poorly optimised third-party scripts or heavy analytics code running at the worst possible moment.

Processing duration covers the time spent actually executing event handlers and related JavaScript. This includes everything from simple click handlers to complex state updates in frameworks like React or Vue. The tricky part is that processing time varies wildly depending on what else is happening in your application at that moment.

Presentation delay, the final piece, measures how long it takes to render the visual changes after processing completes. This phase often gets overlooked, but it’s where many optimisations fall flat. You might have very fast JavaScript, but if you’re triggering expensive reflows or repaints, your users will still experience sluggish interactions.

Percentile-based scoring system

Here’s where INP gets clever, and where it differs sharply from other performance metrics. Instead of reporting average response times or even the slowest interaction, INP uses the 98th percentile of all interactions during a user’s visit.

Why the 98th percentile? Google’s research shows this balances the typical user experience against genuinely problematic interactions. If they used the average, a few fast clicks could mask seriously sluggish ones. If they used the worst case, a single odd interaction (maybe during a temporary network hiccup) could unfairly penalise an otherwise responsive site.

Let me use some real numbers. Imagine a user session with 50 interactions ranging from 50ms to 800ms. The 98th percentile captures the second-worst interaction, giving you insight into the poor experience without being thrown off by a single outlier. It’s like judging a restaurant based on most of your visits, not just the one time they were slammed on Valentine’s Day.

Measurement tools and APIs

Now let’s talk about actually measuring INP. You’ve got several tools available, each with its own strengths and blind spots.

The Web Vitals JavaScript library is your go-to for real user monitoring. It’s lightweight, reliable, and gives you the same measurements Google uses for ranking. Here’s a basic implementation:

import {onINP} from 'web-vitals';
onINP(console.log);

For lab testing, Chrome DevTools and Lighthouse give you detailed breakdowns of interaction performance. The User Interactions timeline in DevTools is especially useful, since it shows exactly which phase is causing problems for specific interactions. According to WP Rocket’s comprehensive guide, this visual approach often reveals issues that raw numbers miss.

PageSpeed Insights gives you field data from real users, which matters because lab conditions rarely match real-world usage. I’ve seen sites that test beautifully in controlled environments but struggle with actual user interactions because of network conditions, device capabilities, or usage patterns that testing didn’t account for.

Data collection methods

There are two main ways to collect INP data: Real User Monitoring (RUM) and synthetic testing. Each has its place, and honestly, you need both to get the full picture.

RUM data comes from actual users visiting your site with all their real-world constraints: slow networks, older devices, background applications competing for resources. This data is valuable because it reflects genuine user experiences, but it can be noisy and hard to interpret. Chrome User Experience Report (CrUX) provides this kind of data aggregated across millions of users.

Synthetic testing gives you controlled, reproducible measurements. Tools like WebPageTest and Lighthouse let you test specific scenarios and device configurations. The downside is that these controlled conditions might not represent your actual user base. I’ve learned to use synthetic testing for debugging and optimisation, then validate improvements with RUM data.

For businesses looking to improve their web presence and their performance metrics, listing in quality web directories like Web Directory can help drive more traffic to your optimised site while providing backlinks that support your SEO efforts.

Effective data collection depends on setting up proper attribution. You need to know not just that an interaction was slow, but which specific element, event type, and user context contributed to the problem. Modern RUM solutions can provide this detail, helping you prioritise fixes based on actual user impact rather than guesswork.

That said, don’t get lost in the data. I’ve seen teams spend months perfecting their measurement setup while their users keep suffering from poor responsiveness. Start measuring quickly with basic tools, then refine your approach as you learn more about your specific performance challenges.

Where INP goes next

INP is more than another metric to optimise. It measures what actually matters to users. The web is getting more interactive, and loading metrics alone don’t capture the full user experience anymore.

The future of web performance measurement will likely bring more sophisticated ways to understand user experience. We’re already seeing experiments with metrics that consider user intent, device capabilities, and contextual factors. But for now, mastering INP gives you a real advantage in creating websites that not only load quickly but feel genuinely responsive and engaging.

Optimising for INP isn’t only about hitting Google’s thresholds. It’s about creating digital experiences that respect your users‘ time and attention. In an increasingly impatient world, the difference between a 150ms and a 300ms interaction response can be the difference between a satisfied customer and a lost opportunity.

The tools and techniques for measuring and improving INP will keep evolving, but the principle stays the same: responsive interactions create better user experiences, which drive better business outcomes. Whether you’re running a small business website or managing a complex web application, understanding and optimising INP should be a core part of your performance strategy.