On this page5 sections
Most WordPress performance advice is written for brochure sites. That's part of the problem. WooCommerce stores are different: they have carts, sessions, logged-in users, account pages, checkout flows, search, filters, stock changes, and plugins doing real work on every request. A page cache can't help the cart, the checkout or a logged-in customer, which is why a caching plugin often makes the home page fast and leaves the checkout as slow as it was. So first, a quick check of the other places slowness lives (hosting, plugins, theme, images). Then the part most advice gets wrong: caching, and why page cache, object cache, browser cache and edge cache are not the same thing and solve different problems.
Where the Slowness Usually Lives
WooCommerce is not a blog. A WordPress blog is mostly static content: someone writes a post, it gets published, thousands of people read the same page, and a page cache stores it once and serves it to everyone. A WooCommerce store is different. Your cart page is unique to each visitor. Your checkout page has to be dynamic. Your My Account page is personalised. Page caching helps your homepage and category pages. It does almost nothing for cart, checkout, or any page where a customer is logged in.
Before you get to caching, check the other places slowness usually lives:
- Hosting. Cheap shared hosting means your store shares a server with hundreds of other sites. If your hosting is genuinely underpowered, upgrade. If it's decent and the store is still slow, look elsewhere first.
- PHP and database performance. More plugins and more products mean more queries per page load. The database is usually the bottleneck nobody checks: slow queries, missing indexes, bloated tables.
- Plugins. It's not the number of plugins, it's what they do. A poorly built plugin that loads JavaScript on every page and runs dozens of queries will destroy your speed even if it's the only plugin you have.
- Theme. A bloated theme with features you're not using (sliders, animations, icon libraries) loads all that code on every page, whether you use it or not.
- Images. Unoptimised images are usually the single biggest payload on a WooCommerce store. Compress them, serve WebP, use responsive sizes. I did exactly this on a project for Follio, a WooCommerce store where image optimisation was a primary performance bottleneck.
- Third-party scripts. Analytics tags, chat widgets, tracking pixels. Each one loads JavaScript from an external server, and some block rendering until they finish.
What Counts as a Real Performance Enhancement
A real improvement does one or more of these:
- reduces expensive database queries
- reduces repeated PHP work
- reduces the number of requests hitting the origin server
- reduces the amount of data the browser has to download
- improves cache hit rate without breaking dynamic WooCommerce pages
- makes the slow parts of the store faster under real traffic
If the site does less work, or reuses work it has already done, that counts.
If you get a nicer score but the cart, checkout, search, or admin still drags, that does not count for much.
What Usually Does Not Help Much
These are common fake wins:
- stacking multiple cache plugins
- improving the homepage while the revenue pages are still slow
- minifying files when the real bottleneck is database work
- deleting transients again and again without fixing the source problem
- switching on Cloudflare and assuming the origin is no longer the issue
- paying for more hosting before checking whether the application is wasting what it already has
Performance work gets expensive when nobody agrees on what the site is actually doing wrong.
What I Check First on a Slow Store
I usually want answers to these questions first:
- Which pages are slow for anonymous users?
- Which pages are slow for logged-in or session-based users?
- Is page cache configured safely for WooCommerce?
- Is object cache persistent?
- Is Cloudflare actually caching useful traffic?
- Which plugins are generating repeated work?
- Is the bottleneck in the application, the database, the host, or all three?
Once you know that, the fix gets clearer very quickly.
The Short Version
- Page cache helps public pages.
- Object cache helps repeated reads.
- Redis usually makes object cache persistent.
- Transients are temporary cache, not permanent storage.
- Cloudflare helps at the edge, not everywhere.
- WooCommerce needs dynamic pages handled carefully.
- The best optimisation is the one that removes real work without breaking the store.
If your site is still slow after a pile of "optimisations," the problem is usually not that you need one more plugin. It is that nobody has found the real bottleneck yet.
Tell me the problem and I can help with that.
For your technical person
Page cache, object cache, browser cache, and edge cache are not the same thing. People talk about caching like it is one feature. It is not.
Page cache stores the finished HTML of a page so the server does not need to rebuild it for every visitor. This is one of the biggest wins for public pages: homepages, blog posts, landing pages, category pages that are mostly the same for everyone. Bad targets: Cart, Checkout, My Account, personalised pages. WooCommerce's own documentation says Cart, Checkout, and My Account should be excluded from cache because they contain customer-specific data. Cache those badly and you start breaking commerce, not fixing it.
Browser cache tells the visitor's device to keep static files like images, CSS, JavaScript, and fonts for a while. Useful. Worth doing. Usually not the main reason a WooCommerce site is slow.
Object cache is WordPress's internal cache that stores reusable bits of data in memory while a request is running. Official WordPress documentation makes it clear that this cache is non-persistent by default: it normally disappears at the end of the request unless you install a persistent backend. Page cache stores the finished page; object cache stores the reusable pieces used to build it (query results, options, settings, taxonomy lookups, repeated plugin data). If the same expensive reads keep happening, object cache can make a real difference.
Edge cache is where Cloudflare fits. Cloudflare APO for WordPress is designed to cache HTML at the edge, not just static files. Cloudflare says this improves TTFB consistency and serves cacheable pages closer to the visitor. Their docs also say logged-in and admin users bypass the cache, and cache is invalidated quickly when content changes if the plugin is installed. That is valuable. It is not magic: Cloudflare helps when the request is cacheable, but it does not remove origin bottlenecks from logged-in, personalised, or session-based requests.
Redis: what it is and how it helps. Redis is a fast in-memory data store. In WordPress, it is commonly used as a persistent object cache backend, meaning cached objects can survive across requests instead of disappearing at the end of each page load. Without Redis, WordPress asks the database for the same repeated data, the database does the work again, and the next request asks again. With Redis, repeated lookups can be served from memory instead. Redis is often useful when the site has a heavy plugin stack, the same queries are repeated constantly, there is logged-in traffic, the admin area is busy, or filters, menus, widgets, or lookups are doing repeated reads. Redis does not fix bad code, slow external APIs, oversized media, front-end bloat, poor hosting, or broken query patterns. It helps when repetition is the problem. It does not make bad architecture good.
WordPress transients: helpful, but easy to misuse. Transients are temporary cached values with an expiration time. Without a persistent object cache, WordPress typically stores them in wp_options on single-site installs; with Redis or another persistent object cache, they can wrap the object cache instead. Two details matter: a transient is cache, not durable state, and expiration is a maximum time, not a guarantee. WordPress documentation explicitly notes that transients can disappear before the timeout, so if code depends on a transient, it must be able to rebuild it. Transients are good for cached API responses, expensive query results that can be regenerated, and short-lived helper data. They are not good for critical business state, anything that must always exist, or anything you cannot safely rebuild. Deleting transients can clean up old waste, but if a site keeps generating too many, the real fix is usually the code or plugin creating them.
Good caching vs bad caching. Good caching reduces repeated work without serving the wrong content: page cache for public pages, persistent object cache for repeated lookups, browser cache for static assets, Cloudflare or another edge layer for global delivery, sensible purge rules. Bad caching serves yesterday's answer to a question that should have been answered live: caching Cart, Checkout, or My Account; caching session-specific fragments; ignoring WooCommerce cookies and sessions; layering multiple systems that fight each other; serving stale stock, price, or account data. That is the difference between a faster store and a broken one.