Why Does My Website Respond Slowly to Clicks? How to Improve INP
Find out why a website feels slow after clicks or taps, what INP measures, and how to test improvements to menus, forms and other interactions.
Part of our guide: The Complete Guide to Website Speed for Business Owners
A website can load quickly and still feel slow when someone opens a menu, selects a filter or presses a button. Interaction to Next Paint, or INP, measures responsiveness by looking at the delay from an interaction to the next visual update.
It does not measure the full time taken for a remote booking or payment to complete. Google’s INP documentation describes a good result as 200 milliseconds or less at the 75th percentile of visits. Scrolling and hovering are not the click, tap or keyboard interactions this metric assesses.
Start with a reproducible customer action
“Sometimes the site is slow” is difficult to investigate. A better report is: “On the service page, the mobile menu takes a noticeable moment to open after the first tap.”
Record the device, browser, page and steps. Note whether the delay happens every time, only on the first visit or after accepting a particular integration.
Do not test only an administrator’s fast laptop. A modest phone with a busy page may reveal problems the office setup hides.
Why can a click wait?
The browser may already be occupied before it handles the interaction. The interaction’s own code may take too long. Or the browser may need substantial work before it can display the resulting change.
The INP optimisation guide separates these phases. Useful improvements can include reducing unnecessary script work, breaking up long tasks and simplifying what an interaction updates.
These are development decisions, not a reason to remove important customer functionality blindly. The goal is a responsive page that still does its job.
Build an interaction test checklist
Choose the actions that matter on your website.
| Journey | Action to test | Expected visible response |
|---|---|---|
| Find a service | Open the mobile menu | Menu appears promptly and remains usable |
| Narrow options | Change a filter | Selection is acknowledged clearly |
| Ask a question | Expand an answer | Relevant content opens without a long pause |
| Send an enquiry | Submit the form | Clear progress, error or confirmation state |
| Make a booking | Select a date | Selection appears and unavailable states are clear |
Also test keyboard operation. Record failures in plain language and, where possible, capture a short recording without customer information.
For forms, distinguish an unresponsive button from a slow server response. Both can frustrate users, but they require different fixes.
Investigate integrations without guessing
Chat widgets, review tools, analytics and other embedded services can contribute work. Their mere presence does not prove they caused the delay.
Use a safe test environment to compare a controlled change. Disable or replace one non-essential integration, repeat the same action and record the difference. Keep required consent, accessibility and customer-service functions working.
Our guide to why mobile website speed matters helps keep the investigation focused on customer experience rather than removing everything interactive.
If a third-party tool is essential, ask whether it can load at a more appropriate time or update less of the page. Check the provider’s current integration guidance rather than adding an unrelated optimisation plugin.
Avoid misleading comparisons
A laboratory test may help identify blocking work, but a different metric such as Total Blocking Time is not an interchangeable INP measurement. Label what the report actually measured.
Compare the same journey under similar conditions and repeat it. Save the original result before changing the page. If an improvement appears only once, investigate before declaring success.
Watch for side effects: a menu that opens faster but traps keyboard focus is not a successful fix. Neither is a form that instantly appears to succeed while silently losing the submission.
Give the developer a useful brief
Include the troublesome interaction, affected pages, test device, expected behaviour and evidence. Ask for a proposed cause, a small change and a re-test.
A practical acceptance statement is: “Customers can open the menu, select a service and submit the enquiry form without unexplained pauses, with clear feedback while requests complete.” Pair that with the relevant measured results rather than promising a universal score.
Check the rest of the experience
Responsiveness belongs alongside loading and stability in the Core Web Vitals guide. Use the website speed guide for the broader diagnosis, including free performance-testing tools.
Reducing unnecessary work may also complement lighter media and page design. Check that each change helps someone complete the task they came to do.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
