Checkout is the one page where slowness converts directly into lost revenue. Everywhere else a delay costs you attention. Here it costs you someone who had their card out.
It is also the hardest page to keep fast, and for a structural reason: checkout is the only part of the store that cannot be cached. Prices, stock, shipping rates and taxes all have to be current for this specific customer, so every request does real work.
Third-party calls in the critical path
The single most common cause we find is a call to an external service that happens while the customer waits. Shipping rate lookups, address validation, fraud checks, tax calculation, loyalty point balances. Each one is reasonable on its own.
The trouble is that they add up and that they are only as fast as someone else's server. If a shipping provider has a slow afternoon, your checkout has a slow afternoon. And if that call has no sensible timeout, a provider outage becomes a checkout outage.
Work that does not need to happen now
Order confirmation emails are the classic example. By default, sending can happen as part of placing the order, which means the customer waits for your mail server before seeing a thank you page.
Nothing about that is necessary. The customer does not need the email to exist before the page loads. Moving it to the background queue takes it out of the critical path entirely, and the same reasoning applies to ERP notifications, analytics posts and anything else that fires on order placement.
JavaScript weight
The default checkout is a JavaScript application, and it is not a small one. Every extension that adds a step, a field or a payment method adds to it, and the browser has to parse and execute all of it before the customer can type anything.
This is where INP shows up most painfully, because a customer tapping a field and waiting for it to respond is an experience they remember. It is also where a lighter frontend makes the clearest case for itself.
What we look at, in order
- Server timing per checkout step. Which request is slow, and is it slow consistently or occasionally? Occasional means an external dependency.
- The list of external calls. What is being asked of whom, with what timeout, and does it have to happen before the page renders?
- Synchronous work on order placement. Email, ERP, notifications. Most of it belongs in a queue.
- JavaScript execution. How long before the form is usable, on a mid range phone rather than on a laptop.
- The number of steps. Sometimes the fastest checkout is the one with less in it, which is a conversion conversation as much as a performance one.
Measure the funnel, not just the page
A speed number on its own does not tell you what you lost. Look at your checkout funnel: how many people reach the payment step and do not complete it, split by device. If mobile drops off much harder than desktop, you probably have a performance problem rather than a pricing one.
That comparison is also the cleanest way to justify the work internally. It turns a technical complaint into a number with a currency symbol in front of it.