By PDS Team
Interaction to Next Paint (INP) is a Core Web Vitals metric that measures how quickly a page responds when someone taps, clicks or types. On 12 March 2024, Google will make INP an official Core Web Vital and retire First Input Delay (FID). If your pages feel slow to react, now is the time to measure and fix them.
This guide explains what INP measures, how it differs from FID, the score you should aim for, and the fixes that usually make the biggest difference on business websites.
What is Interaction to Next Paint (INP)?
INP measures the delay between a user’s interaction and the moment the browser shows the visual result of that interaction.
When someone clicks “Add to cart”, opens a menu or types in a form, the browser has to run your JavaScript, work out the layout and then paint the update on screen. INP observes these interactions throughout a person’s visit and reports a value close to the slowest one. A low INP means the page feels responsive; a high INP means people tap and wait.
INP counts clicks, taps and key presses. Scrolling and hovering are not counted.
How is INP different from First Input Delay?
FID only measured the delay before the browser started handling the first interaction, while INP measures the full response time of all interactions on the page.
| First Input Delay (FID) | Interaction to Next Paint (INP) | |
|---|---|---|
| Which interactions | Only the first one | All clicks, taps and key presses during the visit |
| What is timed | Input delay only | Input delay + processing time + time to paint the next frame |
| Status | Core Web Vital until 12 March 2024 | Becomes a Core Web Vital on 12 March 2024 |
| Good threshold | 100 ms or less | 200 ms or less |
Many sites passed FID easily because it ignored the processing work after the first tap. INP is stricter, so a site with a good FID score can still have a poor INP score.
What is a good INP score?
A good INP is 200 milliseconds or less, measured at the 75th percentile of page loads.
- Good: 200 ms or less
- Needs improvement: more than 200 ms and up to 500 ms
- Poor: more than 500 ms
The 75th percentile means at least three out of four visits should meet the target, on mobile and desktop separately. Mobile results are usually worse because phones have less processing power, so check them first.
How do you measure INP on your site?
Use field data from real visitors first, then lab tools to find the interactions causing the problem.
Field data (what real users experience)
- PageSpeed Insights: enter a URL to see INP from the Chrome User Experience Report (CrUX), if your page or site has enough traffic.
- Search Console: the Core Web Vitals report groups similar URLs. Google has said the report will switch from FID to INP when INP becomes a Core Web Vital.
- Your own monitoring: the open-source web-vitals JavaScript library can send INP values to your analytics.
Lab data (finding the cause)
Open Chrome DevTools, go to the Performance panel, record while you click the slow elements, and look for long tasks on the main thread. Lighthouse cannot measure INP directly because it does not interact with the page, but its Total Blocking Time result is a useful hint: high blocking time often means poor responsiveness.
What usually causes a poor INP score?
Most INP problems come from too much JavaScript running on the main thread when the user interacts.
- Heavy third-party scripts: chat widgets, multiple analytics tags, ad scripts and social embeds.
- Large page builders and plugins that load scripts on every page, even where they are not used.
- Event handlers that do a lot of work before updating the screen, such as filtering a long product list.
- Very large pages with thousands of HTML elements, which make every layout update slower.
- Long tasks during page load, so the browser is busy when a visitor taps early.
How can you improve INP?
Reduce and break up JavaScript work, so the browser can respond to the user and paint quickly.
- Remove what you do not need. Audit plugins and third-party tags. Every script you remove is work the browser no longer has to do.
- Load scripts only where used. A booking widget needed on one page should not load on the whole site.
- Break up long tasks. web.dev’s guidance recommends splitting long JavaScript tasks and yielding to the main thread so the browser can handle input in between.
- Show feedback first. Update the screen immediately (for example, show a loading state), then do the heavier work.
- Keep the page smaller. Reduce DOM size by simplifying layouts and avoiding hidden duplicate content for mobile and desktop.
- Delay non-essential scripts. Chat and marketing tags can often load after the page becomes interactive.
Hosting matters for loading speed, but INP is mostly about what happens in the browser. A fast server will not fix a page that runs too much JavaScript on every tap. If you need help diagnosing slow templates, our technical SEO services include Core Web Vitals audits and fixes, and our web hosting services cover the server side.
Will INP affect your Google rankings?
INP will be part of the page experience signals Google uses, but good content still matters far more than a perfect score.
Google has said that Core Web Vitals are used by its ranking systems and that it recommends site owners achieve good Core Web Vitals. It has also said that great page experience does not override relevant, helpful content. Think of INP as a user experience improvement first: a page that responds instantly is easier to use, and that helps enquiries and sales whatever happens to rankings.
Technical signals change over time. For an earlier example of a Google change site owners needed to prepare for, see our post on the new robots tag by Google.
Interaction to Next Paint FAQs
When does INP replace FID?
Google has announced that INP will replace First Input Delay as a Core Web Vital on 12 March 2024. From that date, FID will be deprecated and tools such as Search Console’s Core Web Vitals report are expected to show INP instead. You can already measure INP today in PageSpeed Insights and Chrome DevTools.
Why does my site pass FID but fail INP?
FID only measures the waiting time before the browser starts handling the first interaction. INP also includes the time your code takes to run and the time to paint the result, across every interaction. Pages with heavy JavaScript can start responding quickly but still take a long time to update the screen.
Can WordPress sites get a good INP score?
Yes. Many WordPress sites score well when they use a lightweight theme, a small number of well-built plugins and only the third-party scripts they really need. Problems usually come from stacking many plugins, sliders, popups and tracking tags that all run JavaScript on every page.
Does INP measure scrolling?
No. INP measures clicks, taps and keyboard presses. Scrolling and hovering are not included. However, heavy scripts that run while someone scrolls can block the main thread and slow down the next tap, so scroll-linked effects can still affect INP indirectly.
Why does PageSpeed Insights show no INP data?
Field data in PageSpeed Insights comes from the Chrome User Experience Report, which needs enough real Chrome visits to a page or site. Low-traffic pages may show no data. In that case, test the main interactions yourself in Chrome DevTools and use Total Blocking Time as a rough guide.
Is INP a mobile or desktop metric?
Both. Google reports INP separately for mobile and desktop. Mobile scores are often worse because phones have slower processors, so a page that feels fine on a laptop can be slow on a budget smartphone. Since most Indian users browse on phones, check mobile results first.
Need help getting ready for INP?
We can measure your INP, find the scripts slowing your pages down and fix them before March. See our technical SEO services or contact our team in Noida to book a Core Web Vitals review.
