DefinitieA Core Web Vitals metric that measures how quickly a page visibly responds to user interactions such as clicks, taps and key presses. Good is 200 milliseconds or less.
Interaction to Next Paint (INP) is a Core Web Vitals metric that measures how quickly a page visibly responds to user interactions such as clicks, taps and key presses, across the whole visit. Good is 200 milliseconds or less, needs improvement runs up to 500 milliseconds, and anything above that counts as poor. Google judges it at the 75th percentile of real visitors, so sluggish clicks on your customers’ phones decide the score, not a test on your own laptop.
The common misunderstanding is that INP is about the first click only. That was First Input Delay (FID), which INP replaced as a Core Web Vital in March 2024. Interaction to next paint looks at the worst, or near worst, interaction of the whole visit. A shop can load fast and still fail INP because the size selector on the product page freezes for half a second every time someone changes a variant.
Why INP matters for a webshop
Interactions are where money changes hands. Adding to cart, opening the filter panel, choosing a delivery option, typing a postcode: every one of those is an interaction that INP measures. If the page takes 600 milliseconds to react, a visitor taps again, adds two items, or assumes the button is broken and leaves. I have watched session recordings where someone pressed “In winkelwagen” three times because nothing visibly happened. That lost conversion never shows up in a loading-speed report.
INP is also one of the three metrics behind the page experience signals Google uses, next to LCP and CLS. The ranking effect is modest and varies by study, so I do not sell it as a ranking lever. I sell it as a conversion lever that happens to keep Search Console green. For a PrestaShop or WooCommerce shop with heavy category filters, a poor INP is usually the first symptom of a JavaScript problem that also slows down everything else.
How to measure INP
Start with field data, because INP is defined on real visitors. PageSpeed Insights shows the 75th percentile from the Chrome User Experience Report at the top of the result, and the Core Web Vitals report in Google Search Console groups URLs with poor INP so you can see which templates are affected. For a quick check across several URLs I use the Core Web Vitals Checker on this site, which pulls the same field data without the clicking around.
To find the cause I move to the lab. The Web Vitals extension in Chrome logs every interaction and its INP value while I click through a product page, and the Performance panel in Chrome DevTools splits an interaction into its three phases: input delay (the browser was busy when you clicked), processing time (your event handlers ran) and presentation delay (the browser had to repaint). Which phase dominates tells me where to look. Lighthouse and Screaming Frog report Total Blocking Time and Time to Interactive; those are lab proxies, not the same metric as interaction to next paint.
Common INP mistakes
Loading every widget on every page. Chat widgets, cookie banners, A/B testing scripts and a tag manager full of old pixels all compete for the main thread. When a customer taps a button while a third-party script is running, the input delay alone can push INP past 200 milliseconds.
Re-rendering the whole product grid on a filter change. Many theme and plugin filters rebuild hundreds of DOM nodes synchronously the moment someone ticks “maat 42”. On a mid-range Android phone that is one long task, and the page visibly hangs until it finishes.
Doing heavy work inside the click handler. Firing analytics events, recalculating prices and updating the mini cart all in the same handler blocks the repaint. The visual feedback should come first; the bookkeeping can wait a few milliseconds.
Trusting a lab score. A green Lighthouse run on a fast desktop says little about INP. Field data at the 75th percentile is the only number Google uses, and on most Dutch webshops the majority of that data comes from phones.
How I handle INP for clients
I begin with the Search Console report to see which URL groups fail, then profile two or three representative pages on a throttled mobile device. For each slow interaction I record the phase breakdown and the script responsible. The deliverable is a short prioritised list: which scripts to defer or remove, which long tasks to break up, where the DOM is bloated, and which handlers need their visual update moved ahead of the heavy work. Where a widget is only needed after the visitor acts on it, I recommend lazy-loading it on first interaction instead of on page load.
Implementation usually sits with the developer or theme vendor, so I write the fixes in terms they can act on and verify the result in field data four to six weeks later, because CrUX needs time to refresh. This work is part of my Core Web Vitals service and it connects directly to the broader technische SEO work on the same shop: a lighter JavaScript stack improves LCP and crawl efficiency as well as INP.
Veelgestelde vragen
What is a good INP score?
Google’s thresholds are 200 milliseconds or less for good, up to 500 milliseconds for needs improvement, and above 500 milliseconds for poor. The score is taken at the 75th percentile of real visits, so three out of four page views need to be under the limit. Aim comfortably below 200.
Is INP the same as Time to Interactive or Total Blocking Time?
No. TTI and TBT are lab metrics calculated during a simulated page load, without any real interaction. INP is measured from actual clicks, taps and key presses by real users throughout the visit. A high TBT often predicts a poor INP, but only field data confirms it.
Why does my shop fail INP when it loads quickly?
Loading speed and responsiveness are separate problems. A page can paint in two seconds and still freeze when someone opens a filter, because the JavaScript that runs on that interaction is heavy or the main thread is occupied by third-party scripts. Profile the slow interaction itself rather than the page load.
Does fixing INP improve rankings?
Slightly at most; page experience is a minor signal and the size of the effect varies by study. The business case is conversion: a shop that responds instantly to every tap sells more from the same traffic. Treat the Search Console status as a health check, not as the goal.