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.
Source | What they found | The bottom line |
Ecommerce sites loading in 1 second convert at 3.05%, those loading in 5 seconds convert at 1.22% | A 2.5x conversion gap, purely from speed | |
A 0.1-second mobile speed improvement lifted retail conversions by 8.4% and average order value by 9.2% | Tenths of a second move real revenue, not just page speed scores | |
70.22% of online shopping carts are abandoned, based on 50 combined studies | Checkout is where most of your lost revenue ends up | |
39% of abandonment is caused by unexpected extra costs at checkout, the top reason given | Speed fixes half the problem,pricing transparency fixes the other | |
Fixing checkout UX issues can lift conversion by up to 35.26% on the average large site | Checkout is the single highest-leverage page on an ecommerce site |
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.
Page type | Who it belongs to | Can it be cached? |
Homepage, category, product, blog, about | Everybody who visits | Yes |
Cart, checkout, My Account | One specific shopper at a time | Not advised |
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:
Cookie | What it does |
wp_woocommerce_session_ | Links the visitor to their cart in the database |
woocommerce_cart_hash | Fingerprints the contents of the cart |
woocommerce_items_in_cart | Flags that the shopper has items in their cart |
woocommerce_recently_viewed | Powers the "recently viewed" widget |
store_notice[notice_id] | Remembers store notices the shopper has dismissed |
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:
Where | Queries before | Queries after | Improvement |
Orders API (admin) | 271 | 132 | ~51% |
Checkout, no object cache | 204 | 172 | ~15% |
Checkout, with object cache | 127 | 115 | ~9% |
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:
What changed | Who'll notice the difference |
Proper database indexes on shipping zones | Stores with lots of zone-based shipping rules |
Last-Modified caching on Store API product endpoints | Headless and React-driven storefronts |
Silent nonce bug on cached checkouts, now fixed | Any store running aggressive edge caching |
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.
Layer | What it caches | What it handles | Where it can't help |
Edge caching | Full rendered HTML at a point of presence | Homepage, category, product, blog, marketing | Cart, checkout, My Account |
Object caching | Database query results in memory | Shipping, tax, transients, cart lookups | Rendered page output |
Application caching (WP Rocket) | Static HTML, fragments, AJAX | WooCommerce-safe exclusions, get_refreshed_fragments | Dynamic per-session HTML |




