Loading speed and interaction speed are different
A page can display its main content quickly but pause when a visitor opens the menu or changes a product filter. That delay makes the site feel unresponsive even though the initial loading test looked acceptable.
For a service website, try opening a dropdown immediately after the page appears. For a store, change several filters and add an item to the cart. These tests reveal work that a screenshot of the loaded page cannot show.
What INP measures
Google’s web.dev guide explains Interaction to Next Paint, or INP, as a measure of responsiveness across a page visit. It covers qualifying click, tap and keyboard interactions and the delay until the next visual update. A good threshold is 200 milliseconds or less, evaluated at the 75th percentile of visits; above 500 milliseconds is poor.
INP is about feedback after interaction, not a guarantee that a remote operation has completed. A button can quickly show a loading state while a server request continues. That state should remain honest about whether the requested action succeeded.
Investigate one slow action at a time
Write down the precise sequence that feels slow: device, page, control and steps. “The site is laggy” is difficult to reproduce; “the product filter freezes after selecting three categories” gives a developer a useful starting point.
Use browser performance tools to inspect what happens during that action. Heavy JavaScript, large rendering work and other main-thread tasks can contribute. Do not assume the largest image is responsible for every delay.
- Repeat the interaction after the page settles and during initial loading.
- Compare a slower phone with a desktop.
- Check whether a third-party widget changes the result.
- Test repeated actions, not just the first click.
- Retest after the fix using the same steps.
Separate controlled tests from visitor data
A local test is useful for reproducing a problem. Real-visitor measurements show how the site behaves across actual devices and sessions. Record which type of evidence you are using, and do not present one successful desktop run as proof of every visitor’s experience.
During a development review, prioritise frequently used actions with visible delays. Keep success messages tied to completed operations and use clear progress feedback for work that takes time. The goal is a dependable interaction, not simply a better-looking score.