Checkout speed is decided after the page has loaded, in the time between a tap and the answer on screen
Advice on site speed usually starts with load time: how quickly the first screen appears after a click. For a product page that is a fair test. For a checkout it misses most of the visit. On the checkout the shopper types a name and address, picks a delivery option, changes a quantity, chooses a payment method and taps the button to pay. Each of those actions asks the page for a response, and each response can be quick or slow regardless of how fast the page first appeared. Google’s own figures from Chrome make the point: nine tenths of the time people spend on a page falls after loading has finished.
Google changed its own yardstick to match. On 12 March 2024, Interaction to Next Paint, or INP, replaced First Input Delay as the Core Web Vital for responsiveness. First Input Delay looked only at the wait before the browser could start handling the first interaction on a page. INP observes every click, tap and key press during the visit and reports the slowest one, setting aside one outlier for every 50 interactions, and the value that counts is the 75th percentile of real page views. Google rates 200 milliseconds or less as good and anything above 500 milliseconds as poor. A checkout that loads fast and then hesitates after every key stroke now shows up as slow in Google’s own measurement, as it always did for the shopper.
The pages deeper in the visit respond worst on a phone
The HTTP Archive Web Almanac, which draws on real-user data from Chrome across millions of websites, shows where the weakness sits. In its performance chapter published in January 2026, based on July 2025 data, 97% of desktop sites had good INP against 77% of mobile sites. The gap widens away from the home page. On mobile, 80% of home pages reached good INP, but only 69% of secondary pages, the pages a visitor reaches by moving through the site. The authors point to the kind of page: pages further into a visit tend to do more work in response to each action, checking input and updating content, and they are where scripts from outside parties often switch on.
A checkout is the clearest example of such a page. It is the most form-heavy screen on the site, it validates as the shopper types, it recalculates totals when a delivery option changes, and it is where tag managers, chat tools, session recording and fraud scripts tend to accumulate over the years. Larger sites are improving but still trail. Among the 1,000 most visited sites, 63% had good mobile INP, up from 53% a year earlier, yet still below the 77% average for all sites.
What a slow answer looks like in the payment step
Responsiveness problems rarely look like a slow site. They look like a field that lags behind the keyboard, a delivery option that appears to ignore the tap, or a total that updates a moment after the shopper has already scrolled on. Google splits each interaction into three parts: the input delay before the page starts handling the tap, the time the page spends processing it, and the delay before the next frame appears on screen. On a busy checkout the first part grows whenever the browser is still occupied with scripts that have nothing to do with the order.
The moment where this costs most is the button that places the order. A shopper who taps to pay and sees nothing change for half a second does not know whether the tap registered. Some tap again and start a second attempt, others wait and wonder whether the payment went through, and some leave. The button should change state on the very next frame, with a clear message that the payment is being processed, even if the work behind it takes longer.
The gains from fixing this are real, though the published evidence is mostly case studies. In a 2023 case study on web.dev, the Indian bus booking site redBus describes how typing into its search fields triggered expensive re-rendering on every change. Keeping the input local and updating the rest of the page only when the shopper left the field improved the page’s INP by 72%, and redBus reported a 7% overall increase in sales after its INP work. The case study does not separate that result from other factors, so read it as an indication rather than a forecast. The pattern it describes, a form that does too much on every key stroke, is common in checkouts.
Give the checkout only the scripts that help the order
The first fix is removal. Scripts that serve marketing, testing or support on the rest of the site are usually loaded on the checkout by default, because nobody decided otherwise. Each one competes with the shopper’s taps for the same processing time on a phone that is slower than the laptop it was tested on. Make the checkout an exception in your tag manager, and keep only what the order needs: the payment components, address lookup, fraud checks and the measurement you actually use for the checkout.
Then look at the form itself. Validate a field when the shopper leaves it rather than on every key stroke, avoid recalculating the whole page when one value changes, and make sure a chosen delivery option or payment method is marked as selected immediately, before any recalculation finishes.
Start with measurement that isolates the checkout. Collect field data for your checkout and payment pages separately from the rest of the site, split by mobile and desktop, and look at INP alongside load time. Then take a mid-range Android phone, complete an order as a guest with no saved details, and note every tap that does not get an immediate visible response. That list, not the home page speed score, is your checkout speed backlog.
Sources: web.dev, web.dev, web.dev, almanac.httparchive.org
