Caching is a big part of what makes WordPress sites fast, but a store isn’t an ordinary WordPress site. The home page and product pages can be cached, the cart and checkout can’t, and a cache set up wrong can show one customer’s cart to another or old prices to everyone.
This guide covers the different kinds of cache, what each of them does in a WooCommerce store, what must never be cached, and how to check that it works.
Four kinds of cache
“Cache” covers several layers that store different things. Each helps a different part of the store:
| Layer | Stores | Helps |
|---|---|---|
| Page cache | The whole finished page as HTML | Home page, categories, product pages and blog for visitors with nothing in the cart |
| Object cache | Results of database queries, for example in Redis | Every page, including cart, checkout and the admin |
| Browser cache and CDN | Images, CSS and JavaScript | Loading in the browser, especially on repeat visits |
| OPcache | PHP code in compiled form | Every page built by PHP |
How the layers fit with the rest of WordPress is explained in how WordPress works: architecture and performance.
What can be cached
Pages that are the same for every visitor can live in the page cache: the home page, categories, product pages, blog posts and information pages. For a new visitor with nothing in the cart who isn’t logged in, that’s typically a large share of page views, and this is where the page cache makes the biggest difference. The server sends a finished page instead of building it with PHP and the database.
If the store shows something that differs from customer to customer on those pages, such as a mini cart in the header, prices by country or “recently viewed products”, it has to be fetched separately after the page is shown, or the page can’t be cached for everyone. WooCommerce does this itself for the mini cart, with cart fragments. When that slows the store down is in our guide to slow add to cart and cart fragments.
What must never be cached
Cart, checkout and My account are different for every customer and must never be in a page cache. WooCommerce’s own guide to configuring caching plugins names exactly those three pages and the cookies WooCommerce uses to keep track of the cart:
woocommerce_items_in_cartandwoocommerce_cart_hash, which show that the customer has something in the cart and when it changes.wp_woocommerce_session_, which is the customer’s session.
Many caching plugins and hosting providers skip the cache when those cookies are set. That means as soon as a customer has added something to the cart, every page they see is built from scratch. The same goes for logged-in customers. So it’s the dynamic pages that decide how fast the store feels to the people closest to buying. What makes checkout in particular slow is in our guide to a slow WooCommerce checkout.
When the cache shows the wrong page
A misconfigured page cache causes errors that can be hard to recognize, because they only hit some customers:
- Another customer’s cart or name: Cart, checkout or My account has ended up in the cache.
- Old prices or wrong stock status: The cache isn’t cleared when a product changes, or when a sale starts and ends.
- Forms that fail: WordPress uses security tokens, called nonces, that by default expire after 12 to 24 hours. If a page stays in the cache longer than the token’s lifetime, forms and buttons on it can stop working.
- Checkout that keeps loading: A cached copy of checkout or its scripts.
Check that the three pages and the cookies are excluded, that the cache is cleared when products and prices change, and that pages with forms don’t stay in the cache longer than 12 hours.
Object cache: what helps on the dynamic pages
The pages that can’t be in the page cache have to be built by PHP and the database every time. Here, an object cache is the layer that helps most. It keeps the results of database queries in memory, for example in Redis, so the next page view doesn’t have to ask the database the same thing again. It works on every page, including cart, checkout and the admin. We go through setting up Redis step by step in our guide to Redis object cache.
Without a persistent object cache, WordPress forgets the results once the page is built. With one, it remembers them across page views. We’ve compared several object cache plugins for WooCommerce in our object cache plugin benchmark. Where caching fits when troubleshooting a slow store is covered in the caching section of the troubleshooting guide.
Browser cache and CDN
Images, CSS, JavaScript and fonts rarely change and can be stored in the customer’s browser for a long time. Make sure the server sends long cache lifetimes for those files, and that file names change when the files do, so customers don’t get stuck with old versions. Many themes and plugins handle the latter themselves.
A CDN delivers the same files from servers close to the customer. If you sell mostly in one country and your server is nearby, the gain from a CDN is smaller than when customers are spread across continents. A CDN doesn’t make cart and checkout faster, because they still have to be built on your server.
OPcache
OPcache stores PHP code in compiled form, so it doesn’t have to be read and compiled on every page view. It’s on at many hosting providers and rarely needs anything from you, but it’s worth asking if you have your own server. More on the PHP side of speed is in PHP optimization in WordPress.
How to check that it works
- Open a product page in a private browser window, and look at the response headers in the developer tools (F12) under Network. Many caches set a header that says HIT or MISS. The name depends on the cache.
- Reload the page. The second view should be a HIT.
- Add a product to the cart, and open the product page again. Now it shouldn’t come from the cache.
- Go through cart and checkout in two different browsers, each with its own cart, and check that they never see each other’s content.
- Change the price of a product, and check that the new price shows right away for a visitor who isn’t logged in.
Frequently asked questions
Which caching plugin should I use?
It depends on your hosting. Many hosting providers have a page cache on the server, and then you shouldn’t add a caching plugin on top. Two page caches stacked on each other cause more errors, not more speed. Ask your provider what they have before you install anything.
Can I cache pages for logged-in customers?
As a rule, no. Pages for logged-in customers can contain names, prices and carts that only apply to them. Here, an object cache and a fast server are what make the difference.
Want help?
Caching in a store has to be set up so it makes the right pages fast and leaves the rest alone. If you’d like us to review the setup in your store, read about optimizing your WooCommerce store. We take a free look at your store first and tell you what it will take.