Commerce

The real cost of a slow checkout

How small checkout delays turn into lost revenue, and the four numbers we track before changing the design.

Written by

Ethan Park

Head of Delivery

/ 6 min read

Key points

  • Checkout latency costs revenue. Measure intent-to-confirmation, the time your customer actually waits.
  • Most slow checkouts have architectural causes: sequential dependencies, unnecessary steps, and an unmanaged payment provider.
  • Fix the critical path before redesigning the interface. Faster confirmation usually beats a new hero section.

We have run enough commerce replatforms to recognise the meeting. Conversion has drifted down for three quarters. The team has a list of hypotheses, all about the design. Almost none of them are about the network.

Checkout is the one flow where every millisecond has a commercial owner. It is also the flow where teams most often measure the wrong thing. They track click to next screen. The number that matters is intent to confirmation.

Where the time actually goes

On a typical storefront, the buy button starts a chain: analytics, session refresh, inventory check, promotion lookup, payment intent, address validation, fraud scoring, and a confirmation write. Each step looks reasonable on its own. Together they turn a two-second decision into a nine-second wait.

The fix is rarely a bigger server. Remove steps from the critical path, parallelise the work that does not depend on the previous response, and treat the payment provider as a dependency you can degrade around, so it stops being a single point of failure.

Measure the flow

We ask clients for four numbers before we touch the design: p75 time to first product view, p75 time from add-to-cart to checkout ready, payment authorization latency, and the abandonment rate at each step. If those numbers do not exist, building them is the first engagement.

Once the flow is instrumented, the argument changes. The team can show a before-and-after on the same cohort, with a confidence interval. Finance can engage with that.

The cheap wins are usually architectural

Server-render the product and cart shell. Cache inventory reads for a bounded number of seconds and make the reservation explicit. Move promotion evaluation to the edge where possible. Preconnect to the payment provider. Render a skeleton that matches the final layout so the page does not shift under a spinner.

None of this requires a redesign. It does require someone to own the critical path end to end. That ownership is usually the actual gap.

What we would do first

Start with a two-week performance review of the live flow, on the same network your customers use. Instrument the four numbers above, record a session trace on a mid-range Android device, and list every step between intent and confirmation.

Then fix the two steps with the worst ratio of latency to business value. In our experience that alone buys more conversion than a new hero section, and it keeps buying it every month.

FAQ

Common questions.

How much revenue does a slow checkout cost?

There is no universal number. The useful calculation is your own p75 checkout latency, abandonment rate at each step, average order value, and monthly checkout starts. Instrument those four numbers and the revenue impact becomes specific to your business.

Which checkout metrics should we track first?

Track p75 time to first product view, p75 time from add-to-cart to checkout ready, payment authorization latency, and step-by-step abandonment. Those four numbers show where intent turns into delay and where delay turns into lost revenue.

Should we redesign checkout to improve conversion?

Measure the live flow first. A redesign can help, but architectural delays, sequential dependencies, and payment-provider latency usually dominate. Fix the critical path, then redesign with evidence.

Next step

Tell us how we can help you.

Tell us the constraint. A senior engineer will reply with a clear next step.

Start a project Direct reply from a senior engineer