A customer opens your site on their phone, taps the menu icon, and nothing happens. They tap again. Half a second later the menu opens and then immediately closes, because the second tap landed too. They have not complained to you. They have just quietly decided your site is a bit broken.
That moment is what Interaction to Next Paint was built to catch. This is interaction to next paint explained for site owners rather than developers: what INP measures, how a single number is pulled from a whole visit, why Google swapped it in for the older First Input Delay, and what tends to make a page feel laggy. Fixing it is a separate job, covered in its own post.
What is INP, in plain words
INP measures how long a page takes to visibly respond after someone interacts with it. The clock starts when the visitor taps, clicks or presses a key. It stops when the browser paints the next frame, meaning the first moment anything on screen can change in response.
Note what it does not wait for. It does not wait for a whole new page to load, or for a slow server request to come back. It only asks: after the tap, how long until the screen showed something? A spinner appearing straight away counts as a response. That is deliberate. Visitors are fine with “working on it”; what bothers them is a page that seems to ignore them.
Google considers INP good at 200 milliseconds or less, measured at the 75th percentile of real page visits. It is one of the three Core Web Vitals, alongside loading and visual stability, which our overview of all three Core Web Vitals introduces.
Interaction to Next Paint explained in three stages
Each tap or click goes through three stages before the visitor sees a result. Understanding these makes everything else about INP easier to follow.
- Input delay. The tap has happened, but the browser is busy with something else, usually running JavaScript, and cannot start dealing with it yet. Think of a shop assistant finishing a phone call before turning to you.
- Processing time. The browser runs the code attached to that tap: the menu script, the add-to-cart handler, the analytics event that fires on every click.
- Presentation delay. The code is done, and the browser now has to work out the new layout and paint it. On a very large or complicated page, this step alone can take noticeable time.
INP is the total of all three. A page can have a slow INP because it was busy when the tap arrived, because the code that runs on the tap is heavy, or because redrawing the page is expensive. Different causes, same symptom.
Which interactions count, and which do not
INP watches three kinds of input:
- Mouse clicks
- Taps on a touchscreen
- Key presses, physical or on-screen keyboard
It does not count scrolling, hovering, or pinch-zooming. Scrolling is handled differently by browsers and is measured in other ways. Hover is not an interaction a phone user can make anyway.
That list explains why certain pages suffer more than others. A blog post that people mostly scroll may have almost no interactions to measure. A product page where visitors pick a size, change the quantity, open a gallery and add to cart has many, and every one is a chance to be slow. Forms are another hotspot: each key press in a search box with live suggestions is an interaction.
How one number comes out of a whole visit
A single visit can include dozens of interactions. INP does not average them, because an average would hide the one awful freeze. Nor does it take the very worst one on a long visit, because one strange hiccup in a hundred taps would be unfair.
This is the part of INP that gets explained least often, and it matters. Roughly, INP reports the slowest interaction on the page. On pages with a lot of interactions, the browser ignores a small number of the very worst outliers, so the figure lands close to, but not quite at, the single worst. For most small business pages, where a visitor taps a handful of times, it is effectively the slowest tap.
Then, as with the other Core Web Vitals, Google takes the 75th percentile across all real visits to that page or site. So your INP is “the slow-ish interaction that three in four visitors would not get worse than”.
Why INP replaced First Input Delay
Before March 2024, the responsiveness metric in Core Web Vitals was First Input Delay (FID). The name gives away both of its weaknesses.
- “First”. FID only looked at the first interaction on a page. If the page responded well to the first tap and then froze on every one after it, FID never noticed.
- “Delay”. FID only measured the input delay, the waiting before the browser started handling the tap. It ignored the time spent running the code and the time spent redrawing the screen.
In practice, a great many sites passed FID easily, including plenty that felt sluggish to use. It was not telling owners much. INP looks at every interaction through the visit and counts the full time until something visible changes, so it lines up far better with what people actually feel when a page is “laggy”.
The practical effect for many site owners was a sudden change in Search Console: a site that had always passed responsiveness started showing INP issues on mobile. Nothing on the site had got worse. The measurement had become more honest.
What makes pages feel laggy to taps
The detailed diagnosis and fixes belong in our step-by-step post on fixing a poor INP. Here is the short list of usual suspects, so you can recognise them.
The main thread is busy
Browsers run most page code on a single “main thread”. While a long piece of JavaScript is running, the page cannot respond to anything else. Tasks that take longer than 50 milliseconds are called long tasks, and pages with many of them tend to have poor input delay. This is very common in the first few seconds after a page loads, when every script is starting up at once.
Too much script, much of it not yours
Analytics, ad pixels, heatmaps, tag managers, chat widgets, consent tools and review badges all run code on your page. Some of them also attach their own listeners to clicks so they can record what visitors do. Each one adds work to every tap. The issue of third-party scripts and what they cost deserves its own audit.
Heavy handlers on common actions
Some themes and plugins do a lot when you tap: recalculating prices, re-rendering a large section of the page, updating several widgets at once. A filter on a shop page that redraws the whole product grid on every checkbox is a typical example.
A very large page
Pages built with deeply nested page-builder sections can contain thousands of HTML elements. Every time something changes, the browser has more to recalculate. This shows up as presentation delay even when the code itself is quick.
Slow phones
A visitor on a mid-range or older Android phone has far less processing power than your laptop. The same script that runs instantly for you can take several times longer for them. Since INP is based on real visitors, their phones are what count.
Where you can see your INP
Because INP needs real people interacting, it comes from field data: PageSpeed Insights shows it in the top section when your page or site has enough Chrome traffic, and Search Console’s Core Web Vitals report flags URL groups with INP issues.
Lab tools such as Lighthouse cannot measure INP, since no one taps anything during an automated load test. They show Total Blocking Time instead, which estimates how busy the main thread was during loading. It is a useful hint, not the same thing. If your lab score looks fine but field INP is poor, that is normal; the difference between the two kinds of data is explained in why real-user and test numbers differ.
To feel it yourself, open the site on an ordinary phone, not a flagship, and use it as a customer would: open the menu, use the search, change a product option, open a form. In Chrome on a computer, the DevTools Performance panel also shows INP live as you click, which helps you narrow down which interaction is slow.
For how responsiveness fits into speed as a whole, from server to scripts, the guide to website performance covers the full set of moving parts.
Frequently asked questions
Why does Search Console say my INP is poor when the site feels fine to me?
You are probably testing on a fast computer or phone over good Wi-Fi, after the page has finished loading. Many real visitors use slower phones and tap while scripts are still starting up. INP reflects their experience at the 75th percentile, so it can be poor even when the site feels responsive on your own devices.
Does a slow server make INP worse?
Usually not directly. INP stops measuring at the next visual update, so waiting for a server reply after a tap is not counted if the page shows a loading state straight away. Server speed matters much more for loading metrics. INP problems are mostly about work done in the browser, especially JavaScript.
Can a page have no INP value at all?
Yes. If visitors only scroll and never click, tap or type, there are no interactions to measure for those visits. Pages with very little traffic may also lack enough data for Google to report anything. In those cases you will see no INP figure in field reports, which is not a fault.
Responsiveness problems usually come down to scripts, which is why a third-party script audit and JavaScript deferral are both part of our website speed optimisation service. Each change is agreed with you before it is made, and the site is re-tested afterwards.
Next in this series: How to Fix Poor INP: Finding the Slow Interaction
