Core Web Vitals: INP indicator - definition and key thresholds
The Core Web Vitals INP indicator has become a central benchmark for assessing how responsive a website is. Google has developed its criteria in order to better reflect the quality perceived by the user, beyond a simple loading time shown on the surface. The challenge is now clear: to understand what happens between the action and the visual feedback.
This metric helps analyse the real performance of a web page when a click, a tap or a keystroke triggers a response. It complements the reading of the other quality signals linked to the user experience and technical optimisation. For product, marketing and development teams, it makes it possible to pinpoint more precisely what is slowing down the interface.
The following sections explain the definition, the thresholds, the calculation, the causes of a poor result and the concrete levers for improving responsiveness. The aim is to understand how to measure, diagnose and optimise without confusing lab tests with field data.
What is INP (Interaction to Next Paint)?
Interaction to Next Paint measures the delay between a user action and the display of the corresponding visual feedback. In practice, it is the time needed for the browser to process the event and then render the next visible paint on screen. The shorter this delay, the better the perceived responsiveness.
This metric is not limited to a single type of action. It takes into account clicks, taps on a touchscreen, keyboard input and other common interactions. That is what makes it a more representative indicator of the user experience than an isolated measurement on a single event.
What INP really assesses
The principle is simple: an action triggers some processing, then the browser has to be able to paint a visible response. Interaction to next paint assesses the overall latency of this chain, with a field-oriented reading. The aim is not just to run code, but to optimise the feeling of smoothness.
- The delay before processing begins.
- The time spent running the associated callbacks and scripts.
- The time needed to display the result on screen.
Within the Core Web Vitals, this approach helps Google better understand a page's responsiveness under real conditions. It also provides a more useful framework for prioritising technical optimisation.
Why did INP replace FID?
Google replaced FID with INP in March 2024 in order to have a more complete indicator. FID only measured the first interaction, which left out the slowdowns appearing after the initial load. INP now covers all the interactions observed during the visit.
This change is important, because a page can behave well on the first click and then become slow afterwards. With FID, this deterioration remained invisible. With INP, Google better assesses the quality of responsiveness across the whole lifespan of the session.
The limits of FID
FID only measured the delay of the first action, without taking the final rendering into account. As a result, it could underestimate the performance issues experienced by the user. Google therefore introduced an indicator that is more representative of real-world use.
- FID only handled a single event.
- It did not capture slowdowns after the first contact.
- It was less useful for diagnosing rich interfaces.
The move from FID to INP, made official in March, brings the Core Web Vitals closer to the experience actually lived by users. It is also an invitation to optimise the whole interactive journey, and not just the first impression.
What are the thresholds for a good INP score?
The reference thresholds let you quickly assess whether a website's responsiveness is satisfactory. Google generally distinguishes three levels: good, needs improvement and poor. The most commonly used benchmarks are 200 ms and 500 ms.
A result below 200 ms is considered high-performing for most contexts. Between 200 and 500 ms, it becomes necessary to optimise certain elements. Beyond 500 ms, the responsiveness is often perceived as detrimental.
Reading the thresholds methodically
Looking at an isolated value is not enough to understand the overall behaviour. You also need to assess the stability of the interactions and the slowest cases observed among real users. Google in fact relies on field data to establish this diagnosis.
- Less than 200 ms: satisfactory responsiveness.
- Between 200 and 500 ms: optimisation recommended.
- More than 500 ms: high improvement priority.
These thresholds serve as a basis for steering optimisation. They also let you assess the impact of a code change, a new script or a new feature on performance.
How to measure INP with real data?
Official INP relies on field data, that is, on interactions actually observed among users. Lab tests are useful for understanding the problem, but they do not provide the official measurement. To track this indicator, you should therefore favour signals collected in real life.
The most common sources include CrUX, Google Search Console and certain RUM tools. They offer a more reliable view of perceived performance across different devices, networks and browsing behaviours. This helps you better understand the variations depending on the context.
Where to find the useful data
Several tools can help you track responsiveness and compare the results over time. The important thing is to distinguish between the environments: field for the official measurement, lab for analysing the causes.
- Google Search Console to track the Core Web Vitals signals.
- PageSpeed Insights to cross-reference field data and recommendations.
- CrUX to observe the statistics from real visits.
- RUM solutions to measure behaviour on your site.
Good monitoring relies on this complementarity. Field data indicates what users experience, while diagnostic tools help you understand why performance is degrading.
Which tools should you use to analyse INP?
To analyse this metric, you need to combine several tools depending on the level of detail you are after. Field tools serve to assess real trends, while lab tools help isolate a specific problem. This approach gives a more reliable view of responsiveness.
Google recommends cross-referencing signals from several sources in order to better prioritise optimisations. An average result on a website does not mean the same thing depending on the volume of traffic, the type of devices or the most-used journeys.
The most useful tools
- PageSpeed Insights for a quick overview and optimisation ideas.
- Lighthouse to test scenarios in the lab.
- Chrome DevTools to record and analyse slow interactions.
- CrUX to check aggregated real-world data.
- RUM solutions to track the user experience continuously.
These tools do not all serve the same purpose. A lab tool does not replace field measurement, but it remains essential for understanding the technical causes and preparing an effective optimisation.
What are the causes of an INP that is too high?
A poor result often comes from a main thread saturated with tasks that are too heavy. When JavaScript monopolises the browser, the processing of events falls behind, and so does the final rendering. The consequence is direct: responsiveness drops and the user experience degrades.
The most frequent causes include long JavaScript tasks, an overly large DOM, expensive callbacks and rendering operations that are too heavy. You should also take into account third-party scripts, complex animations and repeated interface updates.
The main bottlenecks
- Long tasks on the main thread.
- Event callbacks that are too heavy.
- A DOM that is too rich or too deep.
- Non-essential scripts loaded too early.
- Visual rendering delayed after processing.
To understand the source of the problem, you need to separate the input delay, the processing time and the presentation delay. This reading helps you optimise in the right place, rather than applying general fixes with no real effect.
How to optimise JavaScript and callbacks to improve INP?
JavaScript optimisation is often the most effective lever for improving responsiveness. The first objective is to reduce the work carried out on the main thread. The less the browser is blocked, the faster it can respond to user actions.
You should also lighten the event callbacks. A callback should contain only the strict minimum, so as to limit the processing time and let the browser breathe. This logic directly improves the perceived smoothness.
Priority actions on the JavaScript side
- Remove unnecessary code and non-critical JavaScript.
- Break long tasks into shorter segments.
- Defer certain scripts with async or defer.
- Move heavy processing to Web Workers.
- Avoid expensive operations inside callbacks.
This code optimisation does not only affect response time. It also improves the stability of the interface on less powerful devices, where the slightest overload can become visible.
How to reduce the presentation delay after an interaction?
The presentation delay corresponds to the time needed to display the visual feedback after the logical processing. To improve this point, you need to reduce the cost of rendering and simplify the elements that have to be updated. A fast display reinforces the perception of smoothness.
Several techniques are useful: reducing the size of the DOM, avoiding expensive reflows, and using lazy rendering where it is relevant. Using content-visibility can also help to set aside areas that are not visible.
Effective techniques for rendering
- Reduce the number of elements being manipulated.
- Limit style and layout recalculations.
- Delay the display of secondary content.
- Hide off-screen areas with suitable techniques.
When rendering is lighter, the visual response arrives faster. This improves the perception of speed, even if part of the technical processing remains present in the background.
How to diagnose a poor INP in the lab and improve the user experience?
A lab diagnosis lets you reproduce the slow interactions and identify the bottlenecks. Chrome DevTools, Lighthouse in Timespan mode, the Web Vitals extension or Performance recordings are particularly useful for understanding what is blocking. They help you visualise the complete sequence between the event and the rendering.
It is also worth adding immediate visual feedback during long processing. A spinner, a confirmation message or an add-to-basket acknowledgement reassures the user and improves the perception of responsiveness, even if the total processing takes time. This kind of element does not replace a technical optimisation, but it improves the user experience.
What to check during the diagnosis
- The duration of the long JavaScript tasks.
- The moment when the browser can regain control.
- The real cost of rendering after the action.
- The presence of visual feedback elements.
This diagnostic work helps you understand which optimisations will have the most impact. It also makes it easier to prioritise between fixing the code, lightening the structure and improving the visual feedback.
What is the impact of INP on SEO?
The impact of this metric on search rankings exists mainly through the quality of the user experience. Google rewards sites capable of offering smooth, responsive navigation. A good result can therefore support your visibility in competitive contexts.
On the other hand, INP does not replace content, authority or editorial relevance. It acts as one quality signal among others. To obtain a lasting benefit, you need to integrate it into a broader optimisation strategy.
Why this indicator matters to Google
A slow interface can discourage use and increase drop-offs. Conversely, good responsiveness improves the overall perception of the website. Google takes this quality of use into account in its Core Web Vitals, which makes it an important element to track.
The best result comes from a balanced approach: useful content, a clear architecture and continuous technical optimisation. It is this combination that makes it possible to durably improve performance and user satisfaction.
In short, the Core Web Vitals INP indicator serves to assess the real responsiveness of a website, to diagnose bottlenecks and to guide priority optimisations. By measuring field data, lightening JavaScript and taking care over rendering, it becomes possible to improve performance and the perception of speed. For teams that want to strengthen their presence on Google, it is a concrete, useful and durable lever.
