Interaction to Next Paint (INP) Explained: Subparts & 200ms

Quick answer: Interaction to Next Paint (INP) is the Core Web Vital that measures responsiveness: the time from a user's click, tap or key press to the next frame the browser paints. Each interaction has three subparts: input delay, processing duration and presentation delay. A good INP is 200 ms or less at the 75th percentile of page visits. INP replaced First Input Delay (FID) on March 12, 2024.

You opened PageSpeed Insights or Search Console and found INP where FID used to be. This guide explains what INP measures, how its subparts add up, why the threshold is 200 ms, and how to find which subpart is slowing your page down.

If you already know INP is failing and want fixes, go straight to our guide on how to fix INP under 200 ms.

What Is Interaction to Next Paint (INP)?

INP measures how long a page takes to show a visual response after a user interacts with it. "Next paint" means the next frame the browser draws after the interaction, not the end of whatever work the interaction starts. A button that turns grey immediately and submits a form two seconds later has a good INP; a button that freezes the page for 600 ms before anything changes has a poor one.

Unlike LCP and CLS, INP isn't a page-load metric. It observes every click, tap and key press during a visit and reports one value for the page:

• With fewer than 50 interactions, INP is the slowest interaction.
• With 50 or more, the single slowest interaction per 50 is ignored, so one outlier on a long session doesn't define the score.

Scrolling and hovering aren't interactions for INP. Clicks, taps and key presses are.

INP Subparts: Input Delay, Processing Duration, Presentation Delay

Every interaction's latency is the sum of three subparts. Knowing which one dominates is the whole diagnosis, because each has a different fix.

In the Event Timing API, the subparts fall out of four timestamps on each PerformanceEventTiming entry:

input delay          = processingStart - startTime
processing duration  = processingEnd   - processingStart
presentation delay   = (startTime + duration) - processingEnd
interaction latency  = duration            (rounded to 8 ms)

💡 Rule of thumb: If input delay is the biggest subpart, the problem isn't your click handler. Something else was hogging the main thread when the user clicked. Look at long tasks first.

INP Thresholds: What Counts as Good

Google evaluates INP at the 75th percentile of page visits, split by mobile and desktop (web.dev: INP):

Two consequences surprise most teams:

1. The 75th percentile is mostly mid-range phones. A page that responds in 80 ms on a developer laptop can be at 350 ms on a mid-range Android device with a 4× slower CPU.
2. One slow component can fail the page. If the slowest interaction is opening a mega-menu, every visit that opens it carries that latency into the INP calculation.

What Our Lab Data Shows About Input Delay Risk

INP needs real interactions, so it can't be measured by loading a page. What a page load can show is how busy the main thread is, which drives input delay. We loaded 219 randomly sampled homepages (Tranco ranks 1,001–50,000) under Lighthouse-style mobile throttling (4× CPU, 150 ms RTT, 1.6 Mbps) and measured Total Blocking Time (TBT): the main-thread time after first paint spent in long tasks beyond 50 ms each.

The median homepage blocked the main thread for 1.62 seconds after first paint (201 sites measured; 18 timed out or failed). Lab TBT on a throttled profile runs higher than what fast devices see, so read it as relative risk rather than a field number.

A page with seconds of blocking time during load isn't guaranteed a poor INP, but any tap that lands during those long tasks waits for them to finish. That wait is the input delay subpart.

Why Google Replaced FID With INP

First Input Delay measured only the input delay of the first interaction. It ignored processing and presentation, and ignored every interaction after the first.

The higher threshold isn't leniency. INP measures the whole pipeline up to the paint, so it's naturally longer than input delay alone. Google announced the switch in INP becomes a Core Web Vital on March 12.

How to Measure INP and Its Subparts

Field data (what Google uses)

Field INP comes from real Chrome users through the Chrome UX Report (CrUX) and shows up in Search Console's Core Web Vitals report and PageSpeed Insights. It needs enough traffic; low-traffic pages may show "no data".

Measure subparts on your own pages

