Almost every WooCommerce performance investigation starts the same way. The store owner has already moved to a faster host, installed a caching plugin, and bought an image optimiser, and the site is still slow. They conclude that WooCommerce is simply heavy and give up.

WooCommerce is heavier than a brochure site, which is unavoidable when every page can carry a cart. But a store that takes six seconds to load is not suffering from that overhead. It is suffering from something specific, and in my experience it is nearly always one of four things.

The short version: Shops are slow because cart and checkout pages cannot be page-cached, because the options table has grown enormous with autoloaded junk, because product queries scan an unindexed metadata table, and because thirty plugins each add their own scripts to every page. Hosting is the last thing to change, not the first.

Why a Store Is Different From a Blog

Understanding one distinction explains most WooCommerce performance behaviour.

A blog post is the same for every visitor, so it can be generated once and served from cache to everyone. That is why brochure sites are fast almost regardless of how they are built. A store cannot do that on every page, because the cart is personal. The moment a visitor adds an item, the page has to reflect their state rather than a shared copy.

The consequence is that cart, checkout and account pages bypass page caching entirely and execute PHP and database queries on every request. Those are also the pages where slowness costs you money directly. A slow category page loses browsers; a slow checkout loses buyers.

So the useful question is never “is my site fast?” It is “how fast is my site for a logged-in visitor with something in their cart?” Test that state specifically, because it is the one your revenue depends on and the one every synthetic speed test misses.

The Four Things That Are Actually Wrong

An overloaded options table. WordPress loads a set of options on every single request, and plugins add to it freely. Uninstalled plugins routinely leave their rows behind. On older stores this table grows to tens of megabytes of autoloaded data being read on every page view including the checkout. It is invisible, it is cumulative, and it is one of the highest-return fixes available. Check the total size of autoloaded options first; if it is measured in megabytes rather than kilobytes, you have found real time.

Product queries against unindexed metadata. WooCommerce historically stored product attributes, prices and stock in a generic metadata table shared with everything else. Filtering or sorting a large catalogue means joining that table repeatedly. With a few hundred products nobody notices. With tens of thousands, category and filter pages slow to a crawl. Newer WooCommerce versions moved order data to dedicated tables specifically to relieve this pressure, and enabling that storage on a store with a long order history is usually worth doing on its own.

Plugins and External Calls

Plugin sprawl on the critical path. The problem is rarely the count itself; it is that most plugins enqueue their CSS and JavaScript on every page rather than only where needed. A booking plugin used on one page loads its assets on your checkout. The fix is unglamorous: audit what each plugin loads, dequeue assets outside their own pages, and remove anything whose function you cannot name.

Uncached third-party calls. Live shipping rates, tax lookups, currency conversion and stock checks against an external system all place a network request inside the page load. When that provider is slow, your checkout is slow, and when it fails your checkout fails. Every external call in a request path needs a timeout, a cache and a fallback. Our guide to third-party API integration covers how that should be built.

What Actually Helps, In Order

Work through these in sequence, because each one changes what the next measurement tells you.

Object caching, not just page caching. Page caching serves whole HTML pages and cannot help cart or checkout. A persistent object cache stores the results of database queries in memory and speeds up exactly the pages page caching cannot touch. For a store this is usually the single largest improvement available, and it is the step most often skipped because the caching plugin already installed gave the impression the job was done.

Database maintenance. Clear expired transients, remove orphaned metadata from deleted products and orders, and trim post revisions. On a store that has been trading for years this routinely removes a large fraction of the database. Schedule it rather than doing it once.

Then hosting. Once caching and the database are in order, hosting genuinely matters: PHP version, available memory, whether the database is on the same machine, and whether you are on shared hosting competing with other tenants. But moving host before fixing the above just relocates the problem to a more expensive address.

Assets last. Image formats, lazy loading and script deferral are worth doing and they are what most guides lead with. They improve the loading experience of pages that were already being served reasonably quickly. They do very little for a checkout that spends four seconds in PHP before sending a byte.

