The Web Vital That Quietly Replaced FID (And Why Your Old Page Speed Report Is Outdated)

13 October 2026·5 min read

Quick answer: Interaction to Next Paint (INP) officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before your site started responding to a visitor's first click or tap, while INP measures responsiveness across every interaction throughout the whole visit. A good INP score is 200ms or under, 200–500ms needs improvement, and anything over 500ms is poor. If your last speed audit only mentions FID, it's out of date. 📈

If you had a page speed audit done before early 2024, there's a good chance it's quoting a metric that doesn't exist as a Core Web Vital anymore. 💖 We still see agencies handing over reports proudly listing "FID: 45ms, excellent!" as if that settles the responsiveness question — and it doesn't, because FID was always measuring the easiest possible interaction to get right: the very first one, before any of your page's scripts have had a chance to get busy and slow things down.

What most businesses get wrong

The core misunderstanding is thinking Core Web Vitals are a "set once, forget" certificate. Google introduced Core Web Vitals in 2020 with three metrics — Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). In May 2023, Google announced INP as an experimental metric and signalled FID's days were numbered; by March 12, 2024, INP officially took FID's place in the Core Web Vitals set. The reason is straightforward: FID could report a flawless score even on a genuinely janky site, because it only ever measured the delay before the first interaction started being processed — it said nothing about how your site-wide navigation menu, a date picker, or a checkout button behaved for the rest of the visit. A lot of businesses are still being told their site is "fast" based on a metric Google itself stopped using over a year and a half ago.

How to read your current Core Web Vitals report:

Step 1: Open Google Search Console → Core Web Vitals report. Confirm it's showing INP, not FID — if your dashboard or exported report still says FID, it's stale data or an outdated tool.
Step 2: Check your INP score against the actual thresholds: good ≤ 200ms, needs improvement 200–500ms, poor > 500ms. (For reference, FID's old thresholds were good ≤ 100ms and poor > 300ms — don't compare the two numbers directly, they measure different things.)
Step 3: Remember INP is a field metric — it needs real visitor data from the Chrome User Experience Report (CrUX). Low-traffic sites and individual pages often won't have enough data to show a score at all, which isn't a failure, just a data limitation.
Step 4: Use PageSpeed Insights or web.dev/measure for a hybrid view — field data where available, plus lab data using Total Blocking Time (TBT) as the closest lab-available proxy, since INP itself can't be fully simulated in a one-off lab test.
Step 5: Test interaction-heavy pages specifically — forms, filters, checkout, booking calendars — not just your homepage, since that's where INP problems actually live.

A booking-based business with a heavy date-picker widget: FID looked great because the first click (opening the menu) was instant. INP exposed the real problem: selecting a date triggered a slow recalculation that made the calendar visibly lag — exactly the kind of mid-visit friction FID was blind to.

A B2B firm with a long enquiry form and a third-party chat widget: The chat widget's script was quietly hogging the main thread later in the session, making form field inputs feel sluggish right when a prospect was trying to submit — a classic INP-only finding, invisible to FID.

A local service business with a janky mobile menu: The site passed FID easily for years. Once INP became the standard, the mobile hamburger menu's animation turned out to be the single worst-scoring interaction on the whole site, dragging the overall score into "needs improvement."

What's actually driving a bad INP score

INP breaks an interaction into three stages: input delay (time before the browser starts processing the click), processing time (how long your JavaScript takes to respond), and presentation delay (time until the next frame actually paints on screen). Long JavaScript tasks are the usual culprit — heavy third-party scripts (chat widgets, ad tech, certain analytics tags), unoptimised event handlers, and layout thrashing from poorly structured CSS animations. Diagnose it with Chrome DevTools' Performance panel (record a real interaction and look for long tasks), PageSpeed Insights' field data breakdown, and the CrUX dashboard if you want historical trend data across your whole domain.

💡 Field data beats lab data every time for INP. A lab test on a fast office connection will never fully replicate a real visitor on a mid-range phone with patchy mobile data — treat lab scores as a rough guide and field data from actual visitors as the real verdict.

Mistakes to avoid

Trusting any report or tool that's still quoting FID as a live Core Web Vital.
Only testing your homepage instead of your forms, checkout, and interactive pages.
Assuming a low-traffic page has a "bad" score when it may simply have no field data to report.
Fixing LCP and CLS and assuming responsiveness is automatically fine too — it isn't a package deal.
Chasing a perfect lab score while ignoring what real visitor field data is actually showing.

Frequently asked questions

Does INP directly affect my Google rankings?

Core Web Vitals are a confirmed ranking factor, but Google has been consistent that they're a relatively minor one compared to content relevance and quality — more of a tie-breaker between otherwise similar pages than a dominant signal. It's genuinely more valuable for the user experience and conversion impact than for rankings alone, so don't treat it as a silver bullet either way.

What's considered a "good" INP score?

200 milliseconds or under, measured at the 75th percentile of real visitor interactions on your site. Between 200–500ms is "needs improvement," and anything over 500ms is classed as "poor."

Why doesn't my site show an INP score at all?

INP relies on real-user field data from the Chrome User Experience Report, which requires a minimum volume of Chrome traffic to a page before it reports anything. Lower-traffic sites or individual pages often simply won't have enough data yet.

Can I "fix" INP the same way I'd fix image size for LCP?

Partly — reducing heavy third-party scripts and optimising JavaScript helps broadly, but INP issues are often specific to a particular interactive element (a widget, a form, a menu), so it usually takes targeted investigation rather than one blanket fix.

Keep reading 🤍

Written by

Kate, founder of Chronically Online

I help Gold Coast and Brisbane businesses grow with branding, websites and marketing that actually works.

Work with me ✦