INP Replaced FID. Here Is What That Actually Means for Your Site.
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vitals metric in March 2024. As of 2026, it is still the metric where I see the most persistent gaps in client audits — not because teams are unaware of it, but because fixing INP requires a different kind of debugging than what most front-end teams are used to.
This post covers what INP actually measures, why it is harder to fix than FID, and what a realistic optimization process looks like.
What INP Measures (and Why It Is Harder Than FID)
FID measured the delay before the browser could begin processing a user's first interaction. INP measures the full responsiveness of any interaction throughout the page's lifecycle — click, tap, keyboard input — and reports the worst one (or close to it).
The difference matters enormously in practice:
- FID was measured at first interaction, often a click before the page was fully loaded. Optimizing FID mostly meant reducing main-thread blocking during initial load.
- INP is measured across the entire session. A user who clicks a filter on your product page, expands an accordion, or submits a form — any of those interactions can tank your INP score if they cause long tasks on the main thread.
A page can have excellent initial load performance and terrible INP. I see this regularly on sites that have invested heavily in LCP and CLS while leaving JavaScript interaction handlers unoptimized.
The INP Thresholds
| Score | Threshold |
|---|---|
| Good | ≤ 200ms |
| Needs Improvement | 201–500ms |
| Poor | > 500ms |
The 200ms threshold is achievable but not trivial. The common mistake is assuming that a 400ms INP is "close enough." It is not — Google's field data from Chrome UX Report (CrUX) confirms that pages in the "needs improvement" range see measurable ranking disadvantage compared to "good" pages in competitive queries.
Where INP Problems Come From
After auditing INP across dozens of client sites, the culprits break into three categories:
1. Long JavaScript tasks blocking the main thread
The most common cause. When a user clicks a button and your site executes a 600ms JavaScript task before rendering the response, INP is 600ms.
Tools to find these:
- Chrome DevTools Performance tab → look for long tasks (red bars in the main thread timeline)
PerformanceObserverwithlongtasktype in production monitoring- Google's Lighthouse in CI
Common sources: analytics batching, A/B test framework evaluation, poorly structured React re-renders.
2. Input delay from timer-heavy event handlers
If your click handlers do expensive synchronous work (DOM queries across large trees, unoptimized loops, synchronous storage reads), the delay accumulates.
The fix is usually breaking work into smaller chunks: setTimeout(() => {}, 0) to yield to the browser, requestIdleCallback for non-urgent work, or proper async boundaries.
3. Rendering delay after the processing phase
Even if the event handler is fast, the browser still needs to repaint. Complex CSS animations, large DOM trees, and forced layout recalculations all increase rendering time after a user interaction.
A Realistic Optimization Process
The right order of operations:
-
Establish field data — install CrUX monitoring or use a RUM tool (Web Vitals JS library, Sentry Performance, or Datadog RUM). Lab data from Lighthouse does not always capture INP accurately.
-
Identify the interactions — the CrUX data will tell you which interaction types are causing poor INP. It is often a small number of interactions responsible for most of the problem.
-
Profile in DevTools — reproduce the worst interactions in Chrome DevTools with the Performance recorder. Identify the specific tasks causing the delay.
-
Chunk and yield — restructure long synchronous tasks to yield to the browser between chunks. React 18's concurrent features (
useTransition,useDeferredValue) are useful here if you are on a React stack. -
Validate in field data — after deploying fixes, wait 28 days for field data to reflect changes in CrUX (it uses a rolling 28-day window).
What to Prioritize First
If you are starting from scratch on INP optimization:
- Check CrUX via PageSpeed Insights for your most important landing pages
- Focus on interactions that happen on high-traffic pages (product pages, checkout, search results)
- Look for third-party scripts that fire on interaction — these are a common and often easy win (lazy-load or defer analytics and chat widgets)
- Check if your JavaScript bundle is large and synchronous — code-splitting reduces the probability of long tasks during critical interactions
The Underrated Factor: Device Distribution
INP is measured on real user devices in the field. If a significant portion of your users are on mid-range Android devices with 2–4 GB RAM, your INP in the field will be worse than what you measure on a developer MacBook.
Always check your CrUX data segmented by device type. Mobile INP is typically 2–4x worse than desktop INP. If you are optimizing for desktop only, you are missing the audience that needs it most.
INP is harder to fix than any previous Core Web Vitals metric because it requires understanding your full JavaScript execution model, not just your initial load path. But the sites that have done the work are seeing both ranking benefits and measurable conversion rate improvements — faster interactions increase task completion.
If you want to walk through your site's INP profile, let's talk.