Why your WooCommerce checkout is slow, and how to measure it

A slow checkout is the most expensive kind of slow page. Visitors who reach it have already decided to buy, and every extra second gives them a reason to stop. The good news: checkout slowness almost always has one or two dominant causes, and you can find them with measurement instead of guesswork.

This is the order we work in when a client tells us their WooCommerce checkout "feels slow".

1. Separate server time from browser time

First decide where the time goes. Open the checkout in Chrome, open DevTools, go to the Network tab and reload. Click the main document request and look at Timing:

• Waiting for server response (TTFB) is time spent in PHP, the database and anything PHP calls out to.
• Everything after that (downloading, parsing and running JavaScript, loading images and fonts) is front-end time.

Then add an item to the cart, go to checkout, and watch the ?wc-ajax=update_order_review and ?wc-ajax=checkout requests. These are the two calls that make a checkout feel sluggish when the page itself loads quickly: the first runs every time the customer changes the address or shipping method, the second when they click Place order.

If TTFB or those AJAX calls take more than a second, the problem is on the server. If they are fast and the page still feels slow, it is the front end.

2. Profile the server side

Install Query Monitor on a staging copy (never debug on production if you can avoid it). On the checkout page it shows:

• total database queries and their time, grouped by plugin ("component")
• slow and duplicate queries
• HTTP API calls made during the request, with their duration

The HTTP calls are often the surprise. Plugins call external services during checkout: address validation, tax calculation, shipping rates, fraud checks, licence checks of the plugin itself. Each call adds its full network round trip to every update_order_review. One slow carrier API can add seconds.

For deeper profiling, a PHP profiler such as Xdebug's profiler, Tideways or Blackfire shows which functions consume the time. You rarely need it for a first pass, but it settles arguments when Query Monitor shows nothing obvious.

3. Check the usual suspects

In our experience, the cause is usually on this list:

• Shipping and tax plugins calling external APIs on every recalculation. Fix: cache rates per address and cart contents, or calculate only when the address is complete.
• Too many plugins hooking into the cart. Each one adds work to every cart calculation. Remove what you do not use; for the rest, check whether they can be limited to the pages that need them.
• A heavy wp_options autoload. WordPress loads every autoloaded option on every request. A few megabytes of autoloaded data from old plugins slows down every page, including checkout. We cover how to check this in MySQL performance tuning for WordPress.
• Orders still stored as posts. Stores that have not migrated to WooCommerce's High-Performance Order Storage (HPOS) keep orders in wp_posts and wp_postmeta, which makes order creation and lookups heavier than they need to be. HPOS is the default for new stores; older stores can migrate under WooCommerce → Settings → Advanced → Features, after checking that their plugins are compatible.
• No persistent object cache. Without Redis or Memcached, WordPress rebuilds the same data from the database on every request.
• Underpowered or misconfigured hosting. Old PHP versions, too few PHP-FPM workers for the traffic, or a database server shared with dozens of other sites.

4. Then look at the front end

If the server is fast, open the Performance panel in DevTools or run Lighthouse on the checkout. Typical findings:

• scripts from every plugin loaded on every page, including checkout, whether needed or not
• large tracking and chat widgets that block the main thread
• the payment gateway's script loading late, so the payment fields appear after everything else

Core Web Vitals in the field (Search Console, or the Chrome UX report) tell you whether real visitors experience the problem, not just your laptop on fibre.

5. Measure before and after

Write down the numbers before you change anything: TTFB of the checkout page, time of update_order_review, time of the checkout submission, and query count. Change one thing at a time and measure again. This avoids the common trap of installing a caching plugin, feeling that the site is faster, and never knowing whether the actual problem was solved.

A note on caching plugins: full-page caching cannot help the checkout itself, because the checkout is different for every visitor and must not be cached. It helps the rest of the site, which frees server capacity, but it does not fix slow checkout code.

When to call for help

You can do most of this yourself with Query Monitor and DevTools. It gets harder when the slow part is inside a plugin you cannot change, when the fix needs custom caching around an external API, or when the database needs structural work.

That is the work our WordPress and e-commerce service does: measure, fix the real bottleneck, and show the before and after. We build Akantio POS on the WooCommerce REST API, so we spend a lot of time inside WooCommerce internals.