Key Facts at a Glance
- Interaction to Next Paint, or INP, is a Core Web Vital that measures how responsive a page feels when people interact with it.
- Google's web.dev guidance defines a good INP as 200 milliseconds or less, needs improvement as above 200 and up to 500 milliseconds, and poor as above 500 milliseconds.
- INP replaced First Input Delay as a stable Core Web Vital in 2024, according to web.dev.
- INP looks at clicks, touchscreen taps and keyboard presses. Hovering, zooming and scrolling are not included.
- Google Search Console reports INP using real user data and separates results for mobile and desktop.
What Interaction to Next Paint Actually Measures
INP is about responsiveness. It measures how quickly a page reacts after a visitor clicks, taps or presses a key. That matters because a page can appear to load quickly but still feel sluggish when someone tries to open a menu, submit a form, choose a filter or interact with another control.
Google's web.dev guidance describes each interaction as having three parts: input delay, processing duration and presentation delay. Input delay is the time before the browser starts dealing with the interaction. Processing duration covers the work needed to handle it. Presentation delay is the time before the result is visibly painted to the screen.
In practical terms, INP helps expose the gap between "the page looks loaded" and "the page responds properly when I use it". For a business owner, that makes it a useful metric when customers rely on menus, forms, product filters, booking tools, account areas or other interactive features.
web.dev says INP normally reports the worst interaction observed on a page. On pages with many interactions, one highest interaction is ignored for every 50 interactions. The aim is to assess the page's overall responsiveness rather than focus only on its first interaction.
How INP Is Scored
Google's web.dev guidance sets three clear INP bands. The threshold is assessed at the 75th percentile of page loads recorded in field data, with mobile and desktop considered separately.
| Band | Value | What it means for the visitor |
|---|---|---|
| Good | 200 milliseconds or less | Interactions should generally feel responsive. |
| Needs improvement | Above 200 and up to 500 milliseconds | Some interactions may feel noticeably delayed. |
| Poor | Above 500 milliseconds | Interactions can feel slow or unresponsive. |
The 75th percentile matters because your score is not based on one perfect test from one device. It reflects real usage across a wider set of visits. Google Search Console Help explains that Group INP means 75 percent of page requests in that group were at or below the reported value over the last 28 days.
This is also why you should check mobile and desktop independently. A site can behave differently across device types, particularly when processing power, page complexity and JavaScript activity vary.
How to Check INP for Your Website
Start with Google Search Console if you want a site-level view. Google Search Console Help says its Core Web Vitals report groups URLs by status, by metric and by groups of similar pages. The report covers CLS, INP and LCP, and separates mobile from desktop using actual user data from the Chrome User Experience Report.
Search Console is useful for spotting patterns. If a group of similar pages has an INP problem, you can investigate whether those pages share the same template, scripts, widgets or CMS components.
For a single URL, Google points site owners to PageSpeed Insights and Chrome Lighthouse. web.dev also recommends using field data from the Chrome User Experience Report or a real user monitoring provider to find slow interactions before reproducing and diagnosing them in a lab environment.
A sensible workflow is to start with what real visitors are experiencing, then investigate the specific interaction and the work the browser is doing around it.
Diagnose and Fix INP in the Right Order
- Check field data first. Use Search Console for groups of pages and PageSpeed Insights, CrUX data or real user monitoring where you need more detail.
- Identify which interactions are slow. Look for actions such as opening navigation, using filters, clicking buttons, interacting with forms or triggering page controls.
- Reproduce the slow interaction in a controlled test. web.dev recommends testing interactions during page load as well, because that is often when the browser's main thread is busiest.
- Work out which part of the interaction is causing the delay: input delay, processing duration or presentation delay.
- Fix the underlying cause rather than hiding the symptom. Reduce unnecessary work, split up heavy tasks and prioritise the visual response the visitor is waiting for.
- Re-test the interaction and then check field data over time. Google Search Console Help says that after a fix, Start Tracking opens a 28-day monitoring window, and the issue counts as fixed if it does not appear during that window.
What Your Developer Should Fix First
Start with input delay. web.dev recommends reducing script evaluation during startup and breaking up long tasks. This is particularly relevant on sites with heavy JavaScript bundles, plugin-heavy CMS themes or several third-party tags such as chat widgets, ad pixels and A/B testing scripts.
Google's web.dev guidance on long tasks explains that the browser's main thread can process only one task at a time. Any task lasting longer than 50 milliseconds is classed as a long task. If the main thread is tied up when a visitor interacts, the browser may have to wait before it can respond.
Developers can break work into smaller pieces and yield control back to the main thread more often. web.dev identifies scheduler.yield() as a dedicated browser API for this purpose, with code after await scheduler.yield() continuing in a later task.
Next, reduce processing duration. web.dev recommends doing the visual update first and deferring non-critical work, yielding to the main thread often, and avoiding layout thrashing by batching DOM reads and writes. The practical goal is simple: show the visitor the result of their action before starting work that can wait.
Finally, look at presentation delay. web.dev recommends keeping the DOM size down and using the CSS content-visibility property to lazily render off-screen elements. Very large pages can make the browser do more work than necessary before it can present an update.
INP Checklist for Your Developer
You do not need to diagnose JavaScript scheduling yourself. Your job is to give your developer a clear brief, point them towards the affected pages and ask them to identify the slow interaction rather than simply chase a headline score.
- Check Search Console Core Web Vitals for mobile and desktop separately.
- Identify which page groups are marked Poor or Need improvement for INP.
- Use PageSpeed Insights for representative URLs from affected groups.
- Find the actual slow interaction before changing code.
- Reproduce that interaction during page load as well as after the page has settled.
- Check for heavy startup script evaluation and long main-thread tasks.
- Review third-party tags, heavy JavaScript bundles, plugin-heavy themes and unusually large pages.
- Break up long tasks and yield to the main thread where appropriate.
- Prioritise the visible update before non-critical processing.
- Avoid layout thrashing by batching DOM reads and writes.
- Reduce unnecessary DOM size and consider content-visibility for off-screen content.
- Re-test the interaction after changes and use Search Console tracking to monitor the issue.
If nobody on your team owns performance, Thind Global Services can pick this up as part of website maintenance or a wider SEO engagement, starting with the field data rather than guesswork.
Key Takeaway
The key point for a site owner is that INP is not just another technical score. It tells you whether real visitors are waiting too long after they try to do something. Start with field data, find the slow interaction, then ask your developer to reduce the specific browser work causing that delay.
Frequently Asked Questions
What Is a Good INP Score?
According to Google's web.dev guidance, a good INP is 200 milliseconds or less. Above 200 and up to 500 milliseconds needs improvement, while anything above 500 milliseconds is poor. The threshold is assessed at the 75th percentile of field page loads, with mobile and desktop considered separately.
Is INP a Google Ranking Factor?
INP is one of Google's Core Web Vitals and replaced First Input Delay as a stable Core Web Vital in 2024, according to web.dev. That makes it part of the Core Web Vitals framework, but improving INP should not be treated as a promise of ranking gains. The practical reason to improve it is that slow interactions can make a site feel unresponsive to visitors.
How Do I Check INP for My Website?
Start with the Core Web Vitals report in Google Search Console to see groups of affected URLs and compare mobile with desktop. Google Search Console Help points to PageSpeed Insights and Chrome Lighthouse for individual URLs, while web.dev recommends using CrUX or real user monitoring field data to find slow interactions before diagnosing them in the lab.
Why Is My INP Worse on Mobile?
Google assesses mobile and desktop separately, so different results are possible. If mobile INP is worse, your developer should investigate the actual slow interactions on mobile and test them during page load, when the main thread may be particularly busy. Heavy JavaScript, third-party scripts, plugin-heavy themes and very large pages are sensible areas to inspect.
Need help putting this into practice?
Talk to our Birmingham team — free consultation, no obligation, fixed quotes.
