A page passed its lab performance review and still felt broken to real users. The hero appeared quickly and the layout stayed still. The slow moment came later, when opening a filter after the application had hydrated and several third-party scripts had started their own work. The click waited behind a busy main thread.
That is why INP is the Core Web Vital that catches otherwise polished builds. Loading can look finished while interaction capacity is already spent.
INP measures the wait for visible response
Interaction to Next Paint follows clicks, taps and keyboard interactions across the page visit. It includes the delay before an event handler starts, the handler's work and the presentation delay until the browser can paint the result. The official INP guidance explains that the reported value represents the slowest interaction, with outlier handling for highly interactive pages.
Google's current guidance classifies an INP of 200 milliseconds or less as good at the relevant field percentile, as documented in its optimization guide. That figure is a field target, not permission to ignore a reproducible slow control in the lab. A single painful checkout or navigation interaction still deserves repair.
Long tasks create input delay
The browser's main thread can only execute one task at a time. If JavaScript is parsing, evaluating or running when input arrives, the interaction waits. Large state updates, synchronous data transforms, expensive component trees and several small tasks scheduled back to back can all occupy the gap before the event handler.
The web.dev guide to optimizing long tasks describes yielding so higher-priority work, including interaction, can run sooner. The practical fix is not to scatter timers blindly. Reduce the work, split what remains, and yield at boundaries where partially completed state is safe.
Profile the actual slow interaction. A long task elsewhere on the timeline may be irrelevant.
Hydration moves the problem after first paint
Server rendering can produce a quick visual result while the client still has to load, parse and hydrate a large component tree. Users can see a control before the main thread is ready to respond. If hydration also triggers effects, data normalisation or layout measurement, an early interaction competes with startup work.
Keep static regions outside unnecessary client boundaries. Hydrate interactive islands deliberately. Avoid rebuilding large state from browser storage during the first input window. Test clicks during load, not only after the network becomes idle.
A small bundle is useful, but execution shape matters. A compressed script can still produce one dense block of main-thread work.
Third-party scripts share the same thread
Consent managers, analytics, chat widgets, experimentation and advertising code do not live in a separate performance budget. Async loading changes when they arrive, not necessarily how much main-thread work they perform. The web.dev field debugging guidance recommends capturing the target element, interaction type and timing so field regressions can be traced to the surrounding work.
Give every third party an owner and a measured purpose. Delay nonessential code, remove duplicate tags, and retest after vendor updates. A script that cannot be profiled or disabled is an operational risk.
Find the interaction that bites this week
Start with field data and identify the elements associated with slow INP. Segment load-time interactions from later ones, and mobile from desktop. Reproduce the same action under CPU pressure with production scripts enabled.
Record input delay, handler duration and presentation delay separately. Remove third parties in controlled runs, narrow hydration boundaries, and break the confirmed long task. Then remeasure in the field.
Do not begin by chasing a generic score. Begin with the click that did not answer. INP improves when the main thread has room to acknowledge real intent, not when the page merely finishes looking loaded.