Paste this into the DevTools console, then click around the page. It logs every interaction over 40 ms with its three subparts:

// Logs INP subparts for each slow interaction (Chrome 96+).
// Usage: paste in DevTools console, interact with the page, read the table.
const rows = [];
new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    if (!e.interactionId || e.duration < 40) continue;
    const inputDelay = e.processingStart - e.startTime;
    const processing = e.processingEnd - e.processingStart;
    const presentation = e.startTime + e.duration - e.processingEnd;
    rows.push({
      type: e.name,
      target: e.target?.tagName + (e.target?.id ? '#' + e.target.id : ''),
      total: Math.round(e.duration),
      inputDelay: Math.round(inputDelay),
      processing: Math.round(processing),
      presentation: Math.round(presentation),
    });
    console.table(rows);
  }
}).observe({ type: 'event', durationThreshold: 16, buffered: true });

Collect subparts from real users

For field subparts, use the attribution build of Google's web-vitals library and send the breakdown to your analytics:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  navigator.sendBeacon('/vitals', JSON.stringify({
    metric: 'INP', value, rating,
    target: attribution.interactionTarget,
    type: attribution.interactionType,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
  }));
});

Group the results by target and you'll usually find one or two components responsible for most poor interactions.

What Causes Poor INP

• Long tasks during and after load. Hydration, bundle evaluation and tag managers keep the main thread busy, inflating input delay. See optimizing long tasks.
• Heavy event handlers. Re-rendering a large component tree on every keystroke inflates processing duration.
• Third-party scripts. Chat widgets, A/B testing and ad scripts share your main thread. Our list of the worst INP offenders in web apps covers the usual suspects.
• Large DOMs. Every style and layout recalculation after an update costs more, inflating presentation delay.
• Forced synchronous layout. Reading offsetHeight after writing styles in the same handler forces layout mid-handler.

How BugViso Flags INP Risk

Lab tools can't produce a true INP without user interactions, and BugViso is honest about that: its Core Web Vitals pass records INP only when an interaction happens, so on an unattended scan it's usually empty.

What a BugViso scan does measure is the cause behind most input delay. The performance engine captures main-thread Long Tasks (over 50 ms) with PerformanceObserver, computes Total Blocking Time, and names the script responsible for the worst task. It repeats the load under Slow 3G and Fast 3G with CPU throttling, so you see how blocking time grows on slower devices. The remediation playbook then points at the script to defer or split.

The checks behind this are covered on the website audit tool for developers page.

Common Mistakes When Reading INP

• Treating INP as a load metric. A page with a fast LCP can still have a poor INP.
• Optimising the wrong subpart. Shaving 30 ms off a handler won't help if input delay is 400 ms.
• Ignoring third-party code. It runs on your main thread and counts fully against your INP.
• Testing on a fast laptop only. Use DevTools CPU throttling (4× or 6×) to approximate the 75th-percentile device.
• Expecting instant Search Console changes. CrUX is a rolling 28-day window, so fixes take weeks to show.

FAQ

What is a good INP score?

200 ms or less at the 75th percentile of page visits. 200–500 ms needs improvement; over 500 ms is poor.

What are the INP subparts?

Input delay (waiting for the main thread), processing duration (your event handlers running) and presentation delay (rendering the next frame). Their sum is the interaction's latency.

What does INP stand for?

Interaction to Next Paint. It measures the delay between an interaction and the next frame painted on screen.

Is INP the same as FID?

No. FID measured only the input delay of the first interaction. INP measures all three subparts across every interaction in the visit.

Does INP affect Google rankings?

INP is one of the three Core Web Vitals, which Google's Core Web Vitals documentation says are used by its ranking systems as part of page experience. Relevance still matters far more.

Why does Search Console show no INP data for my page?

CrUX only reports pages and origins with enough real Chrome traffic. Until then, use the console snippet above or the web-vitals attribution build to collect your own.

The Takeaway

INP is three numbers wearing one name: find which subpart dominates your slowest interaction and the fix becomes obvious, and a BugViso performance audit shows the long tasks behind most input delay.