INP: The New Critical Metric Replacing FID
On March 12, 2024, Google completed the transition of Core Web Vitals: FID (First Input Delay) and exited, INP (Interaction to Next Paint) and entered. A silent change in the panels of Google Search Console which however has real impacts on the SEO ranking of millions of sites. According to i data from the Chrome User Experience Report (CrUX), the 43% of websites still fail INP "Good" threshold (under 200ms), a significantly higher number than to the 30% of sites that failed FID.
FID only measured the delay to first input: how much time had passed since the user clicked for the first time when the browser began processing that event. It was an easy metric to beat because it only measured the first interaction and didn't hold up account of the next paint. INP is radically different: measure the responsiveness overall for the entire duration of the session, choosing as the final score the worst percentile of interactions.
What You Will Learn
- How INP differs from FID and why it measures actual responsiveness
- INP Good/Needs Improvement/Poor thresholds (200ms / 500ms)
- How to measure INP with Chrome DevTools, web-vitals.js and PageSpeed Insights
- The five most common JavaScript patterns that explode INP
- How to interpret CrUX field data vs Lighthouse synthetic data
- The debugging workflow to find and fix slow interactions
What INP Measures: The Technical Definition
INP observes all user interactions with the page during the visit: clicks, taps and key presses. For each interaction, measure the time since the input of the user at the time the browser paints the next frame that reflects the visual response to that input. This interval is called interaction latency and is made up of three parts:
- Input delay: the time that passes before the browser starts processing the event (the main thread was busy)
- Processing time: the execution time of JavaScript event handlers
- Presentation delay: the time it takes for the browser to layout, paint, and composite the new frame
INP takes the 98th percentile of all interactions in the session (or the worst value if there are fewer than 50 interactions). Not the average, not the typical value: almost the worst. This makes INP much more sensitive to latency spikes than FID.
The INP Thresholds
| Rating | INP value | SEO impact |
|---|---|---|
| Good | < 200ms | Contributes positively to ranking |
| Needs Improvement | 200ms - 500ms | Neutral, area for improvement |
| Poor | > 500ms | Google ranking penalty |
FID vs INP: The Substantial Difference
To understand why the transition from FID to INP is an important change, consider this scenario: you have an e-commerce page. Upon first loading, the user clicks "Add to Cart" and the event is processed in 50ms (excellent FID). Then navigate the page, filter products, opens a category dropdown. This second interaction takes 800ms because it is a heavy computation it is running on the main thread.
With FID: the score was 50ms - Good.
With INP: the score is 800ms - Poor.
INP reflects the actual user experience throughout the session, not just the first click. This is why many sites that had excellent FID now have problematic INP.
How to Measure INP
1. Chrome DevTools - Performance Panel
The most accurate way to diagnose INP is the Performance panel of Chrome DevTools. Proceed like this:
- Open DevTools (F12) and go to the tab Performance
- Click the red circle to start recording
- Run the interactions you want to measure (clicks, typing, etc.)
- Stop recording
- In the resulting panel, look for the red bars in the section Interactions
- Click on an interaction to see the breakdown: input delay, processing time, presentation delay
2. Web Vitals JS Library (Field Data)
The library web-vitals of Google allows you to measure real INP of users in production.
Add it to your project and send the data to an analytics endpoint:
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights and CrUX
PageSpeed Insights shows real CrUX data for your domain in the "Field Data" section. Please note that CrUX data is based on Chrome users who have sync enabled, therefore they reflect real experience on real devices, not synthetic Lighthouse results that run on hardware controlled.
Lab Data vs Field Data
Lighthouse and PageSpeed Insights in "Lab" mode simulate a mid-range mobile device on a slow 4G connection. CrUX data (Field Data) reflects real users of your site. It is normal to have discrepancies of 30-50% between the two measurements. Use field data as an indicator primary for SEO decisions, and lab data for technical debugging.
The Most Common Patterns That Cause High INP
1. Long Tasks on the Main Thread
The main culprit of high INP is the presence of Long Tasks: JavaScript tasks
that last more than 50ms. Each Long Task blocks the browser's main thread, preventing it from responding
to user input. The easiest way to identify them is the DevTools Performance panel
or the API PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. Heavy Event Handlers
Click handlers performing heavy computation synchronously are a frequent cause of high INP. The typical pattern is a handler that:
- Filter or transform large arrays in memory
- Massively render the DOM (add hundreds of elements)
- Calculate complex layouts or force browser reflow
- Parses large JSON
3. React/Angular Change Detection Not Optimized
In frameworks like React or Angular, a single event can trigger a change detection cycle which recalculates the entire component tree. In complex components or in the absence of memoization appropriate, this may take 100-400ms.
In Angular, the solution is ChangeDetectionStrategy.OnPush and the use of signals for
granular reactivity. In React, React.memo, useMemo e useCallback
they are the key tools.
4. Third-Party Scripts
Analytics, chat widgets, ad scripts and other third-party scripts often run on the main thread and can block the response to inputs. To identify them, in the DevTools Performance panel look for Long Tasks originating from third-party domains.
5. Hydration in SSR Frameworks
In applications with SSR (Next.js, Angular Universal, Nuxt), the hydration phase can be expensive. During hydration, the framework reattaches event handlers to the rendered DOM server-side. If this phase overlaps with a user interaction, the INP suffers.
The INP Debugging Workflow
Here is the recommended workflow for diagnosing and correcting high NPI:
- Identify problematic interactions using the Performance panel by DevTools. Look for interactions with latency > 200ms in the Interactions section.
- Analyze the breakdown: which of the three components (input delay, processing, presentation) is the largest?
- If is the input delay: Something else was running on the main thread at the time of the click. Look for Long Tasks preceding the interaction in the timeline.
-
If and the processing time: Your event handlers are too slow.
USA
scheduler.yield()to break them (see next article). - If and the presentation delay: Frame rendering is slow. Look for thrashing layouts, expensive CSS animations, or excessive compositing layers.
INP and SEO: The Real Impact
Google has confirmed that Core Web Vitals, including INP, are ranking factors. The weight Exactly isn't public, but empirical evidence shows that going from "Poor" to "Good" on INP can bring 2-5% ranking improvements for competitive pages. For sites with traffic significant organic, this translates into measurable traffic increase.
The top priority must be to bring all the main pages (homepage, category pages, product pages) to the "Good" rating (< 200ms). Static content pages rarely have INP problems; the problems focus on pages with complex interactive interfaces.
Next Steps
Now that you know how to measure and identify INP problems, the next step is to learn how to
fix them: the next article in this series explains how to use scheduler.yield()
to break up Long Tasks and free up the main thread between one interaction and another.
For the rendering side, the LCP Optimization article covers techniques to reduce the presentation delay and accelerate the paint of the first significant frame.
Conclusions
INP represents a paradigm shift in web performance measurement: it is not enough that the page loads quickly, it must also answer quickly throughout the duration of the session. 43% of sites that fail INP's Good threshold have an opportunity concrete way to improve both user experience and SEO ranking.
The starting point is always measurement: install web-vitals.js in yours
site, collect real user data, and use Chrome DevTools to diagnose interactions
problems. Only with concrete data will you be able to make informed optimization decisions.