Rebuilding checkout for speed

This is the sequel to cutting the flow to three screens: the same checkout, a year later, measured properly. The dashboard said it was fast. The support inbox said otherwise, and the support inbox was right — because the dashboard was showing a median, and nobody complains about a median.

p50 before

1.1s

and it stayed 1.1s after

p95 before

4.6s

on-sale peak, mobile

p95 after

2.2s

same conditions

Find the tail, then find who is in it#

Splitting the p95 by device and moment gave the answer in about ten minutes: it was almost entirely phones, almost entirely in the first four minutes of an on-sale. Which is to say, the exact population for whom the purchase mattered most.

The four changes#

1. 01
   A smaller critical path

   The checkout route was importing the seat map renderer it no longer showed. Ninety kilobytes of JavaScript parsed before the first paint on a device that was never going to run it.

2. 02
   The payment sheet, earlier

   We now create the payment intent while the buyer is still confirming, not after. If they back out, it is cancelled. That single move took roughly 600ms off the tail because it overlaps a network round trip with a human reading a screen.

3. 03
   One round trip, not three

   Hold, price and fee resolution were three sequential calls that each depended on the previous one's id. They are now one endpoint that does all three inside one transaction.

4. 04
   Honest waiting

   Where a wait was unavoidable, the button now says what is happening — “Reserving your seat”, then “Taking payment”. It does not make anything faster; it measurably reduced double-taps, which absolutely did.

What did not work#

• Prefetching the checkout route on hover. Real buyers on mobile do not hover, and the desktop win was inside the noise.
• A skeleton for the payment sheet. It made the wait feel longer in testing — a skeleton implies content is arriving, and what arrives is a third-party iframe with its own timing.
• Shaving the CSS. Twelve kilobytes saved, no measurable change. The critical path was JavaScript, and we spent two days confirming that the hard way.