Why Shoppers Abandon Checkout on Slow-Loading Pages
Shoppers abandon checkout on slow pages because every second past roughly two to three seconds stops reading as patience and starts reading as risk. They wonder if the payment went through twice, if the site has frozen, or if a competitor's checkout would just be faster. Baymard's research puts average cart abandonment at 69% across all causes, and slow load time is one of the few causes a store can fix in an afternoon.
How slow is too slow? The checkout abandonment threshold
There is a real number here, and it is smaller than most store owners assume. Google's own performance research has repeatedly shown that mobile shoppers start leaving a page once load time crosses about 3 seconds, and the drop-off compounds for every second after that. Checkout is not a place where shoppers give you the benefit of the doubt. They have already decided to buy. A slow page at this exact moment reintroduces doubt you had already removed.
A simple way to think about it, based on what we see across audited stores and what performance research consistently shows:
| Checkout load time | What typically happens |
|---|---|
| Under 2 seconds | Meets expectations, no noticeable drop in completion |
| 2-4 seconds | Shoppers hesitate, some open a second tab to check the price elsewhere |
| 4-6 seconds | Noticeable abandonment increase, worse on mobile networks |
| 6 seconds or more | Most shoppers exit before reaching payment |
This is also the threshold that answers the ideal checkout load time question directly: aim for under 2 seconds to the point the shopper can act, not just under 2 seconds for the page to appear.
Why checkout pages load slower than the rest of your store
Most speed advice online is written about homepages and product pages, where the bottleneck is usually images. Checkout is different. The bottleneck is almost always scripts, and checkout tends to carry more of them than any other page on the site.
A typical checkout page loads:
- A payment gateway SDK (Stripe, PayPal, Klarna, or similar), often loaded synchronously
- A tax and address validation API call per field change
- Trust badge and security seal images, sometimes still unoptimized
- A live shipping rate calculator hitting a third-party carrier API
- Analytics, pixel, and A/B testing tags stacked on top of each other
- Fraud detection scripts running in the background before the page is even interactive
Each of these is individually defensible. A fraud check protects you from chargebacks. A live shipping rate is genuinely useful information, and its absence is its own abandonment problem, which we cover in Why Shoppers Abandon Their Cart Over Shipping Costs. But stacked together, and loaded in sequence rather than in parallel, they turn a page that should render in under a second into one that takes five or six.
NN/g's research on perceived performance is useful here: shoppers do not experience load time as a single number, they experience it as a sequence of moments where nothing visible happens. A checkout that shows a skeleton layout at 300ms and becomes interactive at 1.8 seconds feels faster than one that shows a blank white screen for 2 seconds and then appears all at once, even if the second one technically loads sooner on some metric.
What a slow checkout actually costs you
The cost is not abstract. It shows up as carts that were built correctly, with the right product and the right shipping option selected, that simply never convert. In our audits, the most common pattern is a spinner or blank state sitting on screen while third-party scripts finish loading, with no indication to the shopper that anything is happening.
The shopper clicks "Proceed to checkout" and sees a blank white screen for 4-6 seconds, then the full page appears at once.
The shopper sees the page shell and their cart contents within 300ms, with shipping and payment fields becoming interactive within 2 seconds.
This matters more on mobile than desktop, because mobile shoppers are more likely to be on a variable connection and more likely to be doing something else at the same time, like standing in a queue or half-watching something else. We go into the mobile-specific version of this problem, including tap targets and field behavior, in Why Shoppers Abandon Checkout on Mobile: 9 UX Mistakes to Fix.
It also compounds with other checkout problems rather than sitting in isolation. A slow page that also hides shipping costs until step three, or asks for account creation before showing the total, gives the shopper two or three separate reasons to leave rather than one. If your checkout is slow and also opaque about cost, fix the speed first. It is usually the cheaper engineering problem and it affects every shopper, not just the price-sensitive ones.
Does checkout speed matter more than homepage speed?
Yes, and the reason is about intent, not raw numbers. A slow homepage costs you a shopper who was still deciding whether to look around. A slow checkout costs you a shopper who had already decided to buy and put a card in their hand. The second loss is more expensive per visitor, because you have already spent the acquisition cost, the browsing time, and the persuasion to get them there.
This is why UXFix scores checkout load time as its own rule rather than folding it into a general site speed score. A store can have an excellent Core Web Vitals score on its homepage and still lose a third of its checkout traffic to a slow payment step, because the scripts that matter for conversion are concentrated at the very end of the funnel, not the beginning.
The same logic applies to AI shopping agents completing a purchase on a shopper's behalf. Agents typically operate on a fixed timeout and will abandon a checkout that does not respond within a few seconds, with no patience at all for a spinner. If you sell through any agent-assisted channel, a slow checkout is not a conversion problem, it is a hard failure. We cover the broader set of blockers in Why AI Shopping Agents Abandon Checkout on Your Store.
How to fix a slow checkout page
Most fixes here are not redesigns. They are sequencing and prioritization changes to what already loads on the page.
- Load the payment SDK asynchronously, after the core page is interactive.
- Show a skeleton or cart summary within 300ms, even before totals are final.
- Preconnect to your payment gateway's domain so the handshake happens early.
- Audit every third-party script on checkout quarterly and remove ones with no measurable return.
- Block page render on a live shipping rate call from a carrier API.
- Stack five trust badge images at full resolution above the fold.
- Add a new analytics or retargeting pixel to checkout without testing its load impact first.
A few of these deserve more detail. Preconnecting to the payment gateway's domain is a one-line change in most templates and shaves real time off the handshake, since the browser can resolve DNS and start TLS negotiation before the script is actually requested. Google's own guidance on this, and on measuring the metrics that matter for perceived speed, is documented on web.dev, which is also the right place to run a real audit of your checkout template rather than guessing.
Script audits are the highest-leverage fix and the one most stores skip, because no single team owns "everything on the checkout page." Marketing adds a pixel, fraud adds a script, a plugin adds a widget, and eighteen months later nobody remembers what half of them do. Pull up your checkout in a network waterfall tool once a quarter and ask, for each request, whether removing it would change a business outcome. If the answer is no, remove it.
Finally, treat trust and security signals as a design problem, not a loading problem. Shoppers need to see them, but they do not need to load five full-resolution badge images above the fold before the page becomes usable. We cover how to place these signals without the performance cost in Why Shoppers Abandon Checkout Without Trust Badges or Security Signals.
Frequently asked questions
What is an acceptable checkout load time?
Under 2 seconds to a fully interactive state is the target most performance research converges on, with meaningful abandonment risk appearing once total load time crosses 3 seconds on mobile. The safest way to think about it is not the page appearing, but the shopper being able to actually tap a field or button.
Does checkout speed affect conversion more than homepage speed?
Yes, because checkout sits closest to the purchase decision, so a delay there costs a shopper who had already committed to buying rather than one who was still browsing. UXFix scores checkout load time as a separate rule from general site speed for this reason, since the two do not move together and one is far more expensive to get wrong.
How do I test my checkout page speed?
Run your checkout URL, not just your homepage, through a real network waterfall tool and check both total load time and time to interactive on a throttled mobile connection. Google's web.dev tools and NN/g's usability research are both useful starting points, since one measures raw performance and the other explains how shoppers actually perceive that performance.
What is the single biggest cause of a slow checkout page?
In our audits, it is almost always a synchronously loaded payment SDK or a live third-party API call, such as tax or shipping rate lookups, blocking the rest of the page from rendering. Fixing the loading order, rather than removing functionality, resolves most of the delay in the stores we have audited.