Your store is probably not slow for you. It is slow for the people who are about to buy. WooCommerce keeps cart, checkout and my account out of the page cache on purpose, and the moment a visitor picks up a cart cookie, most caching setups stop serving them cached pages at all. From that click onward, every page they open is built from scratch: PHP runs, the database is queried, the theme renders.
Which means the speed test you ran on the homepage measured the fastest visitor you have — a stranger with an empty basket. The slowest experience on your store belongs to the person furthest down the funnel. That is the frame for everything below: seven causes that are genuinely worth your time, sorted by who feels them, and the one that is almost always first.
There are two versions of your store
A cached page is a file. A visitor asks for it and the server hands it over without running WordPress at all. That is why an optimised catalogue page can come back in a few dozen milliseconds and why homepage scores look reassuring.
A shop cannot work that way end to end. WooCommerce’s own documentation names the three pages that have to be excluded: “Cart, My Account, Checkout. These pages need to stay dynamic since they display information specific to the current customer and their cart” (verified August 2026). Cache them and you serve one shopper someone else’s basket, someone else’s address, someone else’s order history.
The part people miss is that the exclusion is not limited to three URLs. The same documentation lists the cookies that should bypass the cache — woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed and the store-notice cookie. A visitor who has any of those is a visitor your cache is instructed to skip. Adding one product to a basket therefore moves that person out of the fast store and into the slow one, for the rest of the session, on every page they open next.
| The cached store | The uncached store | |
|---|---|---|
| Who gets it | A logged-out visitor with no cart and no WooCommerce cookies | Anyone holding a cart or a session, plus every logged-in customer |
| What the server does | Returns a stored file; WordPress does not run | Boots WordPress, loads plugins, queries the database, renders the page |
| Which pages | Home, catalogue, product pages, posts | Cart, checkout, my account — and every other page, once a cart cookie exists |
| What a caching plugin can do | Nearly everything | Nothing directly; only an object cache and cheaper code help |
| What a homepage speed test measures | This one | Not this one |
| What it is worth to you | First impressions and bounce rate | Orders |
So “my store is slow” is two questions wearing one coat. Is the cached path slow — images, fonts, render-blocking assets, a theme doing too much? Or is the uncached path slow — the server work that has to happen fresh on every single request from anyone holding a cart? They have different causes and different fixes, and only the second one costs you orders.
The seven causes, and who feels each one
In the stores we audit, the same seven things account for nearly all of it. The middle column is the one worth reading twice: it tells you whether a fix protects your bounce rate or your revenue.
| Cause | Who feels it | How it shows up | What actually fixes it |
|---|---|---|---|
Bloated autoloaded options in wp_options | Everyone on the uncached path — every request, before a single line of your page exists | A slow, flat TTFB on cart, checkout and account that no caching plugin improves | Audit what is autoloaded, remove leftovers from removed plugins, stop autoloading anything large |
| Cart fragments firing where they are not needed | Buyers, and anyone on a theme with a mini-cart widget | An extra uncached AJAX request per page load, often the slowest call in the waterfall | Move to the Mini-Cart block, or scope the script to the pages that use it |
| Plugins that run on every request | Everyone, but the uncached path pays it repeatedly | Server time grows with each addition, and never comes back when a feature is switched off | Measure per-plugin cost, remove what is dormant, replace the expensive ones |
| Product images shipped at full size | Cached visitors most, on mobile data | Poor LCP on category and product pages; heavy pages that look fine on a desk connection | Correct sizes, modern formats, lazy loading below the fold |
| An unindexed or overgrown database | Buyers and admins | Filtering, search and the Orders screen crawl while the homepage stays fine | Clean expired transients and orphaned meta, rebuild lookup tables, index what is queried |
| Hosting that shares CPU with strangers | Everyone, unpredictably — worst under load | The same page takes 400ms at 3am and 3s at 8pm, with no change on your side | A plan with real resources, once you have confirmed the code is not the cause |
| Third-party scripts in the front end | Cached visitors, and interaction responsiveness for all | Long tasks and delayed clicks; the page looks ready but does not respond | Remove the trackers nobody reads, defer the rest, keep checkout clean |
Notice how few of these are the server. That is the pattern behind the most common opening line we get: we think we need a bigger plan. Sometimes true. Usually the store is spending its budget before the server ever gets a chance.
Caching is not the first fix — the database usually is
On a store, caching is the second fix. The database is the first. This is the opposite of the usual advice, and the reason is arithmetic rather than opinion: a cache helps the requests it is allowed to answer, and on a shop the requests that matter most are the ones it is forbidden from answering. Every cart page, every checkout step, every account page is a full WordPress boot. Make that boot expensive and you have made buying expensive.
The clearest example is autoloaded options. WordPress keeps a set of wp_options rows marked to load on every single request, before your theme runs, before WooCommerce decides what the page is. Plugins write to it, and plugins that are deleted frequently leave their rows behind. Nothing warns you, because nothing is broken — the request just costs a little more, forever.
WordPress core now treats this as a performance problem in its own right. Since WordPress 6.6, an option saved without an explicit instruction and larger than 150,000 bytes is no longer autoloaded by default (the threshold is filterable via wp_max_autoloaded_option_size), and Site Health raises a critical issue when the total autoloaded options on a site exceed 800 KB — Make WordPress Core, June 2024, verified August 2026. Site Health is in your admin right now, under Tools. On a store that has been running for a few years and has tried a few plugins, that check is worth reading before you buy anything.
The second example is the one that sends people looking at their traffic graphs. A store owner tells us checkout got slow and assumes a spike in visitors caused it. It rarely is. It is usually the cart fragments call — the AJAX request that keeps a mini-cart counter accurate — running on pages that have no mini-cart to update. WooCommerce’s developer documentation is direct about the history here: before WooCommerce 7.8 “the cart fragments script was enqueued on every page load in a WooCommerce [site] even if the mini-cart widget wasn’t present on the page”, producing “unnecessary additional AJAX requests to the server”. The recommended replacement is the Mini-Cart block, which “does not use the cart fragments API” (verified August 2026). Plenty of themes still ship the old behaviour.
Both problems share a shape. They add a fixed cost to every uncached request, they are invisible in a homepage score, and no amount of caching touches them.
What to do, in order
One thing at a time, measuring between steps. Fixing six things at once tells you the store got faster and nothing about which change did it.
- Measure the uncached path, not the homepage. Add a product to the cart, then time a category page, a product page and checkout as that same visitor. That is your real number. Checkout has its own arithmetic on top of this — every field change is another round-trip.
- Read Site Health and the autoload total. If it is flagged, find out what is in there before touching anything else. Leftovers from uninstalled plugins are the usual finding.
- Check what your theme does with cart fragments. If the script loads on pages with no mini-cart, that is a request per page load you are not using.
- Cost the plugins. Not by counting them — by measuring what each adds to a request. One forgotten plugin, added for a single feature, routinely outweighs the rest combined.
- Clean the database. Expired transients, orphaned meta from deleted products, lookup tables that were never rebuilt after a bulk import.
- Then cache, properly. Page cache for the catalogue, object cache for the queries, cart and checkout excluded, and the WooCommerce cookies in the bypass list.
- Then images and third-party scripts — the part that finally moves the number your visitors see first.
Hosting sits deliberately at the end. Move it up the list only when the evidence points there: the same page timing differently at different hours, with nothing changed on your side. If it is that, the fix is a move, and the risks are covered in migrating a store without losing orders.
When it is not worth optimising
If your store gets very little traffic, speed is not your problem. Shaving 800ms off a checkout that forty people a month reach will not produce sales that were never coming. At that stage the honest answer is that the money belongs somewhere else — the product page copy, the photography, how people find you at all. Come back to speed when there is enough traffic for a percentage to mean something.
And do not optimise a store you are about to rebuild. If the theme is being replaced in two months, tuning the current one is work you are paying to throw away. Wait, then build the new one with the constraints known up front.
Where it does pay: a store with real traffic and a checkout that visibly stalls, or a catalogue that has grown past what the original build was designed for. That is what our WooCommerce speed optimisation work is, and it starts by measuring the uncached path rather than the homepage. If the site is not a shop, the same approach without the cart complications is WordPress speed optimisation.
Frequently asked questions
Why does my store score well on PageSpeed but feel slow to customers?
Because a speed test on your homepage measures the fastest visitor you have: a logged-out stranger with no cart, served a cached page. As soon as someone adds a product, WooCommerce sets a session cookie and that visitor stops receiving cached pages for the rest of the visit. The score is real, it just describes the half of your traffic that was never going to buy anything on that page load.
Should I disable WooCommerce cart fragments?
Only after you know what uses them. Cart fragments are the AJAX call that keeps a mini-cart counter up to date without a page reload, and disabling it on a theme that relies on it leaves customers looking at a cart that says zero. The supported route is WooCommerce’s own: use the Mini-Cart block, which does not use the cart fragments API, or limit the script to the pages that genuinely need it.
Can I cache the cart and checkout pages?
No, and you should not try. WooCommerce’s documentation names cart, checkout and my account as pages that have to stay dynamic, because they show information specific to that customer and that cart. Caching them serves one shopper another shopper’s basket. Speed on those pages comes from making the uncached request cheap, not from caching it.
Will a bigger server fix a slow WooCommerce store?
It shifts the ceiling, it does not fix the cause. More CPU makes an expensive uncached request finish sooner while you keep paying for it on every cart, checkout and account page load. If the request is expensive because of autoloaded options, uncontrolled plugin queries and unindexed lookups, a bigger machine buys you time rather than performance. Measure the request first, then decide whether the hardware is genuinely the limit.
How many plugins are too many for a WooCommerce store?
The count is the wrong number. Thirty light plugins that load nothing on the front end cost less than three that each add a stylesheet, a script and a database query to every page. What matters is how many of them run on the uncached path — the ones that touch cart, checkout or session data on every request are the expensive ones, regardless of how many icons sit in your admin menu.
What speed should I actually aim for?
Use the Core Web Vitals thresholds, measured on real visitors rather than a lab test: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less, judged at the 75th percentile of page loads and split between mobile and desktop (web.dev, verified August 2026). Then check the same numbers on a product page and on checkout, not only on the homepage.
Sources (verified August 2026): WooCommerce — Configuring caching plugins; WooCommerce — Best practices for the use of the cart fragments API; Make WordPress Core — Options API: disabling autoload for large options; web.dev — Web Vitals.