First Input Delay (FID) measured responsiveness in Core Web Vitals from 2020 until March 2024, when Google replaced it with Interaction to Next Paint (INP). This wasn't a minor tweak — it was a fundamental change in how Google evaluates page interactivity.
What FID Measured
FID captured one specific moment: the delay between a user's first interaction (click, tap, key press) and the browser starting to process that interaction's event handler.
Key limitations of FID:
- Only the first interaction — A page could lag on every subsequent click and still pass FID
- Only input delay — FID ignored processing time and presentation delay
- Optional metric — If users didn't interact, there was no FID score
- Typically low scores — 93% of sites passed FID's Good threshold, making it uninformative
What INP Measures
INP observes every discrete interaction throughout a page visit — not just the first one. For each interaction, it measures the full lifecycle:
- Input delay: How long before the event handler starts (same as FID)
- Processing time: How long the event handler takes to execute
- Presentation delay: How long until the browser paints the visual result
INP reports the worst interaction (with outlier exclusion for pages with many interactions). This means a page must be responsive throughout the entire session, not just on first load.
Side-by-Side Comparison
| Aspect | FID | INP |
|---|---|---|
| Interactions measured | First only | All |
| Phases captured | Input delay only | Input delay + processing + presentation |
| Reporting | Single event | Worst case across session |
| Good threshold | ≤ 100ms | ≤ 200ms |
| Poor threshold | > 300ms | > 500ms |
| Pass rate (2024) | ~93% of origins | ~65% of origins |
| Core Web Vital | 2020–March 2024 | March 2024–present |
Why Google Made the Switch
FID Was Too Easy to Pass
With 93% of sites passing FID, the metric wasn't differentiating between genuinely responsive sites and those that simply loaded fast initially. Sites with heavy JavaScript that blocked interactions after page load could still score well on FID.
Single Interaction Was Misleading
Users don't interact with a page once. They click buttons, open menus, fill forms, scroll through carousels. FID gave a false sense of security by only measuring the first event.
Processing and Paint Delays Matter
FID measured only the delay before processing started. But a click handler that takes 400ms to execute creates the same perceived sluggishness as a 400ms input delay. INP captures the complete picture.
What Changed for Site Owners
More Sites Fail
The jump from 93% passing FID to roughly 65% passing INP means many sites that were previously "good" are now flagged. If your FID was Good but you haven't checked INP, your Core Web Vitals assessment may have changed.
Different Optimization Targets
FID optimization focused on reducing initial JavaScript execution — defer scripts, reduce main thread work during page load. INP optimization requires attention to:
- Event handler efficiency throughout the page lifecycle
- Third-party script impact on all interactions, not just initial load
- Layout and paint performance after user actions
- JavaScript execution during scroll, click, and type events
Field Data Takes Time
INP is a field metric based on real user data (Chrome User Experience Report). After making optimizations, it takes 28 days for CrUX data to reflect improvements. Lab tools like Lighthouse measure Total Blocking Time (TBT) as a proxy, but field INP is what determines your Core Web Vitals status.
How to Check Your INP Score
Field Data (What Google Uses)
- Google Search Console → Core Web Vitals report → Mobile/Desktop → Interactivity
- PageSpeed Insights → Enter URL → Check "What real users experience" section
- CrUX Dashboard → Historical INP trends per origin
Lab Data (For Debugging)
- Chrome DevTools → Performance panel → Record interaction → Check interaction timing
- Web Vitals Extension → Real-time INP display in browser
- Lighthouse → TBT serves as lab proxy for INP (not exact, but directionally useful)
Migration Checklist: FID to INP
If you optimized for FID and haven't addressed INP:
- Check your current INP score in PageSpeed Insights or Search Console
- Identify worst interactions using the Performance panel in DevTools
- Profile all interactions, not just first load — click every button, open every dropdown
- Audit event handlers for expensive DOM operations and synchronous work
- Test third-party impact by disabling scripts one at a time and measuring INP change
- Implement
scheduler.yield()in long-running handlers to break up work - Monitor field data monthly to track improvement in CrUX
FAQ
Is INP harder to optimize than FID? Yes. INP covers more ground — every interaction, the full processing pipeline, throughout the session. But the techniques are well-understood: break up long tasks, optimize event handlers, manage third-party scripts.
Does INP affect my search rankings? INP is part of Core Web Vitals, which is a confirmed ranking signal. The impact is one factor among many, but failing INP can hurt rankings, especially in competitive SERPs where other signals are similar.
Can I still see my old FID scores? Historical FID data remains in CrUX, but Google no longer uses it for Core Web Vitals assessment. Focus on INP going forward.
What's a realistic target for INP? Under 200ms is Good. Most well-optimized sites achieve 100-150ms. Under 100ms is excellent but not always achievable on JavaScript-heavy applications.