INP measures how quickly your site responds to every user interaction, not just the first click like FID did. Click a button, open a menu, type in a form: the time between that action and the next paint must stay under 200 milliseconds for a good score. The "poor" threshold starts at 500ms.
Why do 43% of sites fail?
Because INP, unlike LCP, can't be solved with better images or CDN caching. It's a JavaScript architecture problem. Every long task that blocks the main thread (third-party scripts, hydration, framework overhead, expensive event handlers) counts. Rendering slot machines you don't see but do feel.
Five concrete fixes
1. Split long tasks
A function that blocks 300ms blocks INP for 300ms. Split them with `await scheduler.yield()` (Chrome 129+) or `setTimeout(fn, 0)`. The browser gets breathing room to handle events in between.
2. Lazy-load third-party scripts
Analytics, chat widgets, A/B test tools, social embeds, they will break INP. Load them with `defer`, `strategy="lazyOnload"` (Next.js), or only after user consent. A chat widget that blocks 250ms costs you more than it returns in 80% of cases.
3. Reduce client-side JavaScript
Server rendering via Next.js, Astro or Remix moves work to the server. Less JS in the bundle = less hydration = fewer INP stalls. React Server Components were built specifically for this.
4. Optimise event handlers
An onChange handler that fetches on every keystroke, or an onScroll that triggers a layout recalc every frame, both INP killers. Debounce, throttle, or use `requestIdleCallback`.
5. Measure field data, not lab data
Lighthouse measures INP synthetically in a simulation. Real users are a different story. Use Chrome User Experience Report (CrUX) or the Performance Observer API to see real-user metrics. That's what Google uses.
When is INP a priority?
Always, but especially if you have an SPA, use a lot of third-party scripts, or have a complex form flow. Brochure sites with static pages hit INP easily; e-commerce checkouts and SaaS dashboards often leak.