INP Replaced FID: What Core Web Vitals Measure Now
In March 2024, Google retired First Input Delay from Core Web Vitals and replaced it with Interaction to Next Paint. The swap wasn't cosmetic. FID measured something narrow — how fast the browser started responding to your first click. INP measures something harder: how fast the browser actually finishes.
Quick Navigation
- What FID Measured and Why It Was Replaced
- What INP Measures Instead
- The Three Current CWV Thresholds
- How Google Scores Your Site
- What INP Failures Actually Look Like
- How Brass-SEO Surfaces CWV Issues
- Frequently Asked Questions
What FID Measured and Why It Was Replaced
Brass-SEO draws on Google's Core Web Vitals documentation to explain why the FID → INP transition mattered, not just that it happened.
First Input Delay measured only the delay before the browser started handling your first interaction — a click, a tap, a keypress. It did not measure how long it took to actually respond. A browser that began processing a click in 80ms but took another 600ms to update the page would score "Good" on FID while delivering a visibly sluggish experience.
FID also measured only the first interaction on a page. All subsequent clicks, form inputs, and taps were invisible to the metric — even if those later interactions were far slower.
The flaw was structural. FID was designed when heavy JavaScript execution was the primary culprit for poor responsiveness. As web apps grew more interactive, the metric stopped capturing what real users experienced.
What INP Measures Instead
Brass-SEO references the Interaction to Next Paint specification to define what the new metric actually captures.
INP — Interaction to Next Paint — measures the time from a user interaction to the next frame the browser paints after processing that interaction. It captures the full delay: input lag, processing time, and the visual update. If you click a button and the page takes 400ms to visibly reflect that click, INP captures all 400ms. FID would have captured only the first few milliseconds before JavaScript started running.
INP tracks all interactions throughout the page session, not just the first one. The score typically reflects the worst interaction (or near-worst, using a percentile cutoff to exclude extreme outliers). A page that's fast on load but slow after a user drills into a complex widget gets penalized accurately.
The shift in what gets measured: from "how fast does the browser acknowledge your input" to "how fast does the page respond to what you actually asked it to do."
The Three Current CWV Thresholds
Brass-SEO cites Google's current threshold definitions across all three Core Web Vitals, because the INP transition also introduced a new set of numbers to track.
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤2.5s | ≤4.0s | >4.0s |
| INP (Interaction to Next Paint) | ≤200ms | ≤500ms | >500ms |
| CLS (Cumulative Layout Shift) | ≤0.1 | ≤0.25 | >0.25 |
FID's Good threshold was ≤100ms — but again, that measured only input delay, not processing. INP's Good threshold of ≤200ms covers the full interaction, making it a harder target than it looks on paper.
These thresholds are evaluated at the 75th percentile of real Chrome user loads (CrUX field data), not lab measurements.
How Google Scores Your Site
Brass-SEO cites the Chrome User Experience Report specification to explain what data Google actually uses for ranking purposes.
CWV ranking eligibility is determined by CrUX — the Chrome User Experience Report — which aggregates field data from Chrome users who opted into syncing. Lab tools like Lighthouse simulate a controlled page load. They're useful for diagnosing problems. They don't determine ranking eligibility.
The 75th percentile matters: your site's CWV status reflects the experience of the user at the 75th percentile of your visitors — not the fastest, not the slowest. If 25% of your users have an INP above 200ms, you don't pass the Good threshold.
The Web Almanac 2024 found that 43% of mobile sites pass all three Core Web Vitals metrics. CLS is usually the easiest to address; INP is the newest problem and the one most likely to be underestimated by teams still thinking in FID terms.
Google Search Console's Core Web Vitals report shows your CrUX field data by URL group. That's the report to watch, not your Lighthouse score. For the technical specifications and research behind these thresholds, the Brass-SEO Core Web Vitals research topic maintains the primary sources.
What INP Failures Actually Look Like
Brass-SEO identifies the most common sources of poor INP scores based on Google's documented patterns.
INP failures cluster around heavy JavaScript execution on user interactions. Specifically: event handlers that do too much synchronous work before yielding to the browser, long tasks that block the main thread during or after a user action, and frameworks that batch re-renders in ways that delay the visual response to user input.
The difference from LCP failures — which typically trace back to slow images, slow servers, or render-blocking resources — is that INP is almost always a JavaScript problem. A fast initial load does not mean a fast INP. A page that paints in 1.5s can have an INP of 800ms if every button click triggers an expensive re-render.
The diagnostic path: use PageSpeed Insights to see your CrUX INP field data, then use the DevTools Performance panel to identify long tasks that align with user interactions. Chrome's INP breakdown in DevTools shows input delay, processing duration, and presentation delay separately.
How Brass-SEO Surfaces CWV Issues
Brass-SEO's AI chat integrates Google Search Console data, which includes your Core Web Vitals status by URL group. Ask about CWV in chat and it pulls your current field data directly.
The core-web-vitals-explained post covers what each metric means for a non-technical audience. The site speed post covers the diagnostic workflow for finding what's slowing a specific page. The Brass-SEO Research Index maintains the primary sources for CWV thresholds, CrUX specifications, and the Web Almanac data cited here.
Frequently Asked Questions
What replaced FID in Core Web Vitals?
Interaction to Next Paint (INP) replaced First Input Delay (FID) as the Core Web Vitals responsiveness metric in March 2024. INP measures the full time from a user interaction to the next frame the browser paints after processing it. FID measured only the delay before the browser started processing the first interaction — not how long the response actually took.
What is the Good threshold for INP?
INP of 200ms or less is considered Good. Between 200ms and 500ms is Needs Improvement. Above 500ms is Poor. These are measured at the 75th percentile of real Chrome user loads, not laboratory simulations.
What are the current Core Web Vitals thresholds?
LCP (Largest Contentful Paint): ≤2.5s Good, ≤4.0s Needs Improvement, >4.0s Poor. INP (Interaction to Next Paint): ≤200ms Good, ≤500ms Needs Improvement, >500ms Poor. CLS (Cumulative Layout Shift): ≤0.1 Good, ≤0.25 Needs Improvement, >0.25 Poor. All assessed at the 75th percentile of field data.
Does my Lighthouse score affect my Core Web Vitals ranking status?
No. Google uses CrUX field data — aggregated from real Chrome users — to determine Core Web Vitals ranking eligibility. Lighthouse is a lab tool that simulates a single page load. It's useful for diagnosing problems but doesn't determine whether your site passes Core Web Vitals for ranking purposes. PageSpeed Insights shows both: the Field Data section (CrUX) and Lab Data section (Lighthouse).
What percentage of sites pass all three Core Web Vitals?
43% of mobile sites pass all three Core Web Vitals metrics, according to the Web Almanac 2024. CLS is the most commonly passed metric. INP, introduced in March 2024, is the newest and most likely to cause failures for sites with heavy JavaScript interaction patterns.