Interaction To Next Paint
Interaction to Next Paint, often shortened to INP, is a Core Web Vital that measures how quickly a web page responds after a user clicks, taps, or types. It looks at the time between a user interaction and the next visible update on the screen, which makes it a practical way to judge whether a website feels fast, smooth, and responsive.
Responsiveness matters because users do not only judge a website by how quickly it loads. They also care about what happens after they start using it. If you have ever clicked a button and wondered whether the page has frozen, that moment of doubt is exactly what INP helps to measure. When someone taps a menu, selects a product filter, or clicks an add to basket button, they expect a clear response almost instantly.
INP replaced First Input Delay as the Core Web Vital for responsiveness in March 2024. That change matters because INP gives a fuller picture of page experience by measuring qualifying interactions throughout the visit, not just the first one. For website owners, marketers, and developers, it is now one of the key technical performance metrics to understand.
Core Web Vitals can feel frustrating, especially when a site looks fine but still feels slow to users. If you are trying to understand why that happens, C2 Marketing helps businesses improve their online presence through practical SEO, web design, and development support. By combining technical insight with clear marketing strategy, C2 Marketing helps websites perform better for users and search engines without making the process feel more complicated than it needs to be.
What Interaction To Next Paint Means
Interaction to Next Paint is a measure of page responsiveness. In simple terms, it checks how long it takes for the page to show a visible response after someone interacts with it. A fast INP means the page reacts quickly, while a poor INP suggests users may experience lag, hesitation, or delayed feedback.
The name sounds technical, but each part is fairly straightforward. An interaction is a click, tap, or keyboard action. Next means the next frame the browser shows after that action, while paint means the visible update the browser displays on screen, such as a button changing state, a menu opening, or a form field responding.
Take an e commerce example. A shopper clicks an add to basket button, the website runs the code linked to that click, updates the basket count, and shows a visual confirmation. INP measures the time from the click to the point where the browser paints that visible confirmation. It does not mean every background task is fully finished, but it does measure whether the user sees that the page has responded.
What Does INP Measure?
INP measures qualifying interactions that usually matter most to users. These include mouse clicks, touchscreen taps, and keyboard presses. These are the actions people use to navigate websites, complete forms, open menus, select options, and move through checkout steps.
INP does not measure every possible action. Scrolling, hovering, and zooming are not qualifying INP interactions. A page may still feel poor if scrolling is jumpy, but that issue is handled separately from INP because the metric focuses on clear actions that trigger a response from the page.
Behind the scenes, several things happen during an interaction. The browser receives the user action, waits for the main thread to become available, runs any event handlers linked to the action, calculates any style or layout changes, then paints the next visual frame. The main thread is the part of the browser that handles important work such as running JavaScript and updating the page. Think of it like a busy member of staff. If it is already dealing with too much, it cannot respond to the next request straight away.
For official definitions and current thresholds, Google's Core Web Vitals guidance is a useful reference. It explains how INP fits within page experience, alongside loading performance and visual stability.
Interaction To Next Paint Score Thresholds
A good INP score is 200 milliseconds or less. That means the page usually responds quickly enough for users to feel that it is reacting straight away. When INP moves above that level, delays become more noticeable, especially on mobile devices or pages with lots of interactive elements.
The main INP score thresholds are simple to understand and useful for prioritising improvements. Use them as a practical benchmark when reviewing field data, mobile performance, and key user journeys.
- 200 milliseconds or less: Good responsiveness, where interactions feel quick and smooth.
- More than 200 milliseconds and up to 500 milliseconds: Needs improvement, where users may notice a delay after interacting.
- More than 500 milliseconds: Poor responsiveness, where the page can feel sluggish or unresponsive.
These thresholds are assessed using the 75th percentile of page visits, usually separated by mobile and desktop. That means the score reflects what most users experience, while still paying attention to slower visits. Mobile scores can be worse than desktop scores because phones often have less processing power, variable network conditions, and more demanding touch based interactions.
How Is INP Calculated?
INP is calculated by observing qualifying interactions during the full page visit. Rather than averaging every click and key press, it generally reflects the slowest meaningful interaction on the page. For pages with many interactions, some outlier handling is applied so one unusual event does not unfairly distort the final value.
This is an important point because INP is not an average response time. A page could respond well to most clicks but still have a poor INP if one key interaction is very slow. For example, a product page might open tabs quickly, but the size selector could freeze briefly because it triggers heavy JavaScript and layout changes.
Pages can also have no INP data. That may happen if users do not click, tap, or type during their visit, or if there is not enough real user data available. It can also happen when users mostly scroll or hover because those actions do not count as qualifying INP interactions.
INP Versus FID
INP replaced First Input Delay because it gives a more complete picture of responsiveness. FID only measured the delay before the browser started responding to the first interaction. It did not include the time spent running event code or painting the visible result, and it ignored later interactions.
INP is broader because it looks at qualifying interactions throughout the visit. It includes input delay, processing duration, and presentation delay, which means it measures more of what the user actually experiences. If a page loads well but becomes slow when someone opens filters, uses a calculator, or fills out a form, INP is much more likely to show that problem.
A simple comparison helps when deciding why INP is now the more useful metric. FID looked mainly at whether the browser could begin responding, while INP focuses on whether the user actually sees a response quickly.
- FID: Measured only the first interaction and focused on initial input delay.
- INP: Measures qualifying interactions throughout the visit and includes the visible response.
- FID: Was useful for early page responsiveness.
- INP: Is better for judging overall page responsiveness.
The Three Parts Of INP
INP can be understood in three parts: input delay, processing duration, and presentation delay. Breaking the metric down like this makes it easier to diagnose what is actually going wrong. A poor score does not always have the same cause, so guessing can waste time.
Input Delay
Input delay is the time between the user action and the moment the browser starts processing it. This often happens when the main thread is already busy with other work, such as loading scripts, processing tracking tags, or handling other JavaScript tasks. If the browser cannot start dealing with the click straight away, the user feels a delay.
Processing Duration
Processing duration is the time spent running the code linked to the interaction. This could include updating a basket, opening a complex menu, filtering products, or validating form fields. Heavy event handlers, large calculations, and unnecessary state changes can all make this stage slower than it needs to be.
Presentation Delay
Presentation delay is the time between the code finishing and the browser painting the visual result. This can be affected by complex layouts, large page structures, animation effects, or forced layout recalculations. In plain English, the browser may know what needs to change, but it still has to work hard to show it on screen.
Why Your INP Score May Be Poor
A poor INP score is usually linked to too much work happening at the wrong time. The most common cause is heavy JavaScript, especially when scripts block the main thread during page load or when a user tries to interact. This can happen on custom websites, e commerce stores, and content management systems with lots of plugins or third party tools.
Large page structures can also hurt responsiveness. The DOM, which is the browser's structure for the page, becomes harder to update when it is huge or overly complex. If a click triggers changes across many elements, the browser may need more time to calculate layout and paint the result.
Third party scripts are another common issue. Chat widgets, tracking tags, pop ups, review tools, advertising scripts, and animation libraries can all add extra work. These tools may be useful, but when too many run at once, they can compete with the user's interaction and slow down the response.
Different websites tend to have different risk areas. If you run an e commerce site, you should check filters, basket buttons, variant selectors, and checkout fields. If you manage a publishing site, test search, navigation, and comment forms. Lead generation sites should look closely at forms, calculators, and mobile menus, while software platforms should test dashboards, editors, and drag based controls.
How To Measure INP
The best way to measure INP is to start with field data, then use lab tools to investigate. Field data comes from real users on real devices, so it reflects what people actually experience. Lab data is collected in a controlled test environment, which is useful for diagnosis but may not reproduce every real world interaction.
Google Search Console is a good starting point because its Core Web Vitals report groups affected URLs and separates mobile and desktop performance. It helps you spot patterns, such as a template that performs poorly across many product pages. If you are already reviewing wider search performance, our article on how Google Search Console tracks rankings explains how to interpret Search Console data with more confidence.
PageSpeed Insights can show field data from the Chrome User Experience Report when enough data is available. It also includes Lighthouse lab results, which can help highlight performance opportunities. The important thing to remember is that a lab test may not click the same menu, filter, or form field that real users struggle with.
Chrome DevTools is useful when you need to reproduce a slow interaction. You can record a performance trace, click through common user journeys, and look for long tasks, delayed event handling, or expensive rendering work. Developers can also use real user monitoring with the web vitals library to capture INP alongside useful context such as device type, page URL, and interaction type.
How To Improve INP
Improving INP usually starts with reducing unnecessary JavaScript. Remove scripts that do not add value, delay non essential code, and split large bundles so the browser has less work to do at once. This gives the main thread more breathing room, which helps clicks, taps, and keyboard actions get processed more quickly.
Event callbacks should also be kept as small as possible. An event callback is the code that runs when someone interacts with the page, such as clicking a button. The best approach is to do only the work needed for the next visible update, then defer secondary tasks such as analytics, saving preferences, or background calculations until after the page has responded.
Presentation delay can often be reduced by simplifying layouts and avoiding unnecessary visual work. Large DOM structures, complex animations, and repeated layout calculations can all make the browser work harder. If your site has recurring visual stability issues as well, our guide on reducing Cumulative Layout Shift is a helpful next read because many performance improvements overlap.
For content management systems, review plugins, pop ups, sliders, menu scripts, and tracking tools carefully. You do not always need a full rebuild to improve INP. Often, the quickest wins come from removing unused features, replacing heavy scripts, simplifying interactive components, and improving how code loads on mobile.
INP And SEO
INP is part of Core Web Vitals, so it has a role in how Google understands page experience. However, it should not be treated as a simple ranking switch where one poor score automatically causes a page to drop. Search performance depends on many factors, including content quality, relevance, authority, technical accessibility, and user satisfaction.
That said, a poor INP can still affect business results. If users hesitate because filters lag, forms feel slow, or checkout buttons do not respond quickly, conversions can suffer. This is where technical performance and marketing performance meet because a fast, responsive website supports both search visibility and user trust.
If your website needs wider technical support, C2 Marketing's website design and development team can help identify the issues that affect performance, usability, and conversions. Good INP optimisation is rarely about chasing a number in isolation. It is about making the whole experience feel easier and more reliable.
INP Optimisation Checklist
A structured process makes INP work far more manageable. Start with real user data, identify the affected pages, then reproduce the slow interactions before making changes. This helps you focus effort where it will have the biggest impact.
- Check the Core Web Vitals report in Google Search Console.
- Separate mobile and desktop issues rather than treating them as one problem.
- Identify affected templates, such as product pages, category pages, or lead forms.
- Test common clicks, taps, and keyboard flows on realistic devices.
- Use DevTools to find long tasks and slow interaction timings.
- Reduce unnecessary JavaScript and third party script activity.
- Simplify event handlers so the visible response happens quickly.
- Reduce large DOM structures, heavy animation, and repeated layout work.
- Retest after changes and monitor field data over the following weeks.
Field data can take time to reflect improvements because it depends on real users visiting the updated pages. Do not panic if Search Console does not change the next day. Look for movement over time, and keep testing the interactions that matter most to your users.
Final Thoughts
Interaction to Next Paint is one of the clearest ways to understand whether a website feels responsive after people start using it. It measures the delay between a click, tap, or keyboard action and the next visible update, which makes it closely tied to real user experience. A good INP score is 200 milliseconds or less, while anything above 500 milliseconds needs urgent attention.
The most effective improvements usually come from reducing main thread work, trimming unnecessary JavaScript, simplifying event handlers, and making visual updates easier for the browser to paint. Start with field data, diagnose the specific slow interactions, then fix the root cause rather than chasing generic performance scores. You do not need to fix everything at once. Begin with the interactions that matter most to your users, and small, focused improvements can quickly make the website feel faster, calmer, and more reliable.
Frequently Asked Questions
What Is A Good INP Score?
A good INP score is 200 milliseconds or less. Scores above 200 milliseconds may need improvement, while anything above 500 milliseconds is considered poor.
Does INP Measure Scrolling?
No, INP does not measure scrolling, hovering, or zooming. It focuses on qualifying interactions such as clicks, taps, and keyboard actions.
Why Did INP Replace FID?
INP replaced FID because it measures responsiveness across the full visit, not just the first interaction. It also includes processing and visual presentation time, so it reflects user experience more completely.
Can A Page Have A Good Lighthouse Score But Poor INP?
Yes, this can happen because Lighthouse is a lab test and may not reproduce the same interactions as real users. Field data is usually better for confirming real INP issues.
How Long Does It Take For INP Improvements To Show?
Search Console and field data can take several weeks to reflect changes because they depend on real user visits. Lab tools can show whether fixes are working sooner, but field data is the final confirmation.
