🖱️INP and FID: Measuring Page Interactivity
FID has been replaced by INP as the Core Web Vital for responsiveness. Learn what both measure, why INP is harder to optimize, and strategies to reduce interaction delays.
Responsiveness — how quickly a page reacts to user input — is the third Core Web Vital pillar alongside LCP (loading) and CLS (stability). Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the official CWV metric in March 2024.
FID vs INP
| FID | INP | |
|---|---|---|
| Measures | Delay before browser starts processing FIRST interaction | Worst interaction delay throughout the page lifetime |
| Threshold | < 100ms good, > 300ms poor | < 200ms good, > 500ms poor |
| Easy to pass? | Yes — most pages pass | Harder — any heavy JS can cause failure |
| Counts | First click/keypress only | ALL interactions (clicks, keypresses, taps) |
| Status | Deprecated March 2024 | Active CWV metric |
Interaction to Next Paint (INP) (ms)
Why INP Is Hard
INP captures every interaction — not just the first. A user scrolling through a page, clicking multiple buttons, typing in a search box — all of these are measured. If any single interaction takes too long, your INP score suffers. The main culprit is long-running JavaScript blocking the main thread.
Reducing INP
- Break up long tasks (> 50ms) into smaller chunks using setTimeout, requestIdleCallback, or scheduler.yield()
- Minimize JavaScript bundle size — remove unused code (tree shaking)
- Defer or lazy-load non-critical JavaScript
- Avoid heavy synchronous work in event handlers
- Use web workers for CPU-intensive tasks off the main thread
- Avoid layout thrashing: batch DOM reads and writes separately
Analytics, chat widgets, A/B testing tools, and ad scripts frequently cause INP failures because they execute JavaScript on the main thread. Audit your third-party scripts regularly and remove those you don't actively need.