What is INP?
INP measures the latency of all interactions a user makes with a page — clicks, taps, and keyboard inputs — and reports the worst-case delay observed across the session. It replaced FID as a Core Web Vitals ranking signal in March 2024.
Google's INP thresholds
Good
≤ 200ms
Needs improvement
200ms – 500ms
Poor
> 500ms
What Interaction to Next Paint (INP) means
Interaction to Next Paint (INP) is Google's responsiveness Core Web Vital. It replaced First Input Delay (FID) in March 2024 because FID only measured the delay of the very first interaction, missing the slow UI responses that happen mid-session — during form completion, checkout steps, or search filter interactions.
INP captures every interaction across the user's entire session and reports the worst-case delay. An 'interaction' is a click, tap, or keyboard event that causes the browser to paint a visible response. The measured time is from when the user initiates the event to when the next frame is painted — encompassing input delay, processing time, and presentation delay.
For React and Next.js applications, INP is particularly challenging because state updates trigger synchronous re-renders. A button click that causes React to reconcile a large component tree can block the main thread for hundreds of milliseconds — long enough to push INP into the 'Needs Improvement' or 'Poor' range and suppress conversion rates on interactive flows.
Common causes of poor INP
- Heavy synchronous React re-renders triggered by click handlers
- Long JavaScript tasks blocking the main thread during interaction processing
- Synchronous DOM reads (offsetHeight, getBoundingClientRect) inside event handlers causing forced reflow
- Heavy third-party scripts competing for the main thread at interaction time
- Large, unvirtualised lists that re-render entirely on filter or sort
- Animations driven by JavaScript instead of CSS transforms
How to improve INP
- Use startTransition to mark non-urgent state updates as low-priority
- Move CPU-bound work to Web Workers to free the main thread
- Replace JavaScript-triggered DOM reads with ResizeObserver / refs
- Virtualise long lists with react-virtual or @tanstack/virtual
- Use CSS transforms and opacity for animations instead of layout-triggering properties
- Profile interactions in Chrome DevTools Performance panel to find specific long tasks
Frequently asked questions about INP
What replaced FID in Core Web Vitals?
INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. FID only captured the delay of the first interaction; INP captures all interactions across the session and reports the worst-case delay.
What is a good INP score?
Google considers an INP score of 200ms or less as 'Good'. Scores between 200ms and 500ms are 'Needs Improvement', and anything above 500ms is 'Poor'. At 500ms+, users notice the lag and may abandon interactions.
Does Lighthouse measure INP?
No. Lighthouse reports Total Blocking Time (TBT) as a proxy for interactivity, but TBT does not directly equal INP. Real INP scores come from field data — actual user interactions captured via the web-vitals library or Real User Monitoring (RUM).
How do I improve INP in a React app?
The primary fixes are: use React 18's startTransition for non-urgent updates, avoid synchronous layout reads inside click handlers, move heavy computation to Web Workers, and virtualise large lists. Use Chrome DevTools' Interaction to Next Paint trace to identify which interactions are slow.
How does AuditJet measure INP?
AuditJet runs automated Google Lighthouse audits that report Total Blocking Time (TBT) — Lighthouse's lab-based proxy for INP. For real-user INP field data, AuditJet surfaces Google PageSpeed Insights CrUX data alongside each audit so you can compare lab and field scores in one place.
Monitor INP continuously.
AuditJet tracks INP across all your pages on a scheduled basis and alerts your team the moment it regresses.