WooCommerce Slow Checkout: What to Check

Symptoms

• Several seconds between clicking Place Order and the thank-you or payment page.
• The order review spins every time the customer changes the address, shipping method or quantity.
• Checkout is fast at night and slow during busy hours.
• Occasional 502 or 504 errors at checkout under load.

Most common causes

1. External calls during checkout: live shipping rates, tax calculation services, address validation, fraud scoring, ERP stock checks, licence checks.
2. Work done while the order is created: transactional emails sent through a slow mail server, synchronous CRM or ERP pushes, PDF invoice generation.
3. Slow database queries: large meta tables, a big sessions table, unindexed custom queries, and no persistent object cache.
4. Too many refreshes: every field change triggering an order review update that re-runs all of the above.
5. Exhausted PHP workers: slow requests occupy the PHP-FPM pool, so new checkout requests wait in a queue.

Diagnosis

1. Time the right requests

Open the Network panel and go through a checkout. Note the time to first byte (TTFB) of:

• ?wc-ajax=update_order_review (classic checkout, every refresh)
• ?wc-ajax=checkout (classic checkout, Place Order)
• /wp-json/wc/store/v1/cart/... and /wp-json/wc/store/v1/checkout (Checkout block)

A slow update_order_review points to shipping, tax and totals; a slow checkout points to order creation, payment and anything hooked to it.

2. Break the time down on staging

On a staging copy with production-like data, use Query Monitor to see, for the slow request, the database queries (slowest and duplicated), the HTTP API calls with their duration, and the hooks that run. External calls usually stand out immediately.

3. Find slow requests on production

Enable the PHP-FPM slow log (request_slowlog_timeout, for example 5 seconds). For every request that exceeds it, PHP-FPM writes the stack trace of where the code was waiting — often a curl_exec() inside a shipping or ERP plugin.

4. Check the database side

Look at the slow query log, the size of the sessions table, autoloaded options, and whether a persistent object cache (Redis or Memcached) is active and actually being hit.

Logs and technical checks

• Network panel timings for the checkout requests.
• Query Monitor on staging: queries, HTTP API calls, hooks.
• PHP-FPM slow log and status page.
• MySQL slow query log.
• Mail logs or the SMTP plugin's log for slow deliveries at order time.
• Tools → Scheduled Actions for background work that falls behind.

Solutions

• Cache or reduce external calls: cache carrier and tax responses where their terms allow it, add timeouts, and avoid calling services on every field change.
• Move work out of the order request: push ERP and CRM syncs to Action Scheduler; defer transactional emails or send them through a fast relay.
• Add a persistent object cache and make sure checkout-related data is not flushed on every request.
• Fix the slow queries: indexes for custom lookups, cleaning expired sessions and oversized autoloaded options.
• Size PHP-FPM for real traffic, based on memory per worker and peak concurrency.

// Send WooCommerce transactional emails after the response instead of during checkout.
add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

What not to do

• Do not page-cache the checkout or cart to make them "fast"; it breaks sessions, nonces and totals.
• Do not install a second caching plugin; it does not apply to checkout.
• Do not remove shipping or tax plugins without checking the business rules they enforce.
• Do not upgrade hosting before measuring where the time goes.

When to contact an expert

Contact an engineer when the slow part is inside a plugin or custom code you cannot change safely, when slowness only appears under real traffic, or when checkout errors (502/504) start appearing at peak times.

Related problems

• WooCommerce / Performance WooCommerce Action Scheduler Problems Past-due, failed and stuck scheduled actions: how the queue runs, why it stalls and how to fix it without losing pending work. →
• WooCommerce / Checkout WooCommerce Checkout Not Working: How to Diagnose the Root Cause First determine whether the failure happens before the checkout request, during it, or after the gateway response. The Network panel and PHP logs usually reveal which layer fails. →
• WooCommerce / Errors WooCommerce Plugin Conflict: How to Find the Cause Start from the evidence — the error, the timing, the request — and isolate on staging by halves, not one plugin at a time on production. →

Frequently asked questions