Interaction to Next Paint (INP) is the Core Web Vital most sites fail, and it is the one most teams still do not understand. A good INP score is 200 milliseconds or less, measured at the 75th percentile of real user interactions; 200–500ms needs improvement, and anything above 500ms is poor. As of mid-2026, roughly 43% of sites still fail the 200ms threshold — making INP the most commonly failed Core Web Vital and a real, fixable ranking and UX problem.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and the change mattered. FID only measured the delay before the browser started processing your first interaction — a low bar that most sites passed without trying. INP measures the full latency of interactions throughout the visit, from tap to the next visual update. It is a much more honest measure of how responsive a page actually feels.
What INP actually measures
INP looks at every click, tap, and key press during a page visit and reports (close to) the worst interaction latency. Each interaction is measured in three parts:
- Input delay — time before the event handler can start, usually because the main thread is busy doing something else.
- Processing time — how long your event handlers take to run.
- Presentation delay — time to render the next frame after the handlers finish.
The total of those three is what the user perceives as “did the page respond.” A high INP feels like lag: you tap, and nothing happens for a beat. That hesitation is what Google is now measuring, and it correlates strongly with how cheap or expensive your front-end is to run on a mid-range phone.
Why sites fail INP
The root cause is almost always the same: too much JavaScript executing on the main thread.
Long tasks block the main thread
The browser runs your JavaScript on a single main thread, and while a long task is running, the page cannot respond to input. A task that takes 300ms means any tap during that window waits at least 300ms. Heavy frameworks, large bundles, and unoptimized application code create long tasks, and those long tasks are the direct cause of poor input delay.
Third-party scripts
Tag managers, analytics, chat widgets, A/B testing tools, and ad scripts run on the same main thread as your own code. A single poorly-behaved third-party script can dominate INP across the entire site, and because it loads from someone else’s server, you often cannot see it in your own code review. Auditing third-party weight is frequently the highest-ROI INP work available.
Expensive event handlers and layout thrash
Handlers that do heavy synchronous work — large DOM updates, synchronous layout reads and writes interleaved, expensive state recalculation — push up processing and presentation time. React and other framework re-renders that touch large parts of the tree on every interaction are a common culprit.
How to fix INP
Ship less JavaScript
The most durable fix is to send less code in the first place. This is why architecture matters: a site built to hydrate an entire React tree pays an INP tax that a mostly-static site never incurs. Frameworks that ship near-zero JavaScript by default — and only hydrate the interactive islands — start from a structurally better position, which is a large part of why we build content sites the way we do in our website development practice.
Break up long tasks
Where you do run JavaScript, break long tasks into smaller chunks so the browser can respond to input between them. Yield to the main thread (for example with scheduler.yield() or by deferring non-urgent work), and move heavy computation off the critical path. The goal is that no single task hogs the thread long enough to delay an interaction.
Defer and tame third parties
Load non-critical third-party scripts late, after the page is interactive, and question every tag. Many analytics and marketing scripts can be deferred, loaded on interaction, or moved to a more efficient loading strategy without losing the data you actually use. On WordPress specifically, plugin sprawl is the leading cause of third-party bloat, which is why we treat plugin discipline as core to WordPress engineering rather than an afterthought.
Optimize what runs on interaction
Keep event handlers lean. Debounce expensive work, avoid synchronous layout thrash, and for framework apps, narrow the scope of re-renders so a single click does not recompute the whole page. Render the visual feedback first (the state the user expects to see), then do the heavier work afterward.
How to measure it correctly
INP is a field metric — it reflects real users on real devices, not a single lab run. Use Chrome User Experience Report (CrUX) data and tools that read it (PageSpeed Insights, Search Console’s Core Web Vitals report) to see your actual 75th-percentile INP. Lab tools like Lighthouse can estimate and help you debug, but they cannot replicate the range of devices and interactions your real audience brings. Fix in the lab, verify in the field.
A useful debugging loop: reproduce the slow interaction in Chrome DevTools’ Performance panel, find the long task in the flame chart, identify the script responsible, and attack that specific task. INP problems are almost always concentrated in a handful of interactions, not spread evenly — find the worst one and you have found most of the score.
The bottom line
INP rewards sites that respect the main thread and punishes sites that drown it in JavaScript. The fastest path to a good score is structural — ship less code, defer what you can, and keep interactions cheap — which is the same discipline that produces good Core Web Vitals at scale generally. If your site is failing INP and the usual caching-and-plugins advice has not moved it, the problem is in the JavaScript execution model, and that is exactly what our performance and website development work is built to fix.