INP (Interaction to Next Paint)

For every user interaction on a page during a session, the browser records the interaction latency: the time from the input event to the next paint reflecting a visual update in response. Because a session can involve many interactions, INP reports a high percentile of these latencies (effectively the near-worst-case) rather than an average, since a single slow, frustrating interaction meaningfully damages the perceived quality of a page even if most interactions were fast.

Interaction latency itself breaks into three phases: input delay (time before the browser starts processing, often due to main-thread congestion from other running scripts), processing time (the actual work triggered by the event handler), and presentation delay (time to render and paint the resulting frame). A poor INP score can stem from any one of the three, which is why diagnosis has to isolate which phase is actually the bottleneck before attempting a fix.

As click volume shrinks on informational queries due to AI Overviews, the traffic that does convert into a click is disproportionately higher-intent — someone about to fill out a quote form or tap to call. A janky, unresponsive interaction at exactly that moment is a direct conversion cost, arguably more consequential now than when INP was introduced, even though the ranking weight of Core Web Vitals hasn't changed dramatically.

Start with the field data in Search Console's Core Web Vitals report or the CrUX dashboard to confirm INP is genuinely failing at the URL-group level, then use Chrome DevTools' Performance panel or the web-vitals JavaScript library to capture specific slow interactions in the field or in a realistic manual test.

Look specifically at long tasks on the main thread around the time of the interaction — anything over 50ms blocks the browser from responding promptly to input — and identify which script triggered them using the DevTools flame chart or a Real User Monitoring (RUM) tool with attribution.

Third-party scripts — chat widgets, analytics tags, ad-tech pixels — are the single most common culprit, frequently running expensive work in response to interactions the site owner never directly authored or reviewed.

Large client-side re-renders in React or similar frameworks are the second most common cause: a component tree that re-renders far more of the page than the interaction actually requires, often due to state management that doesn't scope updates narrowly enough.

Unthrottled or unnecessarily complex event handlers — scroll or input listeners doing heavy synchronous work — round out the most frequent causes.

Identify the specific interactions and pages driving the p75 INP failure using field data and RUM attribution, rather than guessing from a general site-wide audit.

Audit and defer or remove non-essential third-party scripts, loading them after first interaction or on a lower-priority schedule where the business requirement allows it.

Break up long JavaScript tasks using techniques like `scheduler.yield()` or manual chunking, so the main thread can respond to input between chunks rather than blocking until an entire task finishes.

Scope client-side re-renders narrowly — memoise components, avoid unnecessary state propagation, and profile with React DevTools or the framework's equivalent to confirm re-render size actually shrank.

Re-measure using field data over a full 28-day CrUX window before declaring the fix successful, since lab tests can look improved without the field percentile actually moving.

Local sites commonly stack a booking widget, a chat tool, a review-collection script, and several analytics tags on every page — each individually reasonable, but collectively often responsible for the bulk of an INP failure. A quarterly third-party script audit is disproportionately effective for these sites relative to custom development work.

INP is one of the three metrics comprising Core Web Vitals, alongside LCP (loading speed) and CLS (visual stability); a page can pass all three, fail just one, or fail multiple simultaneously, and each requires a distinct diagnostic and fix approach rather than a single generic 'speed up the site' effort.