What is INP?

INP stands for Interaction to Next Paint. It measures how long it takes your site to visually respond after a visitor clicks a button, taps a link, or types into a form. Google made it an official Core Web Vital in March 2024, replacing a metric called First Input Delay, and it now factors into your search rankings.

The short version: if your site feels sluggish to interact with, INP is probably the metric that shows it. And if your INP score is poor, Google is using that as a signal that your site delivers a bad experience.

How INP Is Measured

INP looks at every interaction a visitor has with your page during their visit: every click, every tap, every keyboard input. For each one, it measures the time from the moment the interaction happens to the moment the browser paints the next visual update in response.

At the end of the session, INP takes the worst interaction (with a small allowance for outliers on pages with many interactions) and uses that as the score for the page. So a page might handle ninety-nine interactions perfectly, but if one of them causes a three-second delay, that’s what INP reports.

Google assesses your score at the 75th percentile across all real user visits to your page. That means 75% of your visitors need to experience good INP for the page to pass. It’s not about the average. A fast experience for most visitors doesn’t compensate for a terrible experience on slow devices or connections.

The thresholds are:

• Good: 200 milliseconds or under
• Needs improvement: 201 to 500 milliseconds
• Poor: over 500 milliseconds

200 milliseconds is about the threshold of human perception for responsiveness. Below it, interactions feel instant. Above it, there’s a noticeable lag. Above 500 milliseconds, the site feels broken to most users.

INP vs First Input Delay: What Changed

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. The reason for the switch is that FID was measuring the wrong thing.

FID only measured the delay before the browser started processing the first interaction. It didn’t measure how long the visual update took to appear. So a site could have a good FID score while still feeling slow and unresponsive in practice, because the browser started processing the click quickly but then took another 800 milliseconds to paint the result.

INP fixes this by measuring the full cycle: from the interaction to the visual response. It also covers the entire visit, not just the first interaction. A page that feels fine when it first loads but bogs down after a few minutes of use would have had a good FID and now correctly gets a poor INP.

The practical impact of the switch: many sites that were passing Core Web Vitals under FID are now failing under INP. Core Web Vitals pass rates dropped across the web in 2024 as a direct result of this change, and the industry has been working to catch up since.

What Causes a Poor INP Score

INP problems almost always come down to one thing: JavaScript blocking the browser’s main thread.

Browsers handle all of this on a single main thread: parsing JavaScript, responding to user interactions, and painting visual updates. If a piece of JavaScript is running when a user clicks something, the browser has to finish that task before it can process the interaction. The user is left waiting.

The gap between the interaction and the visual update breaks into three phases:

Input delay. The time between the user’s interaction and when the browser starts processing it. Long tasks running on the main thread cause this. If a JavaScript function is taking 400 milliseconds to run, any interaction during that window will be delayed by however long that task has left to run.

Processing time. How long the browser spends executing the event handlers attached to the interaction. An onClick handler that triggers a large re-render or a complex database lookup can add hundreds of milliseconds here.

Presentation delay. The time between processing completing and the browser actually painting the update on screen. This is usually the smallest component but can be inflated by complex layouts or large DOM trees that take time to update.

Common culprits in practice:

• Heavy third-party scripts: chat widgets, advertising scripts, analytics libraries, social embeds
• Page builders that generate large amounts of JavaScript
• WordPress plugins that load JavaScript on every page regardless of whether it’s needed
• Large JavaScript bundles that haven’t been code-split or lazily loaded
• Fonts and images that trigger layout shifts during loading
• Undersized server responses causing slow hydration on JavaScript-rendered sites

How INP Relates to Your Hosting

INP is mostly a frontend problem. Unlike TTFB or LCP, which are heavily influenced by your server’s speed, INP happens in the visitor’s browser after the page has loaded. Your hosting choice has less direct influence here than the quality of your JavaScript.

That said, hosting still matters indirectly. A slow server that delivers JavaScript files late delays when those scripts start executing, which pushes back the point where the page becomes interactive. Hosting that includes a good CDN delivers scripts from a server closer to the visitor, reducing network latency. And object caching and server-level optimisation reduce the processing time for server-side event handlers on dynamic pages.

The bigger lever is usually your WordPress theme, your plugins, and how your JavaScript is structured. That’s something you can control independently of your hosting choice.

How to Check Your INP Score

There are two types of data to look at: lab data and field data.

