A slow store costs money. Shoppers who wait for a product page to load, or watch a spinner after clicking “Place order”, often leave and do not come back.
WooCommerce itself is not slow, but a store asks far more of a server than a blog does. Here are the usual causes, roughly in the order worth checking them.
1. The pages that matter most cannot be cached
On a blog, a page cache saves a finished copy of each page and hands it to every visitor. That is why blogs feel fast even on small servers.
A store’s most important pages are different. The cart, checkout and my account pages are personal to each shopper, so they must be built fresh every time. A well-configured cache skips them on purpose, as it should.
That means two things:
- Make sure everything else is cached. Home, category and product pages for visitors who are not logged in should come from the cache. If they do not, fix that first.
- Make the uncached pages as cheap as possible. The rest of this list is mostly about that.
2. No persistent object cache
Every uncached page runs many database queries, and many of them ask the same questions again and again: store settings, product data, tax rates.
By default, WordPress forgets the answers at the end of each request. A persistent object cache, backed by Redis or Valkey, keeps them in memory between requests, so the database is asked far less often. For cart, checkout and the admin dashboard, this is often the single biggest improvement you can make.
3. A bloated database
Stores collect data quickly, and some of it is never cleaned up:
- Autoloaded options. WordPress loads every option marked “autoload” on every page. Plugins you deleted years ago can leave megabytes of data behind in the
wp_optionstable, slowing every single request. - Scheduled actions. WooCommerce and many plugins use a task queue that keeps a log of completed and failed jobs. On a busy store, that log can grow to millions of rows.
- Expired transients, old sessions and post revisions add up too.
A database cleanup, carefully done and with a fresh backup first, can make the admin and checkout noticeably faster.
4. Orders stored the old way
Older stores keep orders in the same tables as blog posts, which gets slow as order numbers grow. WooCommerce now offers High-Performance Order Storage (HPOS), which keeps orders in their own tables, and it is the default for new stores. If your store is older, check under WooCommerce → Settings → Advanced → Features whether it is turned on. Test it on a staging copy first, since some older plugins may not support it.
5. Too many plugins doing too much
The number of plugins matters less than what they do on each page. Watch out for:
- plugins that run heavy queries on every page, such as some “related products”, analytics or reporting tools,
- several plugins doing the same job,
- page builders that load large amounts of CSS and JavaScript on every page,
- plugins that call external services while a page is being built.
Turn plugins off one at a time on a staging copy and measure. The culprit is usually one or two plugins, not all of them.
6. Heavy images and front-end weight
Large product photos straight from a camera, sliders on the home page, and many third-party scripts (chat widgets, tracking pixels, review badges) slow down what shoppers actually see, even when the server responds quickly.
- Resize and compress product images, and use modern formats like WebP.
- Load scripts only on the pages that need them.
- Lazy-load images below the fold.
7. The server is simply too small
If you have done all of the above and the store still slows down at busy times, look at the server. Memory constantly full, swap in use, or CPU pinned near 100% during sales all mean it is time for more resources. Our guide on how much RAM and CPU WordPress needs explains what to watch.
Shared hosting is a common cause here: you share CPU and memory with other customers, and a store’s uncached pages suffer first. Moving to a VPS gives you resources nobody else can borrow.
How to tell what is slow
Measure before you change anything:
- Test a product page, the cart and checkout separately, as both a visitor and a logged-in shopper.
- Compare cached and uncached pages. If even cached pages are slow, the problem is the server or the network, not WooCommerce.
- A query-monitoring plugin, used on a staging copy, shows which plugins run the most database queries and how long they take.
Where Rubuz fits
Rubuz runs WooCommerce on a VPS you own, with a LiteSpeed page cache that skips cart and checkout correctly, a Valkey object cache already set up, and staging sites for testing changes like HPOS safely. See how it works for WooCommerce developers.