INP (Interaction to Next Paint): What It Is and How to Fix It

If you have checked your Core Web Vitals recently and seen "INP" flagged, you are looking at the metric that now decides whether Google considers your site responsive. INP, or Interaction to Next Paint, replaced First Input Delay (FID) as an official Core Web Vital on March 12, 2024, and it is a much stricter test.

This guide explains what INP measures, what counts as a good score, and the practical steps that actually move the number down.

What Is INP?

INP measures the latency of interactions on your page — the delay between a user doing something (clicking a button, tapping a menu, typing in a field) and the browser visually responding by painting the next frame.

Unlike its predecessor, INP does not just measure the first interaction. It observes every interaction a visitor makes during their visit and reports a value close to the worst one. That is what makes it harder to pass: one sluggish menu or one slow form field can drag your whole score down.

An interaction's latency is made up of three parts:

1. Input delay — time spent waiting because the main thread is busy with other work.
2. Processing time — time spent running the event handlers (your JavaScript).
3. Presentation delay — time spent calculating layout and painting the next frame.

INP is the sum of all three, measured at the 75th percentile of all interactions across real visits.

INP Thresholds: What Counts as Good

Google groups INP scores into three bands. To pass, at least 75% of visits must fall in the "Good" range.

INP vs FID: Why the Change?

FID only measured input delay on the first interaction — and only the delay, not how long your code took to actually respond. A page could score a great FID while still feeling slow on every click after the first.

INP fixes both gaps. It measures the full interaction (delay + processing + paint) and it covers the entire session. In practice, many sites that comfortably passed FID now fail INP, which is exactly why it caught so many teams off guard in 2024.

How to Measure Your INP

There are two kinds of data, and they do not always agree:

• Field data (CrUX) — real measurements from real Chrome users. This is what Google uses for ranking. Find it in Google Search Console's Core Web Vitals report or in PageSpeed Insights.
• Lab data — a simulated test in tools like Lighthouse. Useful for debugging, but Lighthouse cannot fully reproduce INP because it depends on real user interactions.

The most practical workflow: use the Chrome DevTools Performance panel, record yourself clicking around the page, and look for long tasks (highlighted in red) that block the main thread during interactions.

How to Fix a Slow INP

Almost every INP problem comes back to one thing: the main thread is too busy to respond. Here are the highest-impact fixes, roughly in order.

1. Break up long JavaScript tasks

Any task that runs longer than 50 ms blocks the browser from responding. Split heavy work into smaller chunks and yield back to the main thread with setTimeout, requestIdleCallback, or the newer scheduler.yield().

// Instead of one long blocking loop:
function processAll(items) {
  items.forEach(doExpensiveWork) // blocks the main thread
}

// Yield between chunks so the page stays responsive:
async function processAll(items) {
  for (const item of items) {
    doExpensiveWork(item)
    await scheduler.yield() // let pending interactions run
  }
}

2. Reduce JavaScript you ship

Less code on the main thread means less to block it. Code-split, lazy-load below-the-fold scripts, and remove unused third-party tags. Heavy analytics, chat widgets, and A/B-testing scripts are frequent culprits.

3. Defer non-urgent work

When a user clicks, paint the visual response first, then do the heavy lifting. Show the menu open immediately; fetch its contents a frame later. The user perceives the page as instant even if work continues in the background.

4. Avoid large, complex DOM updates

A huge DOM makes every layout and paint slower. Keep your node count reasonable, avoid layout thrashing (reading and writing styles in a loop), and use CSS content-visibility for off-screen sections.

5. Move heavy computation off the main thread

For genuinely expensive work — parsing, image processing, large data transforms — use a Web Worker so the main thread stays free to handle clicks and taps.

INP and SEO: Does It Actually Affect Rankings?

Yes — INP is one of the three Core Web Vitals Google uses as a page-experience signal, alongside LCP and CLS. It is rarely the deciding factor on its own, but on competitive queries where content quality is similar, a responsive page has the edge. Just as important, a snappy page keeps visitors from bouncing, which indirectly helps your overall SEO.

Frequently Asked Questions

What is a good INP score?

A good INP score is 200 milliseconds or less at the 75th percentile of real user interactions. Between 200 and 500 ms needs improvement, and above 500 ms is poor.

When did INP replace FID?

INP officially became a Core Web Vital on March 12, 2024, fully replacing First Input Delay (FID) as Google's responsiveness metric.

Why is my INP worse than my FID was?

Because INP is stricter. FID only measured the input delay of your first interaction, while INP measures the full latency (delay + processing + paint) of every interaction during a visit. Sites that passed FID often fail INP.

Can I measure INP in Lighthouse?

Not fully. Lighthouse provides lab data, but INP depends on real user interactions that a simulated test cannot reproduce. Use field data from Search Console or PageSpeed Insights for the score that matters, and Chrome DevTools' Performance panel for debugging.

What is the most common cause of a poor INP?

Long JavaScript tasks that block the main thread — usually heavy first-party scripts or third-party tags (analytics, chat, ad, and testing scripts). Breaking these up or deferring them is the most reliable fix.

Conclusion

INP is the metric that tells Google — and your visitors — whether your site feels responsive. Aim for the 200 ms "Good" threshold, measure with real field data, and focus your effort on the single longest task blocking your main thread.

Next step: read our full Core Web Vitals guide to see how INP fits alongside LCP and CLS, and how to pass all three.