If your site scores well on Lighthouse but still feels laggy, the moment someone clicks a filter, opens a menu, or submits a form — you have an INP problem, not a load-time problem.
Interaction to Next Paint (INP) became a Core Web Vital, replacing First Input Delay (FID). Unlike FID, which only measured the very first click on a page, INP measures how quickly a webpage responds to every user interaction throughout an entire visit. That distinction matters more than most teams realize: a site can post an excellent FID score and still feel broken the moment heavy JavaScript runs mid-session instead of at load.
This guide covers what INP measures, why most existing INP content stops short of being useful, and the specific, framework-level fixes that bring real sites under the 200ms threshold — with code.
What Is Interaction to Next Paint?
Interaction to Next Paint measures how quickly a website responds to user interactions like clicks or key presses — specifically, how much time elapses between a user interaction and the next time the user sees a visual update on the page. It captures clicks, taps, and keyboard input across the entire session, not just the first one.
A good INP score is 200 milliseconds or less at the 75th percentile. Google scores your site using the CrUX (Chrome User Experience Report) field data collected from real visitors, not a synthetic lab test — so INP reflects what actual users on actual devices experience.
| INP Value | Rating |
| 0–200ms | Good |
| 200–500ms | Needs Improvement |
| 500ms+ | Poor |
Despite two years of attention, this metric is still the industry’s biggest blind spot. Roughly 40% of origins on mobile still fail to meet INP thresholds heading into 2026, making it a persistent liability for search rankings and user experience alike.
The Three Phases of an Interaction
Every user interaction that INP measures is made up of three phases, and knowing which one is broken tells you exactly which fix to reach for.
- Input delay — the time between the user’s action and the browser starting to process it. Usually caused by the main thread already being busy with another task.
- Processing duration — the actual work your event handler, framework, and re-renders do in response to the interaction.
- Presentation delay — the time it takes the browser to paint the visual result to the screen once processing is done.
INP reports the longest of these full interactions observed during a session, so fixing your average case isn’t enough — you have to eliminate the outliers.
Why INP Is Hard to Fix (and Why It’s Worth Fixing)
INP is a frontend queueing problem in disguise. Think of the main thread like a single-lane road: when a large task — a 10,000-row filter, a heavy re-render, a synchronous JSON parse — is running, every user interaction has to wait in line behind it before the browser can even start responding.
The business cost is measurable, not theoretical. Improving INP from 500ms to 200ms correlates with a 22% improvement in user engagement metrics including time on page and return visits, and a widely cited INP case study on web.dev found a 7% sales lift after a company implemented responsiveness improvements tied to INP. For a checkout flow, a lead-gen form, or a SaaS dashboard, every sluggish click is a small tax on conversion.
How to Measure INP (Before You Touch Any Code)
Don’t optimize blind. Start with field data, then move to lab tools to reproduce and debug:
- Chrome UX Report (CrUX) / PageSpeed Insights — real-user field data at the URL and origin level.
- Search Console → Core Web Vitals report — flags which page groups are failing INP in production.
- web-vitals JS library — drop it into your app to log real INP scores per session, segmented by device or route.
- Chrome DevTools Performance panel — record a session, reproduce the slow interaction, and inspect the flame chart.
- Long Animation Frames (LoAF) API — pinpoints exactly which script or function is responsible for a slow frame, which is far more actionable than a generic “long task” warning.
Fix based on the interaction that’s actually failing in the field, not the one that’s easiest to reproduce locally.
Fixing Input Delay
Input delay usually means the main thread is tied up before the click even registers.
- Code-split and lazy-load non-critical JavaScript so it isn’t competing with interaction handling.
- Defer or async non-essential third-party scripts (chat widgets, analytics, ad tags) — audit these first, they’re a common hidden culprit.
- Break up long tasks at their source using scheduler.yield(), which pauses execution to let the browser handle pending high-priority work, then resumes where it left off:
async function yieldToMain() {
if (‘scheduler’ in window && ‘yield’ in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}
async function processLargeDataset(items) {
for (let i = 0; i < items.length; i++) {
processItem(items[i]);
if (i % 50 === 0) await yieldToMain(); // give the main thread breathing room
}
}
This single fix — breaking long tasks into smaller chunks with scheduler.yield() — is often the highest-leverage change you can make, since it directly reduces the wait time for every pending interaction. Note browser support: Chrome and Edge support it from version 129, Firefox from 142, and Safari does not yet support it — always ship the setTimeout fallback shown above.
Fixing Processing Duration
This is where most of the real engineering work lives.
- Debounce, don’t just throttle, expensive input handlers. Throttling still recalculates on an interval while the user types or scrolls; debouncing waits until they stop, which is usually the better trade-off for search and filter inputs. One team found that replacing a throttled scroll handler with a debounced one produced a noticeably smoother result because the calculation only ran once activity settled.
- Move heavy computation off the main thread with Web Workers — JSON parsing, sorting large datasets, or client-side filtering are good candidates.
- Virtualize long lists and tables so you’re only rendering what’s visible, not re-rendering thousands of DOM nodes on every keystroke.
- Avoid layout thrashing — batch DOM reads and writes instead of interleaving them, which forces the browser into repeated synchronous reflows.
For a search filter over a large table, a typical fix chain looks like: debounce the input, paginate or virtualize the results, and render only the visible rows instead of re-rendering the full table on every keystroke.
Framework-specific notes
React: memoization, debouncing, concurrent rendering features, and virtualization are the techniques that most directly move the INP needle. React 18’s concurrent rendering yields back to the main thread roughly every 5ms during rendering to check for higher-priority work like user input, so upgrading rendering strategy alone can meaningfully help — but it isn’t a substitute for fixing genuinely long synchronous handlers.
Vue / Angular / vanilla stacks: the same principles apply — the framework name changes; the fix doesn’t. Identify the long task with the Performance panel or LoAF, then split, defer, or move it off-thread.
Fixing Presentation Delay
Once processing finishes, the browser still has to paint. Reduce this by:
- Simplifying complex CSS selectors and reducing DOM depth in the area being updated.
- Avoiding non-composited animations (animate transform/opacity instead of properties that trigger layout).
- Giving users instant visual feedback (a pressed state, a spinner, a skeleton) — this doesn’t reduce the technical INP number by itself, but it’s good practice alongside the real fix, since perceived responsiveness matters for user trust even while you’re shipping the underlying fix.
The Prioritized INP Checklist
Work through these roughly in order of impact per hour of engineering time:
- Audit and defer/async third-party scripts.
- Find your top 3 slowest interactions in CrUX/Search Console field data.
- Reproduce each in DevTools and identify the responsible script via the LoAF API.
- Break up the long task with scheduler.yield() (with fallback).
- Debounce expensive input handlers; replace throttling where appropriate.
- Virtualize large lists/tables; paginate where virtualization isn’t feasible.
- Move CPU-heavy work (parsing, sorting, filtering) to a Web Worker.
- Re-measure with field data — lab data alone won’t confirm the fix.
FAQ
Is INP a ranking factor?
Yes — INP is one of Google’s three Core Web Vitals that impact search result rankings, alongside Largest Contentful Paint and Cumulative Layout Shift.
Can I test INP without real users?
Not directly — INP relies on real user interactions and is primarily measured through field data, since it requires an actual interaction to occur, though you can script interactions in a lab environment to approximate it.
What replaced FID, and when?
INP replaced First Input Delay as a Core Web Vital in March 2024.
The Bottom Line
INP rewards continuous engineering discipline, not a one-time fix. You can’t optimize only the initial page load and call it done — every interaction throughout the session counts toward your score. Teams that treat responsiveness as an ongoing budget, not a launch checklist, are the ones that stay under 200ms as their product grows.
If your team doesn’t have the bandwidth to profile long tasks, restructure rendering, and re-test against field data on an ongoing basis, that’s exactly the kind of performance engineering work we take on for clients — get in touch and we’ll audit your site’s real INP data before you spend a single engineering hour guessing.