How to cache a WooCommerce store the right way
Caching is the biggest speed win a WooCommerce store has — and the fastest way to break carts and leak stale prices if it is done carelessly. Here is how to get the win without the damage.
Most WooCommerce speed advice starts and ends with “install a caching plugin.” That is half right. Caching genuinely is the single biggest lever on a store’s public pages — and it is also the single most common cause of “my cart empties itself” and “a customer saw someone else’s details.” The difference is entirely in what you cache and what you deliberately never touch.
The two kinds of caching, and what each is for
These do different jobs and you want both:
- Page caching stores the finished HTML of a page so the next visitor is served a file, with WordPress never running. It makes home, shop and category pages extremely fast. It must exclude anything personalised.
- Object caching (Redis or Memcached) keeps the results of database queries in memory, so repeated queries are instant. This is what speeds up the pages a page cache cannot serve — logged-in browsing, the admin, and the queries behind checkout.
A store with page caching but no object cache still crawls the moment a customer logs in or reaches checkout, because every one of those page loads runs the full application against the database.
What you must never full-page cache
This is the rule that prevents every caching disaster. These pages are unique to each visitor and must be excluded from the page cache:
- Cart and the mini-cart / cart fragments
- Checkout and the order-received / thank-you page
- My Account and anything behind login
- Any page carrying a security nonce or a personalised price
Cache one of these and serve it to the next person, and you hand them a stale cart, a broken nonce, or another customer’s session. Every reputable cache plugin ships with these exclusions by default — the danger is a custom rule, an aggressive “cache everything” setting, or a CDN in front that ignores them.
Object caching is where the dynamic-page win lives
Add a persistent object cache (Redis is the usual choice) and enable it with a WooCommerce-aware drop-in. Now the hundreds of repeated option and product-meta lookups that run on every request are served from memory instead of the database. This is the change that makes logged-in browsing and the checkout path feel fast, and it is the half most stores skip because it needs a server component rather than just a plugin.
One honest caveat: object caching accelerates queries, it does not fix a fundamentally slow one. If a reporting plugin runs an unindexed query against a huge orders table, caching the result helps the second visitor and does nothing for the first. Fix the query and cache it.
Browser and CDN caching for the static half
Images, CSS, JavaScript and fonts should be served with long cache lifetimes and from a CDN close to the shopper. This takes load off your origin and cuts real time from every page. The rule mirrors the one above: cache static assets hard at the edge, but make sure the CDN is not also caching your HTML pages unless it too respects the cart/checkout exclusions.
Keep the cache fresh: purging on change
A cache is only safe if it clears itself when the underlying thing changes. Configure automatic purging when a product, price or stock level updates, and when an order changes state, so a shopper never sees last week’s price or an out-of-stock item as available. “Cache forever, purge manually” is how stores end up selling at the wrong price. Warming the cache after a purge — pre-loading key pages — keeps the first visitor from paying the full render cost.
The mistakes that cause 90% of caching problems
- Caching cart, checkout or account pages — the classic cart-leak.
- A CDN set to “cache everything” sitting in front, overriding the plugin’s exclusions.
- Caching pages that contain a security nonce, which then expires and breaks forms.
- No object cache at all, so logged-in and checkout pages get no benefit.
- No automatic purge on price/stock change, so customers see stale prices.
Notice that none of these is solved by switching cache plugin. They are configuration, and that is where the real work is.
Common questions
Which WooCommerce cache plugin is best?
The plugin matters less than the configuration. Any of the well-known full-page cache plugins works well once cart, checkout, account and any personalised page are excluded and object caching is enabled. A perfectly configured free plugin beats a premium one set up carelessly.
Does caching speed up checkout?
No. Checkout is per-visitor and cannot be full-page cached, so a page cache does nothing for it. What helps checkout is object caching (Redis) plus fixing the underlying database queries. Caching speeds up the pages around checkout, not checkout itself.
Redis or Memcached for WooCommerce?
Either works; Redis is the more common choice and is well supported by WooCommerce object-cache plugins. The important thing is that a persistent object cache exists at all, so repeated database queries are served from memory instead of hitting the database every time.
Why did caching break my cart or show the wrong price?
Almost always because a personalised page (cart, checkout, mini-cart fragments) or a page with a security nonce got full-page cached and served to the wrong visitor. The fix is correct exclusion rules, not turning caching off. Cache the public pages, never the per-visitor ones.
Want caching set up so it helps, not breaks?
I configure WooCommerce caching properly — page cache, Redis object cache, CDN and purge rules — with cart and checkout safe. Tell me about your store and I’ll tell you what it needs.