A category page loads quickly, then stalls when the customer changes a filter. That is still a slow experience. On March 12, Interaction to Next Paint becomes a Core Web Vital and replaces First Input Delay. The transition gives website teams a clearer reason to inspect what happens during a visit, rather than treating the initial load as the end of performance work.
Update the meaning of the report
INP considers responsiveness across interactions and the time until a subsequent paint. FID focused on the delay before the browser began processing an initial input. A site that looked comfortable against the older metric should not assume the same result describes its later interactions.
Keep comparisons honest when the measurement changes. Record the metric, the collection method and the period represented by the data. A historical FID result and a new INP result answer related but different questions. Presenting them as one uninterrupted trend can make a technical transition look like an unexplained change in the website.
Reproduce a specific slow moment
Choose an action a visitor is likely to perform: changing a product option, opening an account menu, selecting a filter or submitting an enquiry. Follow the complete sequence, including any content or scripts that become active after the first page load. The problem may not occur when the same control is tested in isolation.
Write down what the person sees while waiting. Does the selected option remain visible? Is there feedback that an update is happening? Does the interface accept another action before the earlier one has finished? Those details help distinguish a processing bottleneck from a state-management problem that merely feels similar.
Look for the cause before choosing the remedy
A long task on the browser’s main thread can delay the visible response, but the relevant work may come from different places. Inspect the event handling, subsequent script work and rendering around the interaction. A third-party feature, a broad component update and an expensive calculation need different conversations.
Make a controlled change and repeat the same task. Where real-user data is available, use it to prioritise affected pages and devices. A powerful development computer is not a substitute for examining the circumstances of visitors using less capable phones or a page with additional content loaded.
Keep the improvement tied to a usable result
Avoid solving the measurement by removing the task the customer came to perform. A filter that becomes fast because it no longer updates anything is not a successful optimisation. Preserve the useful behaviour and make its state clear, including error and waiting states.
INP does not replace the need for loading and layout-stability work, nor does it promise a ranking outcome from one fix. It expands the evidence available about the same visitor experience. A good performance review now follows a person from arrival through the interactions that make the website useful, with each reported number attached to the question it actually answers.
