Checkout is the page in a WooCommerce store where the customer is closest to buying, and the hardest one to make fast. It can’t be cached, and every time the customer changes their address, shipping or payment, WooCommerce recalculates the cart from scratch. When the customer clicks “Place order”, the order has to be created, the payment approved, stock reduced and emails sent before the customer sees the confirmation.
This guide shows how to find out which of those steps is slow and what you can do about it. If the whole store is slow, start with our guide to troubleshooting a slow WooCommerce store.
Where in checkout is it slow?
“Checkout is slow” can mean several different things. Go through a purchase yourself and note where you wait.
| You wait | Typical cause |
|---|---|
| While the checkout page loads | The server, no object cache, heavy plugins or scripts on the page |
| While you type an address or pick shipping | Shipping and tax recalculated each time, often with a call to a carrier’s API |
| After you click “Place order” | The payment gateway, emails sent right away, or integrations running in the middle of the order |
| The page keeps loading | A JavaScript error, a conflicting plugin, or a checkout that gets cached by mistake |
Find the slow request
Most of what happens in checkout happens in requests sent after the page has loaded. You see them in your browser’s developer tools (F12) under Network. Go through a purchase with the tab open, and sort by time.
In the classic checkout, the important ones are ?wc-ajax=update_order_review, which runs every time the address, shipping or payment changes, and ?wc-ajax=checkout, which runs when the customer clicks “Place order”. If the store uses the newer Checkout block, the traffic goes to WooCommerce’s Store API under /wp-json/wc/store/v1/ instead, for example cart and checkout. The request that takes longest is where you look.
If it’s update_order_review or the cart in the Store API, look at shipping, tax and plugins that hook into the calculation. If it’s checkout itself, look at payment, emails and integrations. Query Monitor can show which plugins and external calls use the time in a single request. Ideally, use it on a copy of the store.
Shipping and tax are recalculated on every change
Every time the customer changes their postcode, country or shipping method, WooCommerce recalculates shipping, tax and totals. With flat shipping rates that’s quick. If a shipping plugin fetches rates or pickup points from a carrier’s or shipping platform’s API, checkout waits for the answer each time. If the API is slow or down, the customer feels it directly.
Check the shipping plugin’s settings for whether it keeps answers for a while, so the same address isn’t looked up again on every change, and whether it has a timeout, so checkout doesn’t hang when the API doesn’t answer. If you have several shipping plugins that each serve a single method, it may be worth consolidating them. The same goes for plugins that calculate tax or fees from the cart: they run on every update.
When the customer clicks “Place order”
The moment the customer clicks “Place order”, WooCommerce does a series of things in the same request: it creates the order, reduces stock, calls the payment gateway and sends order emails. Plugins can hook their own work onto the same steps, for example sending the order on to an inventory, accounting or CRM system. The customer waits for all of it.
- Payment: The call to the payment gateway is necessary, but it should only be one. If it’s slow, check that the plugin is up to date, and ask the provider whether there are known issues.
- Emails: If order emails go through the server’s own mail function or a slow mail server, they can delay the confirmation. Send them through a proper email service.
- Integrations: Syncing with accounting, inventory or shipping should happen in the background after the order is complete, not while the customer waits. Many plugins can be set up that way. If yours can’t, it’s worth raising with its developer.
Work moved to the background ends up in WooCommerce’s scheduled actions queue. Why that queue should run from the server and not on your customers’ page views is covered in the section on background jobs in the troubleshooting guide, and how to keep the queue itself clean in our guide to Action Scheduler.
Plugins and scripts on the checkout page
Checkout often gathers many plugins: extra fields, upsells, gift cards, loyalty programs, chat, tracking and pop-ups. Each of them can add work on the server and scripts in the browser. Look in the Network tab at which scripts load on checkout, and ask of each one: does it need to be here for the customer to pay? Chat, pop-ups and sliders can often be turned off on checkout, even if they stay on the rest of the store.
If one plugin accounts for much of the time, try the store without it on a copy. That’s the fastest way to a reliable answer.
Caching and the server
Cart and checkout must not be in a page cache, because the content is different for every customer. So every view is built from scratch by PHP and the database. What helps here is an object cache such as Redis, which keeps the results of database queries between views, and a server with enough PHP processes that customers don’t queue. How those layers fit together is explained in how WordPress works: architecture and performance.
If checkout is only slow when many customers are on it at once, it’s often the server running out. Removing fields won’t help then. It’s the same problem that hits on Black Friday, and the preparation is in our Black Friday checklist.
If checkout keeps loading
A checkout that never finishes is rarely slow. It has stalled. WooCommerce’s own documentation on the endless loading spinner points to the usual causes: a JavaScript error from a plugin or the theme, a conflicting plugin, or a cache serving an old copy of checkout. Look for red errors in the browser console (F12), and check that checkout, cart and My account are excluded from the page cache.
Frequently asked questions
Will switching to a different checkout plugin help?
Only if the checkout page itself is the problem. If the time goes into shipping calculation, payment or integrations, it follows you into the new plugin. Find the slow request first.
Does checkout get faster with fewer fields?
Fewer fields make checkout quicker for the customer to fill in, but they rarely make the server faster. If response time is the problem, the cause is in one of the steps above.
Want help?
A slow checkout hits customers who have already decided to buy. If you’d like us to find the cause, read about optimizing a slow WooCommerce store. We take a free look at your store first and tell you what it will take.