A responsive-looking button can still wait on the browser
Investigate interaction delays where visitors actually click, type or expand content. A page that loads quickly can still respond poorly when scripts block a form interaction.
An interaction may feel slow because the main thread is busy, event handling is expensive or the browser cannot paint the next update promptly. A fast page load does not establish that later interactions are responsive. Investigate the affected click, tap or keyboard action.
A worked example
A hypothetical pricing selector responds slowly while a large third-party script processes work. Removing an unrelated image from the initial page does not address that interaction. A trace of the actual selection can identify the long task or expensive handler blocking feedback.
How to apply it
- Reproduce the problematic interaction on representative hardware and input methods.
- Inspect long tasks, event processing and rendering around the interaction.
- Reduce unnecessary work and verify both prompt feedback and the correct completed action.
What the result can establish
Use INP evidence within its actual collection scope; a single successful click is not a field percentile. Do not make a button appear successful before its underlying save or booking is confirmed. Perceived responsiveness and reliable completion both matter.
Reference: web.dev: optimizing INP.
Supporting documentation
web.dev: optimizing INPGoogle: Core Web VitalsGoogle: technical requirements