If you are researching first input delay core web vitals in 2026, the most important fact comes first: FID is retired. Google replaced it with Interaction to Next Paint on 12 March 2024, and stopped reporting it in Search Console and the Chrome User Experience Report later that year. Any checklist, dashboard, or agency report still tracking core web vitals fid is measuring something that no longer influences anything.
This is not a cosmetic rename. INP measures a fundamentally larger slice of the interaction experience, and the change surfaced responsiveness problems that FID was structurally incapable of seeing.
What FID Measured
First Input Delay measured the time between a user’s first interaction — a tap, click, or key press — and the moment the browser began processing the event handler for it. That is all. It captured input delay only: how long the input sat in a queue waiting for a busy main thread.
The threshold was 100 milliseconds at the 75th percentile. It was deliberately narrow, because when Core Web Vitals launched in 2020 the browser APIs to measure more than that were not widely available.
The narrowness became the problem. FID stopped its clock the instant processing started. Whatever happened afterward — a 900ms JavaScript handler, a blocking re-render, no visual response for a second and a half — was invisible to the metric. A page could feel unusably sluggish and post a perfect FID score.
Why Almost Every Site Passed It
By 2023, roughly 95 percent of origins passed FID. When nearly everyone passes a metric, it has stopped discriminating and stopped being useful as a signal.
Two design choices inflated those numbers. FID only counted the first interaction, and first interactions often happen after the page has settled, when the main thread is already free. And on pages where the main thread was busy, users frequently waited before tapping — which improved the score by measuring a moment chosen to be favorable.
What INP Measures Instead
Interaction to Next Paint measures the full latency of an interaction, from user input to the next frame painted on screen. It has three components:
- Input delay — waiting for the main thread, which is the only part FID ever measured
- Processing time — running your event handlers
- Presentation delay — the time to recalculate styles, lay out, and paint the resulting frame
It observes every eligible interaction during the page’s lifetime, not just the first, and reports approximately the worst one. On pages with many interactions it uses a high percentile rather than the absolute maximum, so a single outlier does not define your score.
The good threshold is 200 milliseconds or less at the 75th percentile of field data. Between 200 and 500ms needs improvement; above 500ms is poor.
Why Sites That Passed FID Fail INP
The transition exposed a lot of hidden debt. Sites with heavy client-side frameworks, large component re-renders, or third-party scripts attached to interaction events often went from a comfortable FID pass to a clear INP failure without changing a line of code.
Nothing regressed. The old metric was simply not looking at the expensive part. If your handler takes 600ms to run and repaint, FID recorded the 20ms queue wait and called it excellent. INP records the whole 620ms, which is what the user experienced all along.
The usual offenders, in the order I find them: unnecessarily large React or Vue re-renders on a small state change, third-party tag managers and analytics firing synchronously on click, expensive DOM queries inside scroll and input handlers, and enormous single-threaded work triggered by filter or sort controls.
How to Fix INP
The whole discipline is keeping the main thread free and getting a paint on screen fast. Practical moves, roughly by return on effort:
- Yield to the main thread. Break long tasks into chunks with
scheduler.yield()where supported, or asetTimeoutfallback, so the browser can paint between them. - Paint feedback before doing the work. Show the state change — button pressed, row selected — then run the heavy logic on the next frame. Perceived responsiveness is what the metric captures.
- Audit third-party scripts on interaction. Chat widgets, heatmaps, and A/B tools attach handlers you did not write. Defer or remove the ones that are not earning their cost.
- Reduce re-render scope. Memoize, virtualize long lists, and avoid re-rendering an entire page tree for a single input change.
- Keep handlers cheap. No layout-thrashing read/write cycles inside an event handler; batch DOM reads and writes separately.
How to Measure It
INP requires real interactions, so lab tools cannot measure it directly. Lighthouse reports Total Blocking Time as a proxy, which correlates loosely but is not the same thing — a page with low TBT can still have terrible INP if a single common interaction is expensive.
Field data is the only real source. Search Console’s Core Web Vitals report and PageSpeed Insights both show INP from CrUX at the 75th percentile over a trailing 28 days. Bear in mind that low-traffic pages may have no field data at all and will fall back to origin-level numbers.
For faster feedback, use the web-vitals JavaScript library with attribution enabled. It reports not just the INP value but the element and event type responsible, which turns a number into an actionable target. Chrome DevTools’ Performance panel then shows you the long task frame by frame.
Updating Reports and Dashboards Built on FID
The practical cleanup is unglamorous but necessary. Anything built between 2020 and early 2024 probably still references FID somewhere, and stale metrics in a report erode trust in the whole thing.
- Client and internal dashboards pulling FID from the CrUX API will now return empty — the field was removed from the dataset, not merely deprecated.
- CI performance budgets asserting on FID or on a lab FID proxy pass trivially forever. Replace them with Total Blocking Time thresholds and pair them with field INP monitoring.
- Audit templates and checklists that list three metrics as LCP, FID, and CLS need the middle row rewritten, along with the 100ms threshold that goes with it.
- Historical comparisons cannot bridge the change. FID and INP measure different things, so a chart plotting one into the other is meaningless. Start a new series in March 2024 and annotate the break.
Expect the reported numbers to look worse after the switch, and say so before anyone asks. A site that showed a green FID and now shows an amber INP has not degraded — it is being measured properly for the first time. Framing that clearly up front prevents a conversation about a regression that never happened.
Where INP Sits in the Current Set
Core Web Vitals today is LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less — all at the 75th percentile of field data. FID appears in none of them.
Worth keeping perspective: these are real ranking signals, but modest ones, and they will not carry a page past better content and stronger links. The stronger argument for fixing INP is behavioral. A page that responds in 150ms feels solid; one that responds in 600ms feels broken, and users tap again, bounce, or abandon a form.
To keep track of which pages actually need work, look at field and lab numbers together rather than in separate tools. SEO Rocket reports PageSpeed and Core Web Vitals with real-user field data beside the lab metrics, alongside full-site crawls that give concrete evidence per issue. That combination answers the only question worth asking here: is this a problem for real users, on pages that matter?
