A customer taps your mobile menu and nothing seems to happen. They tap again, then the menu opens and closes. Or a product filter leaves the page frozen before the results change. The website may look quick when it first loads, yet feel slow when someone tries to use it.
Start with the exact action that stalls. Interaction to Next Paint, usually shortened to INP, can help diagnose delayed browser responses. It will not explain every failed button or every slow request. The useful outcome is a customer journey that responds clearly and finishes correctly.
What INP measures, and what it leaves out
Google’s INP guidance describes a responsiveness metric covering clicks, taps and keyboard interactions throughout a page visit. It measures the delay until the browser can paint the next frame, rather than the complete duration of a later network request. For most visits, the slowest qualifying interaction determines INP, with adjustments for visits containing many interactions.
The recommended thresholds are:
- Good: 200 milliseconds or less.
- Needs improvement: above 200 milliseconds and up to 500 milliseconds.
- Poor: above 500 milliseconds.
Assess these at the 75th percentile of visits, separating mobile and desktop. Scrolling and hovering alone do not count as INP interactions.
For your business, separate three observations. Does the control respond visually? Does the requested work complete? Does the result reach the right place? A booking button can show progress promptly while availability takes longer to arrive. A form can feel responsive while its enquiry never reaches your team. Record each problem separately so the repair addresses the actual failure.
Reproduce the customer’s action before changing anything
Choose a journey that matters commercially: opening navigation to reach a service, changing a product option, applying a filter, starting a booking or submitting a quote request. Use a real phone as well as your usual desktop. Check the reported browser where possible.
Write a short, repeatable test:
- Record the page URL, phone model and browser.
- Describe the route to the page and the control you used.
- Try the action soon after the page appears, then again after it has settled.
- Note whether there is an immediate visual response, a delayed response or no response.
- Record whether the action eventually completes and whether another tap changes the outcome.
For example: open the services page on a phone, tap the menu once as soon as the page appears, then note when it opens. This gives a developer something more useful than “the mobile website feels slow”. A short screen recording can make the symptom easier to recognise.
Repeat with the relevant cookie choices and signed-in state recorded. If the delay appears only after optional integrations load, that is a useful lead for investigation. It is not proof that a particular tool caused it.
If a control never works, ask the developer to check its behaviour and errors alongside performance. Treat incorrect links, disabled controls and obstructing overlays as separate possibilities. A responsiveness score cannot prove that the button does its intended job.
Read the right part of PageSpeed Insights
PageSpeed Insights separates real-user data from lab diagnostics. Its Chrome User Experience Report data covers a trailing 28-day period. Check whether the report describes the individual URL or the whole origin: when a page has insufficient data, the tool can fall back to a broader website view.
Record the mobile INP result, its collection period and its scope. An origin-level warning does not identify your enquiry page as the culprit. Missing real-user data does not prove the page is fast; there may simply be too few eligible samples.
A good Lighthouse loading score is also insufficient evidence that your menu, filter or form responds well. The standard loading test and real customer interactions answer different questions.
Use the report to decide where to investigate, then return to the action you can reproduce. Keep a copy of the starting result so you can compare like with like after the repair. Avoid comparing a mobile URL result before the change with a desktop origin result afterwards.
Ask your developer to record the delayed interaction
The next step is a performance recording made while using the affected control. Chrome’s Performance panel documentation explains how to record interactions and inspect the Interactions track. It exposes input delay, processing time and presentation delay, and flags interactions longer than 200 milliseconds.
Ask the developer to capture the same sequence that caused the complaint, including the early tap if it happens during loading. The recording should identify the delayed interaction and the work around it, rather than provide only a screenshot of an overall score.
Agree a small evidence pack: the reproduction steps, test device or throttling conditions, relevant trace and proposed cause. If the problem cannot be reproduced, keep that uncertainty visible and test the original conditions again. Do not turn an unsuccessful reproduction into a declaration that customers have no problem.
Find which part of the response is slow
Chrome’s INP breakdown guidance separates three phases. High input delay indicates that other browser work held up the interaction. High processing duration points to the interaction’s event handlers. High presentation delay indicates that rendering delayed the result after those handlers ran. Focus the repair on the slowest phase.
The browser is busy before it handles the tap
Ask what was running immediately before the control could respond. Was the delay specific to initial loading, or did it happen repeatedly later? Have the developer identify the relevant script or task rather than assume your hosting package is the answer.
Start with the smallest evidenced change. If a feature is unnecessary on that page, consider removing it there. If it is necessary, discuss when its work can run without obstructing the customer’s next action. Preserve the behaviour that the business still needs.
The action itself does too much work
A filter, option selector or validation routine may be the place to investigate when processing dominates. Google’s guidance on long tasks explains that the browser’s main thread handles one task at a time. Tasks exceeding 50 milliseconds are classed as long tasks; splitting suitable work into smaller tasks can give the browser opportunities to respond between them.
Ask what the customer needs immediately and what can safely happen later. The developer should preserve the order and correctness of the work. Moving code around without checking the result can produce a faster response followed by an incorrect price, missing validation or incomplete update.
The browser takes too long to display the change
Google’s layout guidance explains how large layouts and repeated forced layout calculations can increase interaction latency. A developer can inspect rendering work and avoid repeatedly alternating layout reads with style changes.
If this phase dominates, discuss the affected component rather than immediately redesigning the whole website. Request an explanation of which layout work changed and why. Check that the result still fits a small screen, remains readable and preserves the intended navigation.
Give customers clear feedback while work continues
Review the visible response as part of the fix. For a genuine operation in progress, an appropriate busy state should make that clear. Success should appear only when the operation has succeeded, and a failure should leave the customer with a usable next step.
Do not accept a cosmetic improvement that merely hides the waiting. Test what happens if the request fails, takes longer than expected or the person taps again. For enquiry and checkout journeys, verify the resulting record as well as the screen.
These details belong in the acceptance criteria for website development work. Define the expected response, completed outcome and recovery behaviour before signing off the change.
Verify the repair immediately, then monitor real-user data
Run the original journey again under comparable conditions. Test the first interaction and later interactions, the affected phone, the relevant consent choices and the neighbouring controls. Confirm that an enquiry reaches its destination or that a basket contains the intended product and quantity.
Ask for before-and-after recordings that show the delayed phase has improved. Record the release date and retain the reproduction steps. Because PageSpeed’s field data uses a rolling collection period, an immediate re-run can still contain experiences from before the release. Use local evidence for immediate verification, then monitor the comparable field result as newer visits accumulate.
Keep commercial reporting separate from the performance result. If completed enquiries or orders change, compare a suitable period and consider changes in traffic, campaigns and demand before attributing the difference to this repair.
Google confirms that Core Web Vitals are used by its ranking systems, but good scores do not guarantee top rankings. Prioritise the interactions customers need to complete over pursuing a perfect score.
Start with the control that blocks the next step
A focused investigation should leave you with a reproducible symptom, an identified cause and evidence that the repaired journey works. When the problem involves both layout and behaviour, review mobile website usability alongside the technical fix.
If your mobile menu, filters or enquiry buttons feel delayed, talk to BuzzBoost about the affected journey. Share the page, device and action that stalls so we can discuss a practical next step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
