Your Website Loads Fast, but Buttons Respond Slowly—How to Diagnose INP

1 day ago

6 min read

The homepage appears quickly. The images are visible. Then a visitor taps the menu and nothing seems to happen. They tap again, the menu finally opens, and the page suddenly feels unreliable.

A website button click delay often begins after the page has loaded: JavaScript is busy, a click handler does too much work, or the browser takes too long to draw the updated interface. Interaction to Next Paint, or INP, helps measure that responsiveness. This guide shows how to locate the delayed interaction, identify the responsible work, and verify a fix without relying on a single speed score.

What INP measures—and what it leaves out

INP measures the time between a qualifying user interaction and the browser’s next visual update. It considers clicks, taps, and keyboard interactions across a visit. It generally reflects the slowest interaction, with adjustments for outliers on pages with many interactions. Scrolling and hovering are not included.

Google defines a good INP as 200 milliseconds or less. Values above 200 and up to 500 milliseconds need improvement; above 500 milliseconds is poor. Assess the 75th percentile of visits, separating mobile and desktop. These are experience thresholds, not a promise of higher rankings.

INP does not time the entire business operation. A button can paint a loading indicator promptly while a server takes several seconds to return a quote. That interaction may have a good INP even though the overall wait needs attention. Record both the first visible response and the final outcome. Google’s explanation of Interaction to Next Paint.

Why a fast-loading page can still respond slowly

Loading, responsiveness, and visual stability describe different parts of the experience. A lightweight hero image helps a visitor see the page sooner, but cannot prevent an expensive product filter from freezing the interface later.

A standard Lighthouse navigation test does not reproduce every menu opening, form edit, or cart interaction. Total Blocking Time can reveal busy work during loading, but it is not a substitute for INP measured across real visits. For the wider measurement context, read our guide to a good PageSpeed score with a slow real-world experience. Why a good PageSpeed score can hide a slow visitor experience.

1. Identify the exact action that feels delayed

Start with one reproducible task. “The site is slow” is too broad to investigate. “The mobile menu takes a moment to open when tapped immediately after landing” gives you a test you can repeat.

Record the page URL, device, browser, and the control being used.
Note whether the delay happens during loading, after the page settles, or only on the first interaction.
Test the logged-out customer experience and the relevant cookie-consent state.
Compare the first attempt with later attempts; a widget may download or initialize only once.
Check whether the control eventually works, produces an error, or never responds.

If the button never works, inspect JavaScript errors, overlays, disabled states, and the network request before calling it an INP problem. An unbound click handler or a failed checkout request needs a functional repair.

2. Check field data, then reproduce the delay

Look for INP in the real-user section of PageSpeed Insights and the Core Web Vitals report in Search Console. Check whether the result describes the specific URL or the wider origin. A small site may not have enough eligible Chrome data; missing data does not establish that the site is fast.

If available, use real-user monitoring to identify the affected page template, device group, and interaction. Then reproduce that journey locally. Without field data, begin with the actions that matter most: opening navigation, choosing a product option, filtering results, or submitting a lead form.

Record one interaction in Chrome DevTools

Open the affected page in a clean browser profile with extensions disabled.
Open DevTools and select the Performance panel.
Use its live interaction information to try the suspected control.
Start a recording, perform the action once, and stop the recording.
Select the interaction in the trace and inspect its timing alongside the main-thread work.
Repeat under the same conditions, including an early click during loading.

Use CPU throttling to expose work that a powerful laptop hides, and validate on a real phone where possible. Throttling helps reproduce a problem; it does not produce an exact prediction for every customer’s device. Save the baseline trace before making changes. Chrome Performance panel reference.

3. Match the fix to the longest part of the interaction

An interaction has three timing components. The largest component is a useful starting point, although more than one may need work.

Input delay: the browser is busy before your handler starts

Look for activity already running when the visitor clicks. Tag-manager scripts, widget initialization, timers, and other JavaScript can occupy the main thread before the click handler gets a turn.

In a test environment, disable one suspected integration and repeat the same action. If the delay changes consistently, investigate that integration’s loading scope and behavior. A chat widget needed on a contact page may not need to initialize on every article. Preserve required consent controls and measurement while testing.

