INP optimization is the process of reducing how long your page takes to visually respond after a user clicks, taps, or presses a key. Interaction to Next Paint measures that latency across a whole visit and reports a near-worst value, so passing it means every important interaction — not just the average one — has to feel fast. If your Core Web Vitals report shows a red or amber INP, this guide walks through how to diagnose the slow interactions and fix them at the source.
INP is the Core Web Vital most sites fail, and it is the one most teams misunderstand. It is not a page-load metric. It measures runtime responsiveness — what happens when someone actually uses the page — which makes it harder to fake and harder to fix than the metrics it sits alongside. Getting INP optimization right is now table stakes for technical SEO on any interactive site.
What INP actually measures
Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vital on 12 March 2024, according to Google’s web.dev documentation. The change matters because FID only counted the delay before the browser began handling your first interaction. It ignored everything after that. A page could score a perfect FID and still freeze for a full second every time someone tapped a filter.
INP closes that gap. It observes almost every interaction across the page’s lifetime and reports a single value near the worst one. Each interaction is broken into three parts:
- Input delay — time from the tap or click until the event handler starts, usually spent waiting for the main thread to free up.
- Processing time — how long your event handlers take to run.
- Presentation delay — time for the browser to recalculate layout and paint the next frame.
An interaction feels slow when any of those three phases stretches out. Most real-world INP problems live in the first and third phases: a busy main thread that cannot start your handler, or an expensive re-render that delays the paint. The processing time in the middle is often smaller than people assume.
The threshold is unforgiving. A good INP is 200 milliseconds or less at the 75th percentile of field data, per web.dev’s INP guidance. Between 200 and 500 milliseconds needs improvement; above 500 milliseconds is poor. Because Google uses the 75th percentile, your slowest quarter of interactions decides the outcome. Your median can be excellent and you still fail.
Why INP is a genuine ranking concern
Core Web Vitals feed Google’s page experience signals, which the ranking systems use to separate pages of comparable relevance. Google’s Search Central documentation is explicit that these are a tie-breaker, not a primary factor. INP optimization will not rescue thin content or a weak link profile.
But the tie-breaker framing undersells it on mobile. Interactions on phones are slower — weaker CPUs, more thermal throttling, heavier ad and tag scripts — so mobile INP is where sites bleed. If your rankings are strong but your click-through and engagement lag on mobile, a poor INP is often part of the story. This is the kind of gap a proper technical SEO audit is built to surface before it shows up as lost revenue.
There is a second, quieter reason to care. INP correlates with how the page feels, and a page that feels sluggish loses conversions regardless of where it ranks. You are optimising for the same thing Google is: users who do not abandon.
The five-step INP debugging process
I use the same sequence on every engagement. It moves from real-world evidence to root cause to fix, in that order, because the biggest mistake teams make is optimising interactions that were never slow for real users.
Step 1 — Confirm the problem in field data. Open the Core Web Vitals report in Google Search Console or run the URL through PageSpeed Insights. Both use Chrome UX Report data — real Chrome users, not a synthetic lab run. If field INP is green, stop. You do not have an INP problem worth chasing, whatever your lab score says.
Step 2 — Identify which interactions are slow. Field data tells you the page has a problem, not which button causes it. Use the web-vitals JavaScript library or a real-user monitoring tool to attribute INP to specific elements and event types. On most sites two or three interactions — a menu toggle, a filter, an add-to-cart — account for nearly all the damage.
Step 3 — Reproduce it in the lab. Open Chrome DevTools, throttle the CPU to 4x slowdown to simulate a mid-range phone, and record the slow interaction in the Performance panel. You are looking for the long task on the main thread that blocks the response. Long tasks — anything over 50 milliseconds — are the raw material of poor INP.
Step 4 — Attribute the cost. Read the flame chart. Is the delay before your handler runs (input delay from a blocked main thread), inside your handler (heavy synchronous work), or after it (an expensive re-render or layout thrash)? The phase decides the fix. This is where Total Blocking Time from your lab reports becomes useful — high TBT almost always predicts poor INP, because both are driven by long main-thread tasks.
Step 5 — Fix, then re-measure in the field. Ship the fix and wait. Field data is a 28-day rolling window, so a genuine improvement takes weeks to fully appear in Search Console. Do not judge the fix by the lab number alone.
The fixes that actually move INP
Once you know the phase, the remedies are concrete.
Break up long tasks. The single highest-leverage fix. Any script that runs for more than 50 milliseconds blocks every interaction that lands during it. Split long-running work into smaller chunks and yield control back to the browser between them — scheduler.yield() where supported, or setTimeout and await patterns as a fallback. Yielding lets a pending click be handled between chunks instead of after all of them.
Cut and defer JavaScript. Less code on the main thread is less INP risk. Audit third-party tags ruthlessly — chat widgets, A/B testing scripts, analytics, and tag managers are frequent offenders because they run on every interaction. Defer or lazy-load anything not needed for the first interaction. In my experience auditing sites, third-party scripts are the most common INP cause teams overlook, precisely because they were added by marketing, not engineering, and nobody owns their performance cost.
Move work out of the critical path. If an event handler does expensive computation, do the minimum needed to give visual feedback first — update the UI — then run the heavy work afterward, ideally in a web worker or after the next paint. The user sees a response immediately even if the full result takes longer.
Reduce rendering and DOM cost. Presentation delay grows with DOM size and layout complexity. Large DOM trees, deeply nested components, and CSS that forces synchronous layout all slow the paint after an interaction. Simplify the DOM, avoid layout thrash, and use CSS content-visibility to skip rendering off-screen content.
Fix hydration on framework sites. On React, Vue, and similar stacks, hydration can lock the main thread during the exact window when users first try to interact. Consider progressive or selective hydration, server components, or islands architecture so the page becomes interactive in pieces rather than all at once.
An INP optimization checklist
Run this before you call an interaction fixed:
- Field INP is confirmed red or amber in Search Console — you are fixing a real problem
- The specific slow interactions are identified by element and event type
- The slow interaction is reproduced in DevTools with 4x CPU throttling
- The blocking long task is identified in the Performance flame chart
- The delay phase is attributed (input delay, processing, or presentation)
- Long tasks over 50ms are broken up with yielding
- Non-essential third-party scripts are deferred or removed
- Expensive handler work runs after visual feedback, not before it
- DOM size and layout cost are reduced where they delay paint
- The fix is verified in field data after a 28-day window
Work top to bottom. Skipping the field-data steps is how teams spend a sprint optimising an interaction that was never slow for real users.
Where INP optimization fits in your wider strategy
INP is one lever, and it sits inside page experience, which sits inside a much larger ranking picture. Fix it because a fast, responsive page converts better and protects you on the close ranking calls — not because you expect it to be the thing that moves you from page two to page one. That is rarely how Core Web Vitals work.
If your field data shows a persistent INP failure and your team cannot find the root cause, that is usually a sign the problem is architectural — too much JavaScript, too many tags, a rendering strategy that fights the main thread. Those are worth bringing in outside eyes for. A focused technical SEO engagement or a one-off site audit will find the blocking tasks faster than a team debugging its own code, and if you want to understand how I work before committing, the freelance consultant page lays it out. Good INP optimization is unglamorous, measurable, and permanent once done — exactly the kind of technical work that quietly compounds.
Frequently Asked Questions
What is a good INP score?
A good Interaction to Next Paint is 200 milliseconds or less at the 75th percentile of your field data, across both mobile and desktop. Between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor. Google measures at the 75th percentile, so your slowest quarter of real interactions determines whether the page passes.
Is INP a Google ranking factor?
Yes, indirectly. INP is one of the three Core Web Vitals, and Core Web Vitals feed Google’s page experience signals, which act as a tie-breaker between pages of similar relevance. A poor INP will not sink strong content on its own, but it can cost you the close calls, particularly on mobile.
What is the difference between INP and FID?
First Input Delay only measured the delay before the browser started handling your first interaction. INP measures the full latency — input delay, processing time, and presentation delay — of nearly every interaction across the visit and reports a near-worst value. That makes INP much harder to pass, which is why Google replaced FID with it in March 2024.
How do I measure INP on my site?
Start with field data: the Core Web Vitals report in Google Search Console, or PageSpeed Insights for a single URL, both using Chrome UX Report data. Once you confirm a real problem, reproduce the slow interaction in Chrome DevTools’ Performance panel with CPU throttling to find the long task blocking the response.
Can JavaScript frameworks cause poor INP?
Frequently. Heavy hydration, large third-party scripts, and expensive event handlers all run on the main thread and block the browser from responding. Frameworks are not the problem in themselves — shipping too much JavaScript and doing too much synchronous work in event callbacks is — but that pattern is common on React and Vue sites.
