3 November 2026
Your page loads quickly. Why does it still feel slow? A practical INP audit
The page appears quickly, the images look fine and a speed test gives it a respectable score. Then a visitor opens the menu and nothing seems to happen. They tap again. Suddenly the menu opens and closes. That is a responsiveness problem, not necessarily a loading problem.
Interaction to Next Paint, or INP, measures how promptly a page responds to qualifying interactions across a visit. It gives website owners a reason to look beyond the first screen and test what happens when someone actually uses the page.
Know what the number describes
INP considers interactions such as clicks, taps and keyboard input, and the time until the browser paints the next frame in response. It is not a stopwatch for the entire checkout, nor a measurement of every network request that follows a click.
A good INP is 200 milliseconds or less, assessed at the 75th percentile of visits and separately for mobile and desktop. That is not the same as every visitor having the same experience. Device power, competing browser work and the interactions used can all affect the result.
The other Core Web Vitals describe different problems: Largest Contentful Paint concerns loading performance, while Cumulative Layout Shift concerns visual stability. A fast initial load does not guarantee responsive controls.
Begin with real visitors, then reproduce the problem
Look at field data in Search Console's Core Web Vitals report and PageSpeed Insights. Field data describes real-user experience; a laboratory test is a controlled run. They answer related but different questions.
Check whether the reported data is for the exact URL or the wider origin. Low-traffic pages may not have enough data for a page-level result. Missing data is not a pass. Also remember that field reporting reflects a period of visits, so a successful fix will not instantly replace all older observations.
Group the affected pages by template and device. If mobile product filters are troublesome across the shop, prioritise that shared interaction instead of tuning a single demonstration page until its score looks good.
Test the controls people actually use
Make a short list: mobile navigation, search, filters, variant selectors, accordion panels and form controls. Use a realistic device where possible and test after the page has been open for a while, not just immediately after loading.
A developer can then record the problem with browser performance tools or use real-user monitoring to identify slow interactions in the field. A static loading test that never presses the troublesome button will not explain why that button feels slow.
Find which part of the interaction is waiting
The delay may occur before the event handler starts, while its code runs, or before the next frame is displayed. Those are different bottlenecks. Heavy background work can hold up input; an expensive handler can monopolise the main thread; complex rendering can delay the visible response.
Removing an unused plugin might help, but not if the main problem is an unnecessarily expensive filter calculation. Compressing images can improve loading while leaving the interaction untouched. Match the change to the evidence rather than applying the same optimisation list to every slow page.
Prioritise useful fixes
Depending on the diagnosis, fixes can include reducing unnecessary JavaScript, splitting long tasks, avoiding repeated layout work and rendering less content at once. Third-party scripts deserve inspection because they share the browser's resources with your own interface.
Visible feedback matters too. If a search genuinely needs to wait for the server, the interface should acknowledge the action promptly and communicate its state. That does not make the server faster, but it stops the visitor wondering whether their click registered. Test that feedback for accessibility rather than relying only on a visual effect.
Verify the improvement without breaking the journey
Repeat the original interaction and check it still does the right thing. An instantly responding filter that returns incorrect results is not an improvement. Test keyboard use, a slower device and normal browsing conditions alongside the performance recording.
Then monitor field data over time. Keep a record of the release and compare the affected templates and device groups. Do not declare success from one unusually fast run or assume an immediate change in a rolling report.
Will better INP improve rankings?
Google recommends good Core Web Vitals as part of page experience, but good scores do not guarantee top rankings. Relevant, useful content and other search considerations still matter. The strongest reason to remove a slow interaction is that it gets in the way of a real visitor.
For a review that connects technical priorities with the wider site, explore SEO consultancy. If your team needs to understand how to interpret the reports, see SEO training.