Measuring WooCommerce Performance Properly

Synthetic scores mislead store owners more than any other group, so measure deliberately.

Test the logged-in, cart-populated state. Most tools test an anonymous visitor hitting the homepage, which is the fastest possible path through your site and tells you almost nothing about checkout.

Separate server time from front-end time. If the server takes three seconds to produce the HTML, no amount of image optimisation will save the page. Time to first byte tells you which half of the problem you have, and therefore which of the fixes above applies.

Use field data rather than lab data where you can. Real visitors on real connections and real phones produce a different picture from a test run in a data centre, and Core Web Vitals are assessed on the former. Our WordPress performance audit guide covers how to read those metrics properly, and Core Web Vitals in 2026 explains what the thresholds actually require.

Finally, watch the database directly during a slow request. A query log showing the same query executed two hundred times on one page load identifies the culprit immediately, and that pattern is extremely common in stores running several plugins that each ask for product data independently.

What This Work Costs

Prices below reflect typical UK agency rates for a store of moderate size.

A performance audit that identifies the specific causes, with a prioritised fix list and before-and-after measurements, generally runs £900 to £2,500. That is a diagnostic engagement and it is worth buying separately, because it tells you whether the remaining work is a week or a month.

Implementing the common fixes — object caching, database cleanup, plugin asset auditing, external call caching — usually runs £2,000 to £6,000 depending on how much has accumulated.

Deeper work costs more because it is genuinely development. Migrating a large catalogue to indexed storage, rebuilding a filter system that scans metadata, or replacing a slow plugin with a targeted custom implementation typically falls between £6,000 and £20,000.

The figure that matters more than any of these is what slowness costs you. Checkout abandonment rises measurably with load time, so a store turning over meaningful revenue can usually justify the audit on the checkout page alone.

Fix the Store, Not the Score

Mecanik does WooCommerce performance work as part of our WordPress development service , and we start by measuring the logged-in checkout path rather than the homepage, because that is where stores actually lose money.

We look at autoloaded options, order storage, query patterns and external calls before recommending a host change, and we give you the measurements both before and after so the improvement is verifiable rather than asserted. If your store is slow because it has outgrown the platform rather than because it is misconfigured, we will tell you that too — our comparison of Shopify and custom ecommerce covers where that line sits.

Send us the URL and roughly how many products and orders the store holds, and we will tell you which of the four causes above you are most likely facing.

Related reading: WordPress Hacked: Malware Removal and Recovery Guide , How to Scale an E-commerce Business in the UK: 2026 Guide , Hire a Drupal Developer: Rates, Skills and Vetting and How Much Does a Website Cost in the UK in 2026? .

Frequently Asked Questions

Why is my WooCommerce site slow even with a caching plugin? Page caching cannot be applied to cart, checkout and account pages, because those must reflect each visitor’s own state. Those pages execute PHP and database queries on every request, so speeding them up requires object caching and database work rather than page caching.

Does moving to better hosting fix WooCommerce performance? Only partly, and it should not be the first step. If the options table is bloated, queries are unindexed and plugins load assets everywhere, better hosting makes the same problems slightly faster at higher cost. Fix caching and the database first, then reassess hosting.

How many plugins are too many for WooCommerce? The count matters less than what each one loads. Twenty well-behaved plugins that only enqueue assets on their own pages cause less harm than eight that load scripts site-wide. Audit what each adds to the checkout, and remove anything whose purpose nobody can state.

What does WooCommerce speed optimisation cost? A diagnostic audit with a prioritised fix list typically costs £900 to £2,500. Implementing common fixes such as object caching, database cleanup and asset auditing usually runs £2,000 to £6,000, while catalogue or filter rework can reach £6,000 to £20,000.

How should I test WooCommerce performance properly? Test as a logged-in visitor with items in the cart, not an anonymous homepage visit. Separate server response time from front-end rendering to see which half is slow, and use field data from real visitors rather than relying only on lab scores.