A customer has chosen a product, filled the cart and clicked through to pay. Then they wait. The checkout page takes long to load, the spinner turns after they type their postcode, and after “Place order” there is a long pause before the thank-you page. Some customers wait it out. Some refresh, and some leave.
Is your WooCommerce checkout slow enough to make people refresh? There is rarely a single cause. Checkout is the busiest page in a store: it is never cached, and it is where payment, shipping, tax, coupon and marketing extensions all do their work. The way through is to split checkout into its separate moments and find which one drags. Checkout errors, where orders fail rather than drag, are covered in our guide to fixing WooCommerce checkout errors.
Checkout is uncached by design
Every checkout page is built fresh for the shopper, because it shows their cart, their address and their totals. Caching plugins and well-configured hosts skip it on purpose; why that has to stay true is explained in our post on which store pages must never be cached. So the speed of checkout depends entirely on how much work the server does for each request, and how much the browser has to load.
That makes checkout a good honest test of a store’s underlying speed. A store whose product pages are fast only because of the cache will show its true speed here.
WooCommerce checkout slow at one step? Time the four moments
Time each of these separately, on a phone and on a computer, logged out, with a real product in the cart:
- The checkout page loading. From clicking “Proceed to checkout” until the form is usable.
- The update after entering an address. Changing country, state or postcode recalculates shipping and tax. In the classic checkout, this is a background request to
?wc-ajax=update_order_review. In the block-based checkout, it is a request to WooCommerce’s Store API under/wp-json/wc/store/. - Choosing shipping or payment methods. Switching between them can trigger another recalculation.
- Placing the order. From the click until the thank-you page or the payment provider’s screen appears.
Your browser’s developer tools show the second and third moments clearly. Open the Network tab, filter by wc-ajax or wc/store, change the postcode, and note how long the request takes. Most of the time, one of the four moments is much slower than the others. That is where to dig.
When the checkout page itself loads slowly
The checkout page usually carries more scripts than any other page in the store:
- Payment gateway scripts. Card and wallet providers load their own JavaScript from their servers to build secure payment fields. A store with several gateway plugins may load several of these, even for methods few customers use.
- Address autocomplete. Address lookup tools load a mapping or address service script.
- Checkout field editors and custom fields. Extra fields, conditional logic and validation add scripts and server work.
- Order bumps, upsells and countdown timers placed on the checkout.
- Tracking and marketing tags. Pixels, analytics, heatmaps and session recording. Checkout is the page marketers most want to measure, so tags pile up there.
- A page builder template for the checkout, with its own styles and widgets.
For each, ask whether customers actually need it at this step. Payment methods that almost nobody uses can often be removed. Marketing tags deserve a careful review; our guide to external scripts that slow pages down explains how to audit them.
On the server side, the page load runs every active plugin. If it is slow even with a simple theme and no extras, the store’s uncached speed is the issue, and the priorities in our post on speeding up a WooCommerce store apply.
When the address update is slow
This is the most common slow moment, and the most frustrating for customers because it happens while they are typing.
Live shipping rates
Shipping plugins that quote live rates from carriers or aggregators call the carrier’s service each time the address or cart changes. If that service is slow, your checkout waits for it. Ask yourself:
- Do you need live rates, or would flat rates, table rates by zone or free shipping over a threshold do the job for most orders?
- Does your shipping plugin cache rates for the same cart and address? Some do, and the option is worth switching on.
- Are several shipping plugins each calculating rates when only one is used?
Tax lookups
WooCommerce’s own tax tables are calculated locally and are quick. Tax services that calculate in real time call an outside service, which adds a wait each time the address changes. If you use one, check its timeout and caching options.
Other extensions hooked into the recalculation
Coupons with complex rules, dynamic pricing, loyalty points and fees for payment methods all run during each recalculation. One poorly written rule can make every update slow.
To find which one it is, use a staging copy. Time the address update with all checkout extensions active, then switch them off one at a time. The extension that makes the biggest difference is your answer.
When “Place order” takes a long time
Placing an order does a lot of work in one go: validating fields, creating the order, reducing stock, talking to the payment gateway, recording the payment and sending emails. A few things commonly stretch this out.
- Order emails sent during the request. By default, the confirmation emails are usually sent as part of placing the order. If the site sends mail through a slow mail server, the customer waits for it. A reliable transactional email service set up over SMTP or an API usually responds faster than a struggling server mail setup; our post on fixing WordPress email delivery covers that setup.
- Integrations running immediately. Invoice generators, CRM syncs, accounting connections and shipping label tools may run when the order is created. If they call outside services at that moment, the customer waits for those too. Many can be set to run in the background instead; ask the extension’s developer.
- Fraud and spam checks that call outside services before accepting the order.
- The payment step itself. Redirect gateways send the customer to the provider’s page, and on-site gateways confirm the payment while the customer waits. This is mostly outside your control, but a gateway plugin that is out of date can be slower than it should be.
If this moment is slow only sometimes, check whether it happens when outside services are busy. Logs under WooCommerce’s Status screen, and any logs from your shipping or payment plugin, sometimes include response times or timeout errors.
What not to do
Do not cache the checkout to make it faster. It makes speed tests look good and gives customers wrong totals or someone else’s details.
Do not delay the payment scripts. Script delay and combine features in speed plugins can break the payment fields or the place-order button. Exclude gateway scripts from these optimisations and test a real payment.
Do not remove a payment method without checking how many orders use it. Your order list can be filtered by payment method; look before you remove anything.
Do not test only as an administrator. Admin users load extra things, and customers see a different checkout. Test logged out, and as an ordinary customer account.
Measuring before and after
Write down, for each of the four moments, how long it took in three attempts. Make one change, then measure again. Finish every session of changes with a real low-value order, paid through the live gateway or the gateway’s test mode, and confirm that the order appears, the email arrives, stock reduces and any integrations receive it. Speed that costs you a working checkout is not worth having.
For the wider context, the section guide on judging plugin weight on a WordPress site helps you decide which extensions earn their place, and our page speed guide explains how server time, scripts and page weight combine on any page, checkout included.
Frequently asked questions
Is the block checkout faster than the classic shortcode checkout?
It can feel quicker because it updates parts of the form without reloading as much, but it depends on your extensions. Both versions still run your shipping, tax and payment plugins on the server. Some extensions behave better on one than the other, so test both on staging with your own setup and time the same four moments.
Why is checkout slow only for some customers?
Usually because their order triggers something others do not: an address that needs a live shipping quote, a coupon with complex rules, a payment method with a slow provider, or a product with extra options. Note the details of slow orders when customers report them, then repeat that exact cart and address on staging to reproduce it.
Can I make order confirmation emails stop delaying the thank-you page?
Often, yes. Sending mail through a fast transactional email service usually shortens the wait. WooCommerce can also be set up by a developer to send transactional emails in the background rather than during the order request. Test carefully afterwards, because customers rely on that email, and confirm it arrives every time.
Will better hosting fix a slow WooCommerce checkout?
Only if the server is the bottleneck. Checkout is uncached, so faster processors and more PHP workers do help. But if the delay is a carrier’s rate service, a slow mail server or a heavy extension, a bigger plan changes little. Time the four checkout moments first, so you know which part you are paying to fix.
Checkout pages are listed among the things our store speed optimisation service looks at. We time the store on the pages customers use, rank what we find, and change nothing on a checkout until you have agreed to it; the same steps are timed again afterwards.
Next in this series: admin-ajax.php Slow? Find What Is Calling It
