INP (Interaction to Next Paint) – Google's interactivity metric in Core Web Vitals

Definition

INP (Interaction to Next Paint) is Google's interactivity metric in Core Web Vitals. It measures the time from a user interacting with a page – clicking, tapping or typing – until the browser shows a visible response. INP replaced FID (First Input Delay) on 12 March 2024.

What does INP measure – and why was FID replaced?

INP measures the response time of the whole chain from user interaction to the next "paint" – that is, when the browser actually updates the screen in response to what the user did. It covers three separate phases: input delay (the delay before the event handler starts), processing time (the time to run the JavaScript code) and presentation delay (the time for the browser to render the visual response). The reported INP value is the slowest single interaction during the whole page visit, excluding extreme outliers.

This is the decisive difference from its predecessor, FID (First Input Delay). FID only measured the delay on the user's first interaction on the page. That turned out to be an insufficient metric – a page can have a fast first response but be sluggish on every later click. As a result, almost every website passed FID, so the metric was useless for telling websites apart. Interaction to Next Paint instead captures the full range of interactions during a visit, which gives a more realistic picture of the actual user experience.

On 12 March 2024, INP officially replaced FID as a Core Web Vital, as confirmed by Google's web.dev blog. According to the HTTP Archive 2025 Web Almanac, 77% of all mobile pages now achieve a good INP value. Interestingly, though, only 53% of the 1,000 most visited websites pass INP – larger websites with more scripts and complex DOM structures find it harder to perform well.

What is a good INP value?

Google uses three thresholds:

• Good: under 200 milliseconds
• Needs improvement: 200–500 milliseconds
• Poor: over 500 milliseconds

Google evaluates INP at the 75th percentile of page loads – that is, 75% of the measured interactions need to be under 200 ms for the page to be classed as "good". The data comes from real users via the Chrome User Experience Report (CrUX), not from simulations.

Why is INP important for SEO?

INP is a direct ranking factor via Google's Page Experience signals. A page with slow interactivity – where buttons, menus and forms feel sluggish – gives a poorer user experience, a higher bounce rate and lower engagement. That affects ranking potential not only directly via the Core Web Vitals signal, but also indirectly via behavioural signals.

For AEO there is another angle: ClickRank's analysis shows that pages with poor performance may be given lower priority as sources in AI-generated answers, even when the content itself is relevant. A user experience that feels sluggish or unstable signals to AI systems that the source is of lower quality.

What affects INP – and how do you improve it?

INP problems are almost always caused by the browser's main thread being blocked. The main thread handles everything: JavaScript execution, rendering and responding to user interactions. When it is busy with a large task, it cannot respond to clicks or key presses, which results in a high INP value.

The most common causes and fixes:

• Third-party scripts – ad networks, chat widgets and analytics tools are the most common culprits. Each script you load can add 50–100 ms to the interaction time. With ten or more third-party scripts, that is enough to exceed the 500 ms limit. The fix: identify and remove unnecessary scripts, or defer non-critical scripts until after the page is interactive.
• Long JavaScript tasks – the culprit is often a single JavaScript function that blocks the main thread for hundreds of milliseconds. Google's web.dev guide recommends breaking long tasks into smaller parts and "yielding" to the main thread between them, so the browser can handle user interactions as they come in.
• Too many plugins (especially WordPress) – every plugin adds JavaScript that has to be loaded and run. A WordPress installation with 15+ plugins is a classic recipe for poor INP, especially on mobile, where processing power is lower.
• Large DOM trees – pages with many DOM nodes take longer to render when an interaction happens. The presentation delay phase of INP grows in proportion to DOM complexity.

How do you measure INP?

The best way to measure INP is with real user data (field data), not simulations. Tools:

• Google PageSpeed Insights – shows real CrUX data for INP in the "Field Data" section.
• Google Search Console – the Core Web Vitals report shows INP status per URL group.
• Chrome DevTools – the Performance panel shows individual interactions and where the time goes across the three phases.
• web-vitals.js – Google's own JavaScript library for collecting INP data from real users.

Worth knowing: real INP data can take up to 28 days to show up in the CrUX dataset, so changes do not appear in the reports straight away.