INP: The New Core Web Vital Most Teams Are Failing
Interaction to Next Paint (INP) measures the latency between a user's interaction and the visual update that results from it. Unlike First Input Delay, which only measured the delay before the browser started processing the first input, INP measures the full interaction latency for all clicks, taps, and keypresses across the entire page session. A good INP is under 200 milliseconds. Poor is above 500 milliseconds.
Written by Yashveer Singh, founder of Yashveer Labs.
What you need to know
- INP replaced FID as a Core Web Vital in March 2024. Sites that passed FID are not automatically passing INP. The two metrics measure fundamentally different things.
- INP measures interaction responsiveness throughout the full page session. A page can have good LCP and FID but terrible INP if the JavaScript makes the page sluggish to use after load.
- The three components of INP are input delay, processing time, and presentation delay. Each has different root causes and different fixes.
- Long main-thread tasks are the primary cause of high input delay. Breaking tasks with
scheduler.yield()is the modern fix. Yielding every 50 milliseconds keeps tasks within the browser's long task threshold. - INP is measured from field data, not lab data. Lighthouse does not capture INP. Use CrUX data in PageSpeed Insights or the Web Vitals Chrome extension to see real user INP.
The core argument
The reason most teams are failing INP is that the failure mode is invisible during development. A developer with a fast machine and no other tabs open will not notice a 400ms interaction delay because the main thread is rarely blocked during testing. Real users on mobile devices with backgrounded apps, slower CPUs, and a full JavaScript bundle running on top of each other experience a very different responsiveness profile. INP captures that real-user experience and translates it into a score, which is why so many sites that were passing FID are now failing INP.
The most common INP failure pattern I see is large event handlers. A click handler that runs complex synchronous logic, updates multiple state variables, re-renders a large component tree, and queries the DOM is the pattern that produces INP scores of 400 to 800 milliseconds. The fix is to keep event handlers minimal: update the visual state immediately, then defer the heavy work. The user perceives a responsive interaction because the visual update happens within 200 milliseconds. The background work completes after, without blocking the next interaction. This pattern applies to search inputs, form submissions, dropdown menus, and any interaction that triggers significant JavaScript execution.
The presentation delay component is less commonly discussed but significant on sites with complex render trees. After an event handler finishes, the browser needs to recalculate styles, perform layout, and paint the result. If the render tree is large or the CSS is complex, this phase can add 100 to 200 milliseconds to the interaction latency. Reducing render tree complexity, avoiding forced synchronous layouts, and using content-visibility to skip offscreen rendering all reduce presentation delay. The combination of a minimal event handler and a lean render path is the architecture that produces good INP at scale.
Common mistakes
- Treating INP as an LCP problem. LCP and INP are separate metrics with separate root causes. Optimizing resource loading improves LCP but does not help INP. INP is a JavaScript execution problem, not a network problem.
- Not measuring INP from real user data. Lighthouse lab scores do not include INP because it requires actual interaction. Use CrUX data in PageSpeed Insights, the Web Vitals library with analytics integration, or Chrome UX Report to get real INP values from production traffic.
- Deferring third-party scripts but not auditing their event listener overhead. Third-party scripts that attach global click listeners or intercept input events can add processing time to every interaction on the page. Audit third-party script event listener footprint separately from your own code.
- Using `setTimeout(0)` instead of `scheduler.yield()` for task chunking.
setTimeout(0)yields to the event loop but does not prioritize user input.scheduler.yield()explicitly gives the browser a chance to respond to pending user interactions before continuing the deferred work. Usescheduler.yield()for any chunked work that runs during or after user interaction.
- Not testing on mid-range mobile hardware. INP failures are often invisible on developer machines. Test on an actual mid-range Android device or use Chrome DevTools CPU throttling at 4x to simulate the execution environment where most real users experience your product.
Where to start
- Get your current INP score from real data. Open PageSpeed Insights for your highest-traffic page and look for the INP score in the field data section. If it is in the "needs improvement" range (200 to 500ms), you have actionable work to do.
- Profile your highest-traffic interactions with Chrome DevTools. Open the Performance panel, record a session while clicking through the key interactions, and look for long tasks and large event handler execution times. The flame chart makes the bottlenecks visible.
- Break up the largest event handlers. Take the handler with the most JavaScript execution time and separate the immediate visual update from the deferred work. Use
scheduler.yield()after the immediate update and before the heavy logic. Measure the interaction time before and after.
Related reading
Frequently asked
The work I take and why
I take work that compounds. I do not take work that is rework with extra steps. Yashveer Singh, founder of Yashveer Labs. If the topic on this page is what you are dealing with, the question is not whether it can be solved. It can. The question is whether you want to solve it once or four times. I am the person who solves it once.
Posts that line up with this one.
- Performance Optimization
Image Optimization at Scale: AVIF, WebP, Responsive Images
Images are the largest contributor to page weight on most web products. Here is the format selection, responsive image, and delivery strategy that cuts load time without manual work.
- Performance Optimization
Largest Contentful Paint: The Metric That Changes Conversions
LCP is the Core Web Vital that measures how fast the main content loads. It is also the metric most directly correlated with conversion rate. Here is what causes poor LCP and how to fix it systematically.
- Performance Optimization
Lazy Loading: The Patterns That Work and the Ones That Backfire
Lazy loading reduces initial page weight when done correctly. When done incorrectly, it delays the content users actually need and hurts Core Web Vitals. Here is how to apply it with precision.
- Performance Optimization
Memory Leaks in Long Lived Web Apps
Memory leaks in single-page applications are invisible until the tab slows to a crawl. Here is how they form, how to detect them, and the patterns that eliminate the most common sources in React applications.