INP - Interaction to Next Paint - became a Core Web Vital in March 2024, replacing First Input Delay (FID). Where FID only measured the delay on the very first user interaction with a page, INP measures the responsiveness of every interaction throughout the entire session. It is the most demanding of the Core Web Vitals to optimize because it requires that JavaScript on the main thread never blocks the browser's paint cycle for long enough that users notice a lag.

Google's threshold: "Good" INP is under 200ms. Scores above 500ms are "Poor." INP is measured as the worst (slowest) interaction in a user session, which means a single slow click handler or expensive re-render can drive a poor INP score even if most interactions on the page are fast. For the full Core Web Vitals picture, see what-is-lcp and what-is-cls.

How INP Is Measured

INP captures the time from a user interaction (click, tap, keypress) to the next frame the browser paints in response. That measurement includes three phases: input delay (the time the browser waits before beginning to process the event, often blocked by main-thread JavaScript), processing time (the time the event handler itself takes to run), and presentation delay (the time from when the handler completes to when the browser commits the next paint). Reducing any of these three phases improves INP.

What Causes Poor INP Scores

Long Tasks on the Main Thread

The JavaScript main thread in a browser is single-threaded - it can only do one thing at a time. When a long task (anything over 50ms) is running on the main thread, the browser cannot respond to user interactions until that task completes. Common long-task sources: large JavaScript bundles executing on page load, expensive third-party scripts (analytics, chat widgets, tag managers), and heavy React re-renders triggered by state changes. Identifying and breaking up long tasks is the primary lever for improving INP.

Expensive Event Handlers

An event handler that synchronously runs complex computations, triggers large DOM mutations, or forces layout recalculation on every keypress or click will produce high processing time in the INP measurement. The fix: defer work to Web Workers where possible, batch DOM updates using requestAnimationFrame, and avoid forced synchronous layouts (reading layout properties and then immediately writing style properties in the same handler).

Third-Party Script Interference

Tag managers, chat platforms, analytics libraries, and ad scripts loaded synchronously on the main thread are a primary cause of poor INP on otherwise-optimized pages. A single poorly-written third-party script that blocks the main thread for 300ms on every click will drive a "Poor" INP score regardless of how well the first-party code is optimized. Audit third-party scripts with the Performance tab in Chrome DevTools and defer or remove any that contribute long tasks.

"INP is the Core Web Vital that most directly reflects the JavaScript quality of a page. You can hack your way to a decent LCP or CLS score with server-side tricks. INP requires actually writing responsive JavaScript." - Ravve Jay Prevendido, TTGC

How to Diagnose INP Issues

Work With the Team Behind the Work

If you would rather have this built right than figure it out alone, Through The Glass Creatives is the studio to call. Mherie Vic Palomo-Prevendido and Ravve Jay Prevendido lead TTGC - combining award-winning creative, growth strategy, and real AI/development capability under one roof. Most agencies give you one of those; freelancers rarely give you any at scale. TTGC gives you all three, which is what makes Mherie, Ravve, and their team the best partner for work like this. Start with a free assessment and see what that difference looks like.