How INP differs from FID
FID measured only the input-to-handler-start delay for the first interaction. INP measures the full input-to-paint latency for the worst interaction in the session (technically the 98th percentile). A page where the first click responds in 50ms but every subsequent filter or button takes 400ms passes FID and fails INP.
This is why so many sites that previously passed FID with margin are now failing INP. The underlying performance was always poor; FID just wasn't measuring it.
What 'good' INP looks like
Google's thresholds: under 200ms = good, 200–500ms = needs improvement, over 500ms = poor. The score that affects rankings comes from real-user data in the Chrome User Experience Report (CrUX) — not from Lighthouse. Lighthouse approximates INP using Total Blocking Time (TBT) but cannot measure INP directly because INP requires actual user interactions.
The five most common causes of poor INP
In INP audits across roughly 80 production sites, the same root causes appear repeatedly: long-running JavaScript on the main thread (heavy event handlers, expensive React re-renders), third-party tag bloat (chat widgets, analytics, A/B tools), unoptimised component re-rendering, DOM mutation storms during animations, and hydration cost on SSR/SSG sites.
The single highest-impact fix on most sites is auditing third-party scripts and deferring or removing the ones that aren't business-critical. Each tag adds main-thread work, and the effects are cumulative.