Why your WooCommerce store is slow, and how to fix it

Almost every slow WooCommerce store we have taken over was slow for a configuration reason, not a code reason. That is good news: configuration is cheaper to fix than architecture.

Work through these in order. Do not skip to the interesting ones.

1. Is there a persistent object cache?

Check this first. It is the most common cause by a wide margin.

WordPress makes a large number of repeated database queries per request. Without a persistent object cache, every one of them hits the database, every time, for every visitor.

With Redis or Memcached, repeated query results are held in memory. On the stores we have inherited, enabling this has routinely done more for admin and cart response times than any amount of frontend work.

Most hosting plans do not enable it by default. Many store owners have never been told it exists.

How to check: look for a persistent object cache in your site health information, or ask your host directly whether Redis or Memcached is available and active. “We have caching” usually means page caching, which is a different thing.

2. How many plugins are active, and what do they do?

Each active plugin runs code on requests, and some run code on every request whether or not it is needed.

The specific things to look for:

• Plugins doing work on the front end that only relate to admin functions
• Two or more plugins solving broadly the same problem
• Plugins abandoned by their developers
• Anything installed for a campaign or experiment that ended

Deactivating is not enough — delete what you are not using. Deactivated code still sits on disk and still represents a security surface.

3. Is page caching configured correctly?

Page caching serves a static copy of a page rather than generating it per request. It is enormously effective on catalogue and content pages.

It must never cache cart, checkout or account pages. If it does, customers see one another’s carts and totals. The resulting bugs appear random and intermittent, which makes them expensive to diagnose unless somebody suspects the cache.

Correct exclusions are the difference between page caching being a large win and being an incident.

4. Is the store still on legacy order storage?

WooCommerce historically stored orders in the WordPress posts table, alongside pages and blog posts. That works until order volume grows, at which point order queries compete with content queries for the same indexes.

High-Performance Order Storage moves orders into purpose-built tables. If your store predates it and has never migrated, admin and reporting are doing far more work than they need to.

Migrating is a configuration change with a synchronisation step, not a rebuild. On a store with meaningful order history the difference in admin responsiveness is immediate.

5. Are the images doing damage?

Common and easily fixed:

• Originals uploaded at full camera resolution and scaled down in the browser
• No modern formats served
• No explicit width and height, causing layout shift as they load
• Every image loading eagerly, including those far below the fold

Product galleries are usually the worst offender, because they contain the most images on the most commercially important template.

6. Is the database carrying dead weight?

Over years, a WooCommerce database accumulates:

• Expired transients that were never cleaned up
• Post revisions, sometimes hundreds per page
• Orphaned metadata from plugins removed long ago
• Autoloaded options — settings loaded into memory on every request

That last one deserves attention because it is invisible. Plugins add autoloaded options freely and rarely clean up on uninstall. The table grows quietly for years, and every page view carries the weight.

Checking the size of your autoloaded options is quick, and trimming it is one of the safest wins available.

7. Is the hosting adequate at all?

If the first six are addressed and the store is still slow, the infrastructure may simply be undersized: insufficient PHP memory, an outdated PHP version, a database server shared with too many neighbours, or no CDN in front of static assets.

At that point the fix is a hosting move, not more optimisation. Specification detail is in running WooCommerce properly.

Measure admin and front end separately

They have different causes and different fixes.

A fast storefront with a slow admin points at the database, legacy order storage, or plugins doing heavy work on admin screens. Page caching hides frontend problems from you while doing nothing for the people actually running the store.

If your team complains the site is slow and your monitoring says it is fast, this is usually why.

What this costs

Most of the above is configuration and hosting rather than development. That means the fix is normally faster and cheaper than the rebuild people often assume they need.

We audit before quoting performance work, because quoting a rebuild for a store that needs an object cache switched on would be charging for the wrong job.

A diagnostic session, in order

If you are working through this yourself, this is the sequence that finds problems fastest.

Measure first, on a real page. A product page and a category page, on mobile, throttled. Note Largest Contentful Paint, total transferred bytes and main-thread time. Without a baseline you cannot tell whether anything you do helps.

Check the object cache. One question to your host. Five minutes.

Count and identify plugins. How many are active, and can somebody name what each does?

Check the PHP version and memory limit. Both are visible in site health.

Check order storage mode. Legacy or High-Performance Order Storage.

Look at the autoloaded options total. Anything unusually large points at plugin residue.

Test the admin separately. Load an order list and a product edit screen. If these are slow while the front end is fast, page caching is hiding a database problem.

Only then look at the theme and images. They matter, and they are rarely the largest contributor.

That order is deliberate: it goes from cheapest-to-check and highest-impact toward most-effort and lowest-impact. Working the other way round is how people spend a week optimising images on a store with no object cache.

When it is genuinely a code problem

Sometimes the configuration is right and the store is still slow. The usual culprits:

• A plugin running expensive queries on every page load, often something that should only run on a single template
• Custom code in the theme doing database work inside a loop
• An external API called synchronously during page render, so the store is as slow as somebody else’s server
• Missing database indexes on custom tables added by a plugin

These need profiling to find rather than guessing. But they are the minority, and checking them before the configuration items above wastes the expensive diagnostic effort on the least likely cause.

Keeping it fast

Performance is not a one-off project. Stores slow down again, predictably, as plugins are added and the database grows.

Re-run the diagnostic sequence twice a year, and always before a peak trading period. It takes an hour once you have done it once, and it catches degradation while it is still cheap to reverse.