Processing duration: the handler does too much

A filter button might calculate results, rebuild a large list, update counters, and run analytics before the browser can show a response. Reduce the work required for the immediate update and separate nonessential processing into later tasks.

For custom code, a developer can split long tasks and yield control to the browser. Moving heavy computation to a worker can help where the task does not require direct DOM access. Simply wrapping expensive work in an async function does not automatically move it off the main thread. How to break up long JavaScript tasks.

Presentation delay: the new interface takes too long to draw

When handlers finish quickly but the screen responds late, inspect style calculation, layout, and paint. A filter that changes hundreds of cards or a menu that triggers page-wide layout work can be costly.

Reduce unnecessary elements and updates. Batch layout reads and writes instead of repeatedly changing styles and immediately measuring the result. Simplify the affected component before adding another optimisation layer. If elements also jump unexpectedly, use our separate layout-shift diagnostic. Google’s layout and rendering guidance. Find and fix unexpected layout shifts.

An example: a mobile menu that opens late

Consider this illustrative test—not a measured Webcurry case study. The menu opens promptly after ten seconds, but hesitates when tapped as soon as it becomes visible. A trace shows widget initialization running before the menu handler starts.

The practical experiment is to remove that widget from a test copy and repeat the early tap. If the delay disappears across repeated runs, the next step is to reduce or reschedule the widget’s work while keeping navigation ready. Changing the menu’s colours or compressing its icon would not address the recorded bottleneck.

Now imagine a different trace: the menu handler begins immediately, but generates a large navigation tree on each click. That needs a component-level fix. The same visible symptom can have different causes, which is why the trace should guide the repair.

Platform-specific checks

Wix: review apps, custom code, and page complexity

Test the published visitor experience. Review third-party apps and custom code associated with the affected page, then simplify the interactive section in a test copy. Wix’s Core Web Vitals guidance includes reducing unnecessary third-party code and simplifying pages. If you cannot edit the responsible platform code, capture the URL, device, reproduction steps, and trace for support. Wix’s Core Web Vitals guidance.

WordPress: isolate the theme or plugin responsible

Use staging to compare the interaction with the suspected plugin disabled or with a simpler component. Check overlapping optimisation plugins and settings that delay JavaScript until the first click. That first click may be triggering a backlog of work.

For custom development, WordPress supports script-loading strategies through its enqueue functions and accounts for dependencies. Choose changes deliberately: defer controls when a script executes during loading; it does not make an expensive click handler faster. Retest menus, forms, and checkout after changing execution order. WordPress script-loading reference.

Shopify: test theme code and app additions

Work in a duplicate theme when testing theme changes. Compare product variants, collection filters, cart drawers, and app blocks. Shopify recommends reducing JavaScript and loading functionality when needed. Remove redundant theme features or app embeds only after confirming their purpose and testing the affected customer journey.

An app may have settings that affect the live store even while you preview another theme. Check the scope before changing shared configuration, and avoid testing real charges as part of performance debugging. Shopify theme performance guidance.

Verify responsiveness and successful completion

Retest the exact action under the original conditions after each change. Compare several recordings, including the first interaction, later interactions, and a slower device. Keep a short record of the changed component, the timing breakdown, and whether the customer task still completes.

Give visitors immediate, truthful feedback for asynchronous work: a loading state, progress message, or clearly disabled submit control where appropriate. Do not show success before the server confirms it. Preventing duplicate submissions matters as much as making the interface appear responsive.

Field reports take time to reflect new visits. A better local trace is evidence that the tested interaction improved; continue monitoring real-user INP and task completion. For lead-generation sites, connect this check with a wider conversion audit. Audit a website that gets traffic but no enquiries.

Make the next tap feel dependable

Fixing a website button click delay starts with the visitor’s action. Reproduce it, record it, locate the longest phase, and change the work responsible. A fast homepage and a responsive interface deserve separate checks.

If a menu, form, or product control is losing visitors, share the affected URL and the steps that trigger the delay with Webcurry. That gives a performance review a concrete starting point and a clear test for success. Request a Webcurry performance review.