Why your WooCommerce checkout is still slow

Picture this. A customer is ready to buy. They picked their products, added them to the cart, and entered their card details.  

Then the page hangs.  

Four seconds. Five.  

They close the tab and never come back. 

It happens in WooCommerce stores every day, quietly, and it costs more than most retailers realize. Portent's research across 100 million sessions found that ecommerce sites loading in one second convert at 3.05%, while sites loading in five seconds drop to 1.22%.  

On a $10M revenue store, it's six figures sitting behind a spinner. 

The reason is structural, has been for over a decade, and unfortunately no plugin fixes it on its own. There is some encouraging news though: WooCommerce 10.7, released April 14, 2026, , paired with WordPress 7.0 landing on May 20, is the first time in years both layers have moved on this in the same window. 

Let’s dive into what’s been updated, find out if your checkout speed is holding your store back – and what you can do about it.  

Checkout speed is a ‘revenue’ problem 

Before we get into the caching layers and query counts, it's worth remembering what's at stake. Checkout speed looks like a technical problem but behaves like a revenue problem. The gap between a fast checkout and a slow one shows up in your numbers, not just in PageSpeed Insights. 

Every technical fix later in this post exists to close that gap. And it isn't just a UX or conversion point. Page speed feeds directly into Core Web Vitals and the ranking signals behind them, so the same work protects your search visibility. 

"Checkout speed is an SEO signal. Core Web Vitals feed into rankings directly, and shoppers bailing out of a slow checkout send behavioral data back to Google.  Most stores I audit are losing authority on pages they've never thought about as rankable – but every piece of data counts." 

Daphne Monro, Head of Website & Content at hosting.com  

The dynamic caching problem most advice ignores 

Most speed advice lets you down on checkout for one reason: your store is really two different types of pages, and almost all the advice is aimed at the wrong type. 

Cart and checkout can't be cached because a small set of cookies tracks what's happening for each shopper individually. Without them, the store wouldn't know whose cart belongs to whom: 

Cache one of those pages and serve it to the next visitor and you'd hand them the previous shopper's cart. Which is why WooCommerce's own documentation is firm: cart, checkout, and My Account should never be cached.  

Every checkout request bypasses page caching and falls through to PHP. WordPress processes the request, loading the session and recalculating products, taxes, shipping and coupons. 

On a plugin-heavy stack that's 500ms to 2 seconds, on the one page where money changes hands. 

The block-based checkout, default for new installs since WooCommerce 8.3 in November 2023, adds another wrinkle. The React-powered block ships around 300kB of JavaScript, roughly triple the old short code checkout. 

What WooCommerce 10.7 actually changed 

Headlines calling 10.7 "the 51% query reduction release" are right on the number. But that 51% is on the admin-side orders API that powers the WordPress dashboard and most third-party fulfillment tools, not checkout. All that said, still a big win for high-volume stores. 

Checkout itself picked up a smaller improvement: 

The pattern is the useful part. Those gains compound if you've got object caching running and barely register if you haven't. Which tells you where to spend your attention next. 

A few other changes worth knowing about: 

Most of this builds on 10.5's Product Object Caching work. If you're on pre-10.6 core, HPOS is the other switch worth flipping. 

A note on that nonce fix. Before 10.7, edge-cached checkout HTML could carry an expired nonce.  

A shopper would click "apply coupon," WooCommerce would quietly reject the POST with a 403, no error, no banner.  

They'd assume the site was broken and leave. 10.7 fetches a fresh nonce on load. If you run aggressive edge caching, retest checkout after you update, because the only way to know you had this bug is to confirm it's gone. For the full technical rundown: the WooCommerce developer blog. 

The hosting layer is where the gains compound or get wasted 

Every WooCommerce store sits on three possible caching layers, each solving a different slice. All three working together and core updates compound into something customers can feel. Miss one and the others can't cover forit.