Why Is My WooCommerce Checkout Slow?
A slow checkout is rarely the order itself. Creating an order, reducing stock and taking payment are quick. The time goes on everything that hooks into those steps: plugins making HTTP requests while the customer waits, emails sent inline, integrations syncing the order to another system, and cache-purge plugins reacting to order activity as though each order were a published page. None of that is cached, because checkout never is, so every customer waits through all of it.
Find which of these your checkout is waiting on, then fix that one.
What makes checkout slow
Cache-purge plugins reacting to order notes. WooCommerce writes several order notes during a purchase (“Payment complete.”, “Stock levels reduced.”) and stores them as comments. Purge plugins that purge on every comment then send purge requests for an order that has no public page, and some fetch extra URLs as well. Each is a real HTTP request from your server to itself, made inside the customer’s place-order request.
Third-party HTTP calls. Payment gateways have to talk to their provider, and that call is necessary. But shipping-rate lookups, tax services, fraud checks, CRM and email-marketing syncs, and licence or telemetry calls can all run during checkout too, and WordPress waits for each one to finish or time out.
Emails sent inline. By default WooCommerce sends the new-order and customer emails during the request that creates the order. A slow mail server or SMTP plugin adds its delay straight to the checkout.
Heavy hooks on order creation. Stock syncs, ERP or warehouse connectors, analytics and loyalty plugins often do their work on order creation or status change, inside the same request.
Find out which one you have
Super Speedy Performance Analysis is free and can analyse your checkout and order flow. It places one real order with every plugin on your site active, and shows the server time your customer waits through at each step, split at the payment boundary so time that risks the sale is shown separately from time after the money is in. Before it creates anything, a pre-flight panel lists exactly which emails, webhooks and plugins the run will trigger. The order is then completed, refunded without contacting the gateway, and moved to the Trash.
Do not judge checkout speed from the checkout page loading. The page is one request; placing the order is another, and that second request is where purge calls, emails and integrations run.
Fixes, in the order to try them
1. Stop purge plugins reacting to orders: Scalability Pro
The Checkout Purge Shield in Scalability Pro is on by default. It stops order notes triggering purges, and answers the site’s own requests to URLs that cannot have anything cached without sending them over the network. Genuine purges, such as a new review on a product, still happen.
On a test store running Nginx Helper with its default settings, one checkout made 30 outbound purge requests. With the shield on, it made none. On superspeedyplugins.com, my own store, those purge requests were adding about 19 seconds to checkout. That was my store and my host’s purge set-up; what they cost yours depends on your purge plugin and cache server.
The shield only helps if a purge plugin is reacting to your orders. A separate, off-by-default setting caps the timeout on the site’s own purge requests at 3 seconds, for stores where purges that genuinely need to happen are slow to answer.
2. Move non-urgent work out of the request
Anything the customer does not need before they see their order confirmation can run afterwards:
- Emails. WooCommerce queues its transactional emails in the background instead of sending them inline when the
woocommerce_defer_transactional_emailsfilter returns true. - Integrations. Many CRM, email-marketing and ERP plugins offer a background or scheduled sync mode. Use it where the profile shows the integration’s HTTP calls inside place-order.
- Plugins you do not need. If the profile shows a plugin’s work at checkout and you do not use that feature, switch it off or remove the plugin.
3. Free the server for checkouts: Cache Everything for Everyone
Checkout itself is never cached. But on most stores, the requests competing with checkouts for the server are catalogue pages served uncached to shoppers who have something in their basket or are logged in, because most page caches give up on exactly those visitors. Cache Everything for Everyone is a done-for-you service that sets up full-page caching for basket holders and logged-in customers, so the server’s capacity goes to the requests that cannot be cached, including checkout.
Comments