Lab data comes from tools like Google PageSpeed Insights and Chrome’s Lighthouse. These run a simulated page load in a controlled environment. They’re useful for diagnosing specific issues but don’t always reflect real-world performance because they simulate a single session in one environment.

Field data is what Google actually uses for rankings. It comes from the Chrome User Experience Report (CrUX), which aggregates real visit data from Chrome users. You can see your field data in Google Search Console under Core Web Vitals, or in PageSpeed Insights where it shows both lab and field scores side by side.

A site can have good lab INP and poor field INP if real users on slower devices or older Android phones are struggling with the JavaScript load. The 75th percentile threshold means the experience on those slower devices counts just as much as the experience on a fast desktop.

If you don’t have enough real user data yet (CrUX requires a minimum volume of visits before it shows your scores), PageSpeed Insights will show you lab data only. For a new or low-traffic site, that’s the best available signal even if it’s not what Google is measuring directly.

How to Improve INP

The improvements that move INP scores are generally more technical than the fixes for other Core Web Vitals, but there are steps at every level of technical ability.

Audit your plugins. On WordPress, this is the first thing to check. Plugins that load JavaScript on every page, regardless of whether the page uses the feature, contribute to main thread bloat. Deactivate plugins you don’t use. For plugins you do use, check whether they offer options to disable loading on pages where they’re not needed.

Defer non-critical JavaScript. Loading scripts with defer or async means they don’t block the page from becoming interactive. Most caching and optimisation plugins (WP Rocket, LiteSpeed Cache, W3 Total Cache) have settings for this. Be cautious: deferring some scripts can break functionality, so test after any change.

Break up long tasks. If your site has JavaScript functions that take more than 50 milliseconds to run, they’re blocking the main thread. Developers can use techniques like setTimeout, requestIdleCallback, or the Scheduler API to break these into smaller chunks that give the browser breathing room to handle interactions between them.

Reduce DOM size. Large, complex HTML structures take longer to update when interactions trigger changes. A page with five thousand DOM elements will paint updates more slowly than one with five hundred. Reducing nested elements and simplifying layouts helps.

Audit third-party scripts. Open Chrome DevTools, go to the Performance tab, and record a session while interacting with your page. Look at the main thread activity. Chat widgets, ad scripts, and analytics libraries from third parties are often responsible for long tasks that you have no control over other than removing them or loading them later in the page lifecycle.

Choose a lighter theme. Page builder themes (Divi, Elementor, some Avada configurations) tend to load significantly more JavaScript than lightweight themes. If INP is a chronic problem and your theme is a heavy page builder, the most impactful fix is often switching to a leaner theme.

Frequently Asked Questions

Does INP affect my Google rankings?
Yes. INP became a Core Web Vital and a page experience ranking signal in March 2024. Google uses field data (real user experience from Chrome) at the 75th percentile. If your INP is in the “needs improvement” or “poor” range for 25% or more of your visitors, it’s applying downward pressure on your rankings, particularly when other ranking factors are close between competing pages.

What’s the difference between INP and FID?
First Input Delay measured the delay before the browser started processing the first interaction on a page. INP measures the full time from any interaction to the next visual update, across all interactions during a visit. INP is a more complete and accurate measure of how responsive a page actually feels to use.

My PageSpeed Insights INP is good but Search Console shows poor. Why?
PageSpeed Insights lab data simulates a single visit in a controlled environment. Search Console shows field data aggregated from real Chrome users at the 75th percentile. If a significant portion of your real visitors are on slow devices or weak connections, field INP can be much worse than lab INP. Field data is what Google uses for rankings. Focus on that.

Can my hosting provider improve my INP score?
Indirectly. Faster script delivery via CDN, better server response times, and server-side performance optimisation can reduce some components of INP. But INP is primarily a browser-side metric driven by JavaScript execution. The main levers are your theme, plugins, and custom code. Switching to a faster host won’t fix a slow INP if heavy JavaScript is the root cause. See the guide on how to test your website speed for more on measuring performance end to end.

Is 200ms a realistic target for WordPress sites?
Yes, for well-configured sites. WordPress’s INP pass rate in CrUX field data sits around 86%, meaning most WordPress sites are already hitting the 200ms threshold. The problem sites tend to be those running heavy page builders, large numbers of third-party scripts, or poorly coded plugins that block the main thread. A clean WordPress install with a lightweight theme and minimal plugins will typically pass without specific optimisation.