A good Lighthouse performance score does not establish that every menu, filter or checkout action responds quickly. Loading a page and interacting with it exercise different work. If a visitor reports a slow click, reproduce that action instead of treating the loading score as its measurement.
Identify which result you are reading
PageSpeed Insights can show field data and a Lighthouse lab report on the same screen. Keep them separate. Field INP describes recorded user experience for a reporting window. A lab loading score describes that test run and does not reproduce every later interaction.
Record the page, device, test conditions and exact action. Note whether you clicked while the page was loading or after it settled. Use Speed Scanner for loading diagnostics and INP Scanner to investigate interactions. Neither a single fast run nor a single slow action establishes the field result for all visitors.
Reproduce the complaint as a short scenario
Write a concrete sequence: open the catalogue, type into the filter, expand a product and add it to the cart. Test it first on the device type where the problem occurs. Record whether the delay happens on the first use, after repeated use or only with a particular set of data.
Run the same scenario again before changing code. An unrelated request, an extension or a one-time cache state can make a single observation misleading. Keep failures and incomplete runs separate from successful measurements.
A visible status can still wait for a paint
This teaching example deliberately blocks the main thread after a button is clicked. The 400 ms value is an artificial delay, not an observed customer result.
<button id="run" type="button">Run</button>
<p id="result" role="status"></p>
<script>
const button = document.querySelector('#run');
const output = document.querySelector('#result');
button.addEventListener('click', () => {
output.textContent = 'Working';
const end = performance.now() + 400;
while (performance.now() < end) {
// Artificial work for this example only.
}
output.textContent = 'Done';
});
</script>
Assigning Working to the DOM does not force the browser to paint it before the synchronous work finishes. A small downloaded script can therefore produce an unpleasant interaction. Download size alone does not identify this cause.
Inspect the work around the action
Record the scenario in the Performance panel. Look at work already occupying the main thread before the event, the event handler and the rendering that follows it. These are different places to investigate. The INP optimization guide describes the corresponding interaction phases.
Do not assume that every long interval belongs to the clicked button. A shared listener, data transformation, unrelated task or a large rendering update can contribute. Follow the trace to the responsible code. The guide to INP and JavaScript message queues explains why work scheduled around an event matters.
Make one change and repeat the scenario
Choose a confirmed cause. Remove unnecessary work, reduce the affected data or split work where the application permits it. Moving work to a timer or another callback is not by itself proof that the interface became responsive. The browser still needs an opportunity to present the useful update.
Repeat the same scenario under comparable conditions and check that the feature still works. Compare the interaction trace as well as loading behaviour. If you deferred code, verify the first use of that feature too; it may have become slower even if initial loading improved.
For a recurring issue, retain the scenario and monitor the published page. Use field data to check how the change affects actual visitors over time. Investigate an interaction with Milten, then repeat the specific action reported by the visitor.