If Search Console says your pages have an “INP issue”, or PageSpeed Insights shows a red INP score, the problem is simple to describe. Your page is slow to react when people click, tap or type. Interaction to Next Paint (INP) measures that delay, and you fix it by giving the browser less JavaScript work to do at the moment someone interacts.
In this guide I explain what INP measures in plain words, what a good score is, how to find the slow interactions on your site, and the fixes that work most often. I also cover what you can do if you run WordPress or another CMS and don’t write code yourself.
What Is Interaction to Next Paint?
Interaction to Next Paint is one of Google’s three Core Web Vitals. These are metrics that measure real user experience: how fast the main content loads (LCP), how stable the layout is (CLS) and how quickly the page responds to input (INP).
INP looks at the time between a user action and the next time the screen updates. The “paint” is the moment the browser draws the new frame, so the user sees that something happened. That could be a menu opening, a button changing colour or an item appearing in a cart.
Here is what INP counts and what it ignores:
- Counted: mouse clicks, taps on a touchscreen, and key presses on a physical or on-screen keyboard.
- Not counted: hovering, scrolling and zooming on their own.
- Whole visit: INP watches every interaction while the page is open, not only the first one.
At the end of the visit, the page’s INP is its slowest interaction. There is one small adjustment. For every 50 interactions, the single slowest one is ignored, so one odd outlier on a busy page does not decide the score. Most pages get fewer than 50 interactions, so in practice INP is usually the worst one.
Why Google Replaced FID With INP
INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. FID only measured the first interaction on a page, and only the wait before the browser started handling it. It ignored everything after that.
That made FID easy to pass. Almost every site had a good FID score, even when menus and filters felt slow. INP is stricter because it covers every interaction and the full delay until the screen updates. This is why many sites that looked fine under FID suddenly showed problems when INP arrived.
What Is a Good INP Score?
Google uses these thresholds for INP:
- Good: 200 milliseconds or less.
- Needs improvement: more than 200 ms and up to 500 ms.
- Poor: more than 500 ms.
The score is measured at the 75th percentile of real page visits, and mobile and desktop are judged separately. In plain words, at least 3 out of 4 visits need an INP of 200 ms or less for the page to pass.
For a sense of scale, 200 ms is about one fifth of a second. Below that, a page feels instant. Above half a second, people start tapping again because they think the first tap did not work.
In my experience, mobile is almost always where INP fails. Phones have slower processors than laptops, so the same JavaScript takes much longer to run. When I review INP, I always look at the mobile data first.
Is INP a Ranking Factor?
Yes, but a small one. Core Web Vitals are part of the signals Google’s ranking systems use for page experience. Google is also clear that great, relevant content matters more. A page with a poor INP can still rank well if it answers the search better than anything else.
My honest view is this. Don’t expect a jump in rankings just from fixing INP. Fix it because a slow page annoys people, and annoyed people leave, buy less and fill in fewer forms. The SEO benefit is a bonus on top of that.
The Three Parts of Every Interaction
To fix INP, it helps to know where the time goes. Every interaction has three parts, and each one has its own common causes.
| Phase | What happens | Common cause of delay |
|---|---|---|
| Input delay | The time before your code starts responding to the click or tap | The browser is busy with other scripts, often while the page is still loading |
| Processing time | The time your event handlers (the code that runs on a click) take to finish | Too much work inside the click code, such as tracking calls or big updates |
| Presentation delay | The time the browser needs to work out the layout and draw the new frame | A very large page (DOM) or big changes to the page all at once |
All three phases happen on the browser’s main thread. Think of the main thread as a single checkout lane. It handles your scripts, layout and drawing one job at a time. If a big job is in the lane when the user clicks, the click has to wait.
Any job that runs longer than 50 ms is called a long task. Long tasks are the main cause of poor INP. Most of the fixes below come down to making those tasks shorter or moving them out of the way.
How to Measure Interaction to Next Paint
INP comes from real users, so the most reliable data is field data (measurements from real visitors’ browsers). Lab tools help you find and test fixes, but they can’t give you the real score.
Search Console Core Web Vitals Report
Open Search Console and go to Experience > Core Web Vitals. The report splits your URLs into Good, Needs improvement and Poor, for mobile and desktop. Click an issue such as “INP issue: longer than 200ms (mobile)” to see example URLs.
Search Console groups similar pages together. If one product page is slow, all product pages using the same template usually are too. This is why I start here: it tells me which template to fix, not only which URL.
PageSpeed Insights
PageSpeed Insights shows field data from the Chrome UX Report (CrUX) at the top, for the URL and for the whole site (origin). This data covers the last 28 days of real Chrome users.
The Lighthouse section below it is a lab test. Lighthouse loads the page but does not click anything, so it can’t report INP. Look at Total Blocking Time (TBT) there instead. A high TBT means long tasks are blocking the main thread, which often goes with a poor INP.
If you see “no data” at the top, your page doesn’t get enough Chrome traffic for CrUX. That doesn’t mean INP is fine. It means you need to test it yourself.
Chrome DevTools and the Web Vitals Library
Open the page in Chrome, press F12 and go to the Performance panel. Recent versions of Chrome show live Core Web Vitals there, including INP, as you click around the page. You can also record a trace to see exactly which scripts ran during a slow interaction.
Turn on CPU throttling (for example a 4x slowdown) before testing. Your computer is much faster than the average phone, so without throttling you will miss problems your visitors feel.
For ongoing field data, developers can add Google’s open source web-vitals JavaScript library to the site. Its attribution build reports which element was clicked and which phase was slow, and you can send that data to GA4 or another analytics tool. Real user monitoring (RUM) tools do the same job with less setup.
One thing to keep in mind: INP is measured in Chrome and other Chromium-based browsers like Edge. Safari and Firefox don’t report it yet, so your INP data reflects Chrome users only.
How to Find the Slow Interactions
Once you know a template has a problem, you need to find which interaction causes it. Here is the process I follow.
- Pick one page from the failing group in Search Console, preferably one with real traffic.
- List the things people actually click on that page: menu, search box, filters, add to cart, accordions, tabs, cookie banner buttons, form fields.
- Open DevTools, turn on CPU throttling and watch the live INP value in the Performance panel.
- Click each element, including while the page is still loading. Interactions during loading are often the slowest because scripts are still running.
- Record a trace for the slowest one. Look at the long tasks around the click and see which script files they come from.
- Note the phase. Was the time spent waiting (input delay), running code (processing) or drawing (presentation)? This tells you which fix to try.
On most sites I look at, the cookie consent banner, the mobile menu and the add to cart button come up again and again. They are the first things people touch, and they often load heavy scripts.
How to Fix INP: The Fixes That Work Most Often
The right fix depends on the phase that is slow. These are the changes I’d look at first, in roughly this order.
Cut and Delay Third-Party Scripts
Chat widgets, heatmap tools, ad scripts, A/B testing tools and social embeds all run on the same main thread as your own code. Each one adds long tasks, especially during page load.
- Remove any tag nobody uses anymore. Old tracking pixels pile up for years.
- Load non-essential tools after the page has finished loading, or only when needed. A chat widget can load when someone clicks the chat button.
- Check your tag manager setup. Many tags fire on every page when they only need one or two. My guide to Google Tag Manager for SEO explains how triggers work so you can limit where tags run.
In my experience, this is the fastest win for most business sites. It often needs no developer, just a careful review of what is installed.
Break Up Long Tasks
If one script runs for 300 ms, nothing else can happen during that time. The fix is to split the work into smaller pieces and let the browser handle user input in between. Developers call this “yielding to the main thread”.
The simplest way is to wrap less urgent work in a setTimeout call. Chrome 129 also added scheduler.yield(), which is made for this job. A safe pattern uses it where it exists and falls back to setTimeout elsewhere:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showSpinner(); // urgent: the user sees a response
await yieldToMain(); // let the browser paint
saveToServer(); // less urgent work runs after
sendAnalyticsEvent();
});Do Less Work Inside Click Handlers
A click handler should do only what is needed to update the screen. Everything else can wait for the next task.
- Show feedback first. Open the menu, show a spinner or update the button before running anything else.
- Move tracking calls later. Analytics events don’t need to run before the paint.
- Avoid layout thrashing. This happens when code changes styles and then reads sizes or positions straight away, in a loop. The browser has to recalculate the layout each time. Read all values first, then make all changes.
- Debounce typing. For search boxes and live filters, wait until the user pauses for a moment before running the search, rather than on every key press.
Reduce Rendering Work
When presentation delay is the problem, the browser is struggling to draw the update. Usually the page is simply too big, or one click changes too much of it at once.
- Keep the DOM (the tree of HTML elements on the page) smaller. Mega menus with hundreds of links and pages that load every product at once are common causes.
- Use the CSS property
content-visibility: autoon long sections below the fold, so the browser skips drawing them until they are needed. - Avoid building large chunks of HTML with JavaScript in one go. Update only the part of the page that changed.
Make Page Load Lighter
Input delay is often worst while the page is loading, because the browser is busy parsing and running scripts. Less JavaScript at load time means fewer clicks get stuck waiting.
- Use
deferorasyncon scripts that don’t need to run right away. - Remove unused JavaScript. The Coverage tab in DevTools shows how much of each file actually runs.
- Don’t show buttons that look clickable before their script has loaded, or show a clear loading state on them.
Fixing INP on WordPress and Other CMS Sites
Many readers of this site don’t write code, so here is where I would start on a WordPress, Shopify or similar site.
- Audit your plugins and apps. Every plugin that adds front-end scripts adds main-thread work. Deactivate the ones you don’t need and test again.
- Check your page builder and theme. Heavy builders and multi-purpose themes often add a lot of JavaScript and very large DOMs. I usually see INP problems get worse after a theme change.
- Be careful with “delay JavaScript” settings. Many speed plugins offer this. It can help page load, but it can also make the first click slow, because the scripts only start loading when the user interacts. Test the first click after turning it on.
- Look at sliders, popups and live chat. These are frequent offenders and easy to remove or replace with lighter options.
If you hire a developer, give them the Search Console example URLs, the slow element you found and the phase that was slow. That saves hours of guessing.
How to Confirm Your Fixes Worked
After you make changes, test the same interactions in DevTools with the same throttling. You should see the live INP drop right away.
Field data takes longer. CrUX uses a rolling 28-day window, so PageSpeed Insights and Search Console need a few weeks to reflect the change. In Search Console you can click Validate fix on the INP issue. Google then watches the affected URLs for 28 days before marking it as passed or failed.
I write down the date of each change, and I add it as a GA4 annotation so it shows up in my reports. When the field data moves weeks later, I can tell which change caused it.
Common INP Mistakes
- Trusting the Lighthouse score. A 100 performance score in the lab says nothing direct about INP, because Lighthouse doesn’t click anything.
- Testing only on a fast laptop. Always use CPU throttling or a mid-range phone.
- Testing only after the page has loaded. Real users click while it’s still loading.
- Fixing one URL instead of the template. Search Console groups pages for a reason. Fix the shared component.
- Adding more plugins to fix speed. Another plugin is more code. Removing things usually helps more than adding things.
Conclusion
Interaction to Next Paint measures how quickly your page responds when someone clicks, taps or types. Aim for 200 ms or less on mobile, find the slow interactions with Search Console and DevTools, and fix them by cutting scripts, breaking up long tasks and keeping click code light. Google’s own INP documentation on web.dev is the best reference if your developer wants the technical detail.
Your next step: open the Core Web Vitals report in Search Console and check the mobile INP issues today. If you are working through a wider list of site fixes, my SEO checklist for 2025 shows where Core Web Vitals fit among everything else.
