Most WordPress performance advice is written for brochure sites.
That is 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.
So if your store is slow, the goal is not to "optimise everything." The goal is to reduce the work the site keeps doing over and over.
That is what counts.
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.
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
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.
Good targets:
- 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
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
WordPress has an internal object cache that stores reusable bits of data in memory while a request is running. Official WordPress documentation also 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.
This is important because page cache and object cache solve different problems.
Page cache stores the finished page.
Object cache stores the reusable pieces used to build the page:
- 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
This 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. 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.
That means 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
- 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
- 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
- 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.
- 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
- short-lived helper data
They are not good for:
- critical business state
- anything that must always exist
- 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.
Bad caching serves yesterday's answer to a question that should have been answered live.
Good caching usually looks like this:
- 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 usually looks like this:
- 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.
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.