WooCommerce checkout slow? Why the till is the sluggish part

There is no more expensive place for slowness than the checkout. On a product page your customer is still browsing — at the checkout they have already decided to buy, and every sluggish second gives them time to reconsider. Around 70 % of all carts are abandoned (Baymard Institute), and a cumbersome, slow checkout process is consistently among the most-cited reasons.

The nasty part: in WooCommerce, the checkout is structurally the slowest part of the shop. If you don't understand why, you'll optimize the wrong things. So first the why, then the levers that actually work.

Why the till is slower than the rest of your shop

1. The checkout is never cached — by design. Your caching plugin makes the homepage and categories fast, but cart and checkout are dynamic: individual items, shipping, taxes, session. Every checkout request is pure PHP + database — this is where your hosting shows what it's really made of. (The bigger picture of why caching helps shops less than blogs is in the main guide: WooCommerce slow? The 7 real causes.)

2. The checkout recalculates on almost every input. The classic WooCommerce checkout fires an AJAX call (update_order_review) whenever country, address, or shipping method changes — and that call recalculates the entire cart server-side: taxes, shipping, discounts, everything. On a slow server, each of those recalculations takes seconds, and your customer experiences a till that "thinks" after every field.

3. Payment and checkout plugins load everywhere. Many payment plugins load their scripts and iframes (Stripe, PayPal & co.) not just at the checkout but on every page of the shop. And every "customize checkout fields" plugin hooks into exactly the recalculation from point 2.

The 6 levers that actually work at the checkout

1. Measure the checkout separately — not just the homepage

Put an item in the cart and measure the checkout URL directly (in PageSpeed Insights this only works to a degree, since the checkout is session-based — additionally use the browser DevTools network tab and watch the duration of the update_order_review calls while filling in fields). Above ~1 second per recalculation means: your server is the bottleneck.

2. Object cache (Redis) — this is where it truly pays off

Page caching does nothing for the checkout, but an object cache very much does: it speeds up exactly the repeated database lookups (options, sessions, products) that every recalculation triggers. If your hosting offers Redis: enable it. If not, that's an argument for your next hosting conversation — together with PHP 8.2+ and enough PHP workers (every recalculation occupies one).

3. Tame the cart fragments

WooCommerce keeps the mini-cart in the header current via AJAX (get_refreshed_fragments) — on every page, even with an empty cart, and past every cache. On many shops this is the single most frequent request overall. Check whether your theme can live without it (static cart counter, or update on click) and disable the fragments — there are lean snippets for that, no extra plugin needed (why that's often the better choice).

4. Clean up your payment gateways

Every active payment gateway loads at the checkout — and many load everywhere else too. Deactivate gateways you don't use (that old test gateway, the second PayPal integration), and check in the network tab which payment scripts load on your homepage. Anything that has no business there can be limited to the checkout page with a small snippet.

5. Fewer fields, fewer plugins, less recalculation

Every additional checkout field and every checkout-customization plugin lengthens the recalculation chain. The honest question per field: do you need this information before the purchase — or can you ask afterwards? Fewer required fields are doubly good: a faster till and measurably fewer abandonments.

6. Shorten the path: express checkout

Sometimes a shorter path beats any faster one: Apple Pay / Google Pay directly on the product page skips the address form and card entry entirely — address and payment come from the wallet. For mobile buyers (your majority), this is often the single biggest conversion lever at the till.

And if all that isn't enough: the architecture answer

If hosting, Redis, fragments, and gateways are clean and the checkout still feels sluggish, you're hitting the same limit as the rest of the shop — just earlier, because the checkout is never rescued by a cache: the rendering model of WordPress itself.

That's exactly why, in a headless setup, the checkout gets a new home too: it runs as a lightweight Next.js page (loads in sub-seconds, reacts instantly), and the order goes to your existing WooCommerce via REST API — order management, emails, stock, everything stays as you know it. What that means in detail and what stays exactly the same: Your WooCommerce shop is slow? You don't have to rebuild it.

The checkout checklist

| # | Lever | Effort | Impact | |---|---|---|---| | 1 | Measure the checkout separately (update_order_review duration) | 15 min | diagnosis | | 2 | Redis object cache + PHP 8.2+ | small (hosting) | large | | 3 | Disable cart fragments | small | medium–large | | 4 | Remove unused gateways, limit scripts to checkout | small | medium | | 5 | Thin out checkout fields & plugins | medium | medium + fewer abandonments | | 6 | Express checkout (Apple/Google Pay) | medium | large (mobile) | | 7 | Architecture limit? → headless checkout | project | checkout < 1 s |

Where does your till lose customers? Measure your shop in 30 seconds

The free WooCommerce speed check shows you your shop's performance and LCP for mobile and desktop — plus an honest assessment of whether your problem lives at the checkout, in your hosting, or in the architecture.

---

Want the next performance and build guides — including all the pitfalls? Subscribe to the "Built with AI" newsletter.

Prefer done-for-you? Drop me a line — making slow WooCommerce shops fast is my day job.