Speed up WooCommerce without breaking cart and checkout

You can make WooCommerce much faster by caching the pages every shopper sees the same way, such as product, category and content pages, while cart, checkout and account pages stay fully dynamic. Most broken carts after a speed project come from ignoring that split. This guide shows which pages go where, how to verify it, and what else slows a store down once caching is in place.

Why WooCommerce is slower than plain WordPress

WooCommerce runs on WordPress, so everything that slows WordPress down applies here too: hosting, plugins, theme and images. If you haven't looked at those basics yet, start with why a WordPress site is slow.

On top of that, a store adds its own load:

• More data per page. Product pages query prices, variations, stock, tax classes, reviews and related products.
• Sessions and cookies. As soon as someone adds a product to the cart, WooCommerce starts a session and sets cookies. From then on, that visitor's requests are personal.
• AJAX requests. Add-to-cart buttons, mini carts and checkout updates all call the server through wc-ajax endpoints.
• Background work. Order emails, stock syncs, webhooks and scheduled actions run alongside normal traffic.
• Extensions. Payment gateways, shipping calculators, product filters and marketing tools each add scripts and queries.

That makes the uncached response time of a shop higher than that of a blog, and it makes caching both more valuable and more delicate.

What you can cache and what you can't

The rule is simple: if the page looks the same for every anonymous visitor, cache it. If it depends on who is looking, don't.

WooCommerce documents the pages and cookies to exclude in its guide to configuring caching plugins. The cookies that matter most are woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_*, plus the WordPress login cookies.

Cookie-based bypass

URL rules alone are not enough. Once a visitor has something in the cart, even a product page may show a mini cart with their items. A good cache setup bypasses every request that carries a WooCommerce session or cart cookie, so a shopper with a full cart never sees someone else's page.

Test cart and checkout after every change

Speed changes in a shop need a functional test, not just a speed test. After you enable or change caching, walk through the full purchase path in a private window:

1. Open a product page as an anonymous visitor.
2. Add the product to the cart and check that the mini cart updates.
3. Open the cart, change the quantity, apply a coupon.
4. Go to checkout, switch the shipping country and watch totals update.
5. Place a test order with a sandbox payment method.
6. Log in as a customer and open the account area.

Then check the response headers for the cart and checkout pages. They should show a bypass or miss, never a hit:

curl -sI https://shop.example.com/checkout/ | grep -i -E "cache|set-cookie"

Keep cached pages fresh

Caching product pages raises a fair question: what happens when the price or stock changes?

• Purge on update. When you edit a product, purge its URL and the category pages it appears on. Many caching setups do this automatically through a plugin or an API call.
• Short lifetimes for volatile pages. If stock changes constantly, give product pages a shorter cache lifetime rather than not caching them at all.
• Warm important pages. After a purge, the first visitor causes a cache miss. Warming top products and categories keeps them fast.
• Sales and imports. Before a sale starts or after a bulk price import, purge the affected pages deliberately.

Geolocation and currencies

If your store shows prices based on the visitor's country, cached pages can show the wrong tax or currency. WooCommerce offers a "Geolocate (with page caching support)" option for the default customer location, which adds a query parameter so each location gets its own cached copy. Currency switcher plugins need similar handling. Check their documentation for caching support before you rely on them.

Speed up the dynamic parts

Cart and checkout will never be cached, so their raw speed depends on the server and the code.

Cart fragments

Classic themes often load the wc-cart-fragments script, which calls the server on page load to refresh the mini cart. On a busy store that means an uncached request on top of every cached page view. Check whether your theme actually needs it. If you don't use a mini cart in the header, you may be able to drop it, and many performance plugins offer a setting for this.

Checkout

• Remove checkout fields and extensions you don't need; every shipping or payment plugin adds scripts and server calls.
• Load payment scripts only on the checkout page, not site-wide.
• Keep the number of checkout-page AJAX updates low. Each change of address or shipping method recalculates totals on the server.

Checkout responsiveness is exactly what INP measures: how quickly the page reacts when a shopper clicks or types.

Database and background tasks

• Enable High-Performance Order Storage (HPOS) if your extensions support it. It moves orders into dedicated tables instead of the posts table.
• Watch Action Scheduler. Under WooCommerce > Status > Scheduled Actions, a long list of failed or pending actions often points to a misbehaving extension.
• Add a persistent object cache (Redis or Memcached) so repeated queries for products, options and sessions come from memory.
• Move WP-Cron to a real server cron so scheduled work doesn't run inside a shopper's request.

For a detailed look at server response times, see the guide on reducing TTFB.

Images and scripts on product pages

Product galleries are often the heaviest part of a store. Use WebP or AVIF, serve sizes that match the gallery layout, and don't lazy-load the main product image, because it is usually your LCP element. Zoom, lightbox and slider scripts should load only on product pages, not on every page of the site.

Review your tracking and marketing scripts too. Each pixel, chat widget and review badge competes with the shop's own code on the main thread.

If you run or compare other shop systems, the Shopware 6 performance guide covers the same cache-versus-dynamic split for Shopware's HTTP cache.

How fast.site helps

fast.site sits in front of your WooCommerce hosting. You keep your host; you add your domain in the dashboard and switch your nameservers to fast.site. fast.site then manages your DNS, so all existing records, including MX records for your shop's email, need to be in the fast.site DNS zone.

Product, category and content pages for anonymous visitors can be served from the edge by Fast Edge Cache™, in the regions available on your plan. A cache HIT never reaches your origin, which leaves more server capacity for cart and checkout in peak hours. Cart, checkout, account pages and sessions must bypass the cache, and the fs-cache header shows BYPASS for those, so you can verify each page with the checkout test above. When prices or stock change, you purge URLs in the dashboard or via the API, and the cache warmer keeps important pages primed.

fast.site can also convert product images to WebP on the fly (AVIF depending on plan) and filter bad bots and HTTP floods at the edge before they reach your store. See the WooCommerce page and the WooCommerce integration article for setup details.

Measure your store before and after, including a full checkout run. You can start with a free 7-day trial, no credit card required.

FAQ

Can you cache WooCommerce pages?

Yes, for anonymous visitors you can cache the homepage, content pages, category archives and product pages. Cart, checkout, the account area, AJAX requests and any visitor with a cart or session cookie must bypass the cache.

Why is my WooCommerce checkout slow?

Checkout is never cached, so it shows the raw speed of your server and extensions. Common causes are slow hosting, many payment and shipping plugins, external API calls for shipping rates or tax, and frequent recalculations while the shopper fills in the form.

Does caching break the WooCommerce cart?

Only if it is configured wrongly. Problems appear when cart or checkout pages, or requests with WooCommerce session cookies, are cached. Exclude them, then test the full purchase path in two browsers at once.

How do I keep prices and stock up to date with caching?

Purge the product URL and its category pages whenever you change a product, and purge deliberately before sales or after imports. For stores where stock changes constantly, use shorter cache lifetimes on product pages.

Should I disable cart fragments?

If your theme doesn't show a mini cart, the cart fragments request is usually unnecessary load. If it does show one, keep it or switch to a solution your theme supports, and test that the cart count still updates after adding a product.