Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. Over a year later, a significant number of sites still haven't fully audited their INP performance — and some are paying for it in rankings.
FID measured the delay before a browser began responding to the first user interaction. It only measured delay, not processing time, and only captured the first interaction. INP measures all interactions throughout the page session, taking the worst-case response time as the score.
The threshold for a "Good" INP is 200ms — from tap or click to the next frame painted, no more than 200 milliseconds. "Needs Improvement" runs from 200–500ms. Anything above 500ms is "Poor." This is significantly stricter than what most sites were previously optimized for.
In practice, INP issues cluster around a handful of root causes. Long JavaScript tasks that block the main thread are the most common offender — particularly event handlers that do too much synchronous work. Other frequent causes include:
Chrome DevTools' Performance panel now has INP-specific tooling. Use the "Interactions" track to identify which user interactions are slow, then drill into the flame chart to find what's blocking the response. The Long Animation Frames API, available in Chrome 123+, gives programmatic access to frames that took longer than 50ms to render.
For quick wins: load non-essential third-party scripts with defer, use useDeferredValue or startTransition for non-urgent React state updates, and break long synchronous tasks with scheduler.yield() where supported. For field data, check your Core Web Vitals report in Search Console — CrUX data aggregates over 28 days, so changes you make today won't appear in rankings data for about a month.
Most sites treat internal linking as an afterthought. The sites that grow fastest treat it as infrastructure — a deliberate system for distributing authority and guiding crawlers.
