When checkout taps feel slow: diagnose INP before changing the page

Describe the customer symptom precisely

A shopper taps ‘Continue’ at checkout and nothing visible seems to happen. That complaint can describe several different waits: the browser may be busy before it handles the tap, the tap handler may run too much code, the page may take time to draw a new state, or a payment request may be waiting on the network. Treat these as separate hypotheses. Interaction to Next Paint, or INP, measures how quickly the page provides the next painted response to qualifying interactions during a visit. It is not a timer for completion of a payment or delivery of an order email. A checkout can paint a prompt ‘Processing’ state and still take longer to receive payment confirmation. Conversely, a fast payment service cannot make a frozen button feel responsive. The first task is to identify which wait the customer actually experiences.

Google’s web performance guidance rates INP of 200 milliseconds or less as good, over 500 milliseconds as poor, and the range between as needing improvement. It recommends assessing the 75th percentile separately for mobile and desktop page loads. Those are metric boundaries, not a promise that every tap will finish in 200 milliseconds. A small shop should avoid claiming its checkout is fast based only on one office laptop or a single automated score. A shop with a low number of visits may have too little field data to classify reliably. In that case, use reproducible device and network tests to locate problems, while labelling the conclusion as a test finding rather than a measured population result.

Find the slow interaction in real use

Begin with the checkout step, device class, browser and action reported by the customer. A page-wide INP number alone does not tell you whether the slow interaction was a delivery-option selector, an address field, a coupon button or the final submission control. If the site already has suitable real-user measurement, inspect the interaction target and timing breakdown, and compare affected mobile visits with ordinary visits. Google’s field diagnosis guide describes attribution data for input delay, processing duration and presentation delay. Collect only the technical context needed to diagnose the problem; do not attach names, card details, addresses or typed form contents to performance events. Check consent and privacy handling for any analytics implementation before collecting new events. If no field data is available, state that honestly and start with customer reports plus controlled reproduction.

Reproduce the exact path on a representative phone, including any shipping and payment selections that trigger page updates. Try a slower device as well as the development machine, and record whether the delay occurs during initial loading or after the page settles. Use the browser performance profiler to capture the tap and the next paint, but avoid placing live payment details in a shared trace. Repeat the action enough times to see whether the symptom is stable; one trace may catch a background task by chance. Keep a written table of action, device, browser, observed delay and suspected phase. The exercise is diagnostic, not a substitute for customer data. A controlled trace tells the developer where to look; real use tells the business how broadly the problem appears.

Separate the three parts of a slow response

If input delay dominates, the browser was busy before the tap handler began. Look for a long task from page startup, a recurring timer, or a third-party script running at the same time. Moving work unrelated to the immediate decision out of that busy interval may help. If processing duration dominates, inspect what the tap handler itself does: repeated validation of every field, synchronous parsing of a large list, expensive calculations, or many chained updates. Keep essential checks, but avoid repeating work that can be cached or deferred safely. If presentation delay dominates, the handler may finish yet the browser still has substantial style, layout or rendering work before it can paint feedback. Reduce the area that changes and avoid triggering repeated layouts. Google’s optimization guide treats these phases separately because each calls for a different fix.

Do not mistake an asynchronous server wait for an INP fix opportunity. A network call can take time while the browser remains free to paint a clear waiting state. The customer still needs to know that the request was received, whether it is pending, and what happens if it fails. Show immediate visual feedback that reflects the real server state, prevent accidental repeated submission, and update the status when the result is known. Do not display a completed order before the server has confirmed it. Conversely, adding a spinner only after a long synchronous handler has finished does little for the tap that felt dead. The useful sequence is: acknowledge the input promptly, keep the interface responsive, then report the actual transaction result accurately.

Use a checkout example to choose a fix

Suppose a shop’s delivery selector feels slow only on mid-range phones. A trace shows the tap waits behind a script that rebuilds a large product recommendation list, even though recommendations do not affect delivery eligibility. The team moves that nonessential update until after the selector has painted. It then tests the same phone and path again, ensuring the delivery choice remains correct and the order amount is unchanged. In a second scenario, the trace shows a quick browser response but a long wait for the shipping quote service; the fix is clearer pending and error feedback plus investigation of the service, not a claim that improving INP will make the quote arrive sooner. Both scenarios are illustrative. They show why the phase evidence should choose the remedy instead of a generic ‘speed up the page’ ticket.

Prioritise the interactions that are both slow and important to completing a purchase. A rarely used decorative control may be measurable, but a delayed address correction or delivery selection can stop a customer from ordering. Check keyboard activation as well as touch, because the code path or focus update may differ. Test the failure case too: invalid address, unavailable delivery method and rejected payment need timely, intelligible feedback. An optimisation that removes validation or hides errors has exchanged accuracy for apparent speed. Record the change, the trace that motivated it and the acceptance criteria. The business decision is whether the customer can understand and complete the flow, not merely whether one metric moved.

Verify the change beyond a single score

Retest the same interaction on the same class of device and compare the before and after traces. Then examine field data, where available, over enough ordinary visits to see whether the mobile checkout improves without a new failure elsewhere. Compare the same page and action, and account for a changed traffic mix before claiming improvement. Keep monitoring transaction success, duplicate submissions and customer support reports as separate measures; a responsive button can still submit a broken order. If field coverage is sparse or unavailable, report the controlled test result and the gap honestly. The practical finish line is a checkout that promptly acknowledges each action, preserves correct order logic and tells customers the true status of their purchase.

Write a precise improvement brief

A useful brief identifies the action and expected feedback. For example: when a shopper changes delivery method on a representative mobile device, the selection should show immediately, the displayed charge should remain consistent with the server calculation, and a failed quote should produce a clear recovery path. Attach the trace showing whether input delay, handler work or presentation delay dominated. Name any feature that may be deferred and any correctness rule that must remain synchronous. This allows a developer to reduce unnecessary work without accidentally changing price, stock or eligibility decisions. It also gives the owner a way to assess the customer journey instead of approving a vague performance score.

Keep the evidence proportional. If the slow interaction is reproducible only after a coupon is applied, test that route and an ordinary route rather than profiling every page on the site. If it appears only after a long session, include the state that accumulates during that session. After the fix, verify focus location, visible status, order amount and the eventual server response as well as the next paint. Improving a browser metric is worthwhile when it reflects a clearer and more usable customer action. The record should state what was observed, on which devices and dates, and what remains uncertain. That distinction stops a controlled test from being presented as proof of a site-wide improvement.