A slow WooCommerce store costs money, not just patience. The longer the checkout takes to load, the more customers leave before they pay. What makes a store sluggish is rarely one thing, but a combination of dynamic pages that cannot be cached outright, a database that has swollen over time, and a host not built for e-commerce. This guide covers where the time actually goes in a store, and the fixes that make a real difference. No invented numbers, just the causes we see again and again and what you do about them.
Why a store is harder to speed up than a blog
An ordinary site can serve almost every page from cache: the same HTML to every visitor. A store cannot do that outright. The cart, the checkout and My Account are personal to each logged-in visitor, and they must be rebuilt on every request. That is why the general advice to “turn on caching” is not enough for WooCommerce. The challenge is to cache everything that can be cached, product lists, category pages, the front page, while the dynamic pages stay dynamic. Get that boundary wrong and you risk either a slow store or, worse, one customer’s cart showing to another.
Caching for dynamic pages, done right
The answer is page caching with exception rules. Most of the store is then served from cache, fast and without PHP even starting, while cart, checkout and logged-in views always go live. On Celestio this is exactly how the platform is built: full page caching where you control the rules, so checkouts and logged-in views stay dynamic while everything else is cached. What you want to make sure of, whatever your host:
- Cart, checkout and my-account are excluded from page cache.
- WooCommerce cookies that mark a non-empty cart bypass the cache, so no one sees a cached page with the wrong cart.
- Product and category pages are cached, and the cache clears automatically when you change a product or a stock level.
Beyond page cache, an object cache layer for database results helps on heavy stores, because it offloads repeated database queries between page loads. It is a layer you add at the server level, and worth asking your host about if the store is large.
The database that swelled over time
A store that has been around a couple of years often carries a database full of data no longer needed. That slows every query, especially in the admin and at checkout. The most common sources of bloat:
- Expired transients. Temporary cache entries in wp_options that were never cleaned out.
- Abandoned carts and old sessions. These can reach hundreds of thousands of rows on an active store.
- Post revisions. Each product can carry dozens of saved versions you never need.
- Logs and data from uninstalled plugins. Tables left behind long after the plugin is gone.
An autoloaded options row that has grown large is a classic, invisible brake, because it is read on every single page load. With SSH access you can measure that directly and clean it with WP-CLI rather than guessing.
A fast store is the sum of small, boring decisions: the right cache boundaries, a tidy database, and a host running a modern PHP version. No single button makes it fast, but every brake you remove shows up at the checkout.
The PHP version and the server underneath
WooCommerce is PHP-heavy, and the PHP version matters a lot. Newer versions run the same code faster and also receive security fixes. Run your store on a PHP version several years old and you leave performance on the table without doing anything else. Check your version and plan to stay on one that is still supported. Just as important, the store should not share an overloaded server with hundreds of other sites, because your checkout then competes for the same processing power every time someone shops. Per-site PHP, where you control the version and resources for your store alone, removes that uncertainty.
Measure before you optimise
Never guess where the bottleneck is. Measure first, so you fix the right thing:
- Test both a product page and the checkout, not just the front page. They behave completely differently.
- Look at time to first byte to see whether the server or PHP is slow before the page even starts to render.
- Use Query Monitor to find slow database queries and plugins that eat time.
- Measure a logged-in view, not only as a logged-out visitor, because that is where caching does not help.
Most of these fixes you can do yourself, but they require access to the server and time to measure. If you want a store that already sits on a platform with page caching and rules built for WooCommerce, per-site PHP and real access to measure, read more about our platform and about how we think about running WooCommerce. You can also start an account and move the store across.