How to speed up a slow WooCommerce store

Almost every “my WooCommerce store is slow” problem comes down to the same short list of causes, and they arrive in roughly the same order as a store matures: more plugins, more orders, more data, more third-party calls. The good news is that the fixes are well understood. The trap is spending money and effort on the wrong layer — buying bigger hosting to hide a missing database index, or installing a caching plugin to fix a checkout that can never be cached. This guide walks the whole stack, top to bottom, and ends with the exact order to work in.

Measure the right number first

The single most common mistake is optimising the wrong page. A PageSpeed score for your homepage tells you very little about the experience that actually loses sales, because the homepage is cacheable and checkout is not. Before changing anything, get three honest numbers:

• Server response time (TTFB) on a category page, measured cold. This is how long the server takes to start sending the page. Aim for under ~600ms.
• Largest Contentful Paint (LCP) on mobile, from real-world field data if you have it. This is the Core Web Vital shoppers feel most. Aim for under 2.5 seconds.
• Checkout response, logged in, with a full cart. This is real application speed with nothing cached. It is the number that quietly costs you money.

Write those three down. Everything below is about moving one of them, and you cannot tell what worked if you never had a baseline.

Where WooCommerce time actually goes

It helps to picture three layers, because a fix aimed at the wrong one does nothing:

• The server — hosting, PHP version, and how much memory and CPU your store actually gets. This sets the floor.
• The application — WordPress, WooCommerce, your theme and plugins, and above all the database queries they run on each request. This is where most real slowness lives, and where most people never look.
• The front end — images, JavaScript, CSS and fonts arriving in the browser. This is what speed-test tools grade, so it gets disproportionate attention.

A slow store is usually slow in the middle layer, gets blamed on the first, and gets “fixed” in the third. Keep the three separate in your head and you will already be ahead of most advice online.

Hosting and TTFB: the foundation everything sits on

Hosting sets the ceiling on how fast anything can be, but it does not fix a slow application — it just runs the same slow code on faster metal. Get the fundamentals right and stop:

• Run a current PHP version. Moving from an old PHP release to a current one is one of the largest free wins available, often cutting execution time meaningfully with no code changes. Test on staging, then upgrade.
• Make sure you are not on oversold shared hosting. If your TTFB swings wildly at busy times, you are competing for CPU with hundreds of other sites. A decent managed-WordPress or VPS plan removes that variable.
• Use a CDN for static assets. Images, CSS and JS served from an edge close to the shopper shave real time off every page, and take load off your origin.

Upgrade hosting when you have confirmed the application is healthy and you have simply outgrown the plan. Upgrade it before that and you will pay more each month to keep a real problem hidden.

Caching: page, object and what to never cache

Caching is powerful and widely misunderstood. There are two kinds that matter, and they do different jobs:

• Page caching saves the fully rendered HTML of a page so the next visitor gets it without WordPress running at all. It makes home, shop and category pages extremely fast. It must exclude cart, checkout, account and any personalised page — those are unique per visitor, and caching them leaks one shopper’s cart to another.
• Object caching (Redis or Memcached) stores the results of database queries in memory so repeated queries within and across requests are instant. This is what actually speeds up the pages a page cache cannot touch, including logged-in browsing and, indirectly, checkout.

The honest rule: a caching plugin makes your cacheable pages look great in a speed test, and that is genuinely worth having. But if your pain is slow checkout or a slow logged-in experience, page caching does nothing for it, and no amount of it will. That problem lives in the database.

The database: where the biggest real wins hide

This is the layer that separates a store that stays fast from one that degrades every year, and it is the one most tutorials skip because it is less visible than an image or a plugin. Three things to check, in order:

1. Autoloaded options. WordPress loads every option marked autoload = yes on every single request, before your code does anything. A healthy site autoloads a few hundred kilobytes; stores with a long plugin history routinely reach several megabytes of data deserialised into memory on every page load. Find the largest autoloaded rows, confirm what wrote them, and switch off autoload for anything not needed on every page. It is the cheapest large win there is.

2. Slow queries and missing indexes. Reporting, analytics, loyalty and “related products” plugins commonly query the orders and post-meta tables without the index they need. That query is instant with 500 orders and takes many seconds with 500,000 — and nothing in the code changed, the data just grew. Turn on the slow query log for a day, or use a query profiler, find the one or two offenders responsible for most of the time, and add the index. The fix is usually an index, not deleting the plugin.

3. A bloated wp_options and post-meta table. Expired transients, orphaned meta and abandoned-session data build up for years. A careful clean-up (on a backup first) shrinks the tables every query has to work through.

Most stores that feel “mysteriously slow” are slow here. It is invisible to speed-test tools, which is exactly why it survives.

Plugins: it is what they do, not how many

“Too many plugins” is the most repeated and least useful piece of WooCommerce advice. The count barely matters; the work each plugin does on every request is what matters. Thirty lightweight plugins can easily beat five that each run an unindexed query on the orders table on every page load.

Rather than deleting by gut feeling, profile. A tool like Query Monitor, or a hosting profiler that attributes time to plugins, will show you exactly which ones cost you milliseconds and which cost you seconds. Then you can make an informed decision: index the query, replace the plugin, load it only where it is needed, or remove it. Deactivating plugins blindly to “see if it helps” is how stores end up with broken features nobody notices for weeks.

The front end and Core Web Vitals

Once the server and application are healthy, the front end is what shoppers physically wait for, and what Google grades through Core Web Vitals. The wins here are unglamorous but reliable:

• Images are almost always the biggest front-end payload. Serve modern formats (WebP/AVIF), size them for the space they occupy, and lazy-load anything below the fold. Product images done properly often halve page weight on their own.
• JavaScript and CSS from themes and plugins pile up. Defer what is not needed for first paint, and stop plugins loading their assets site-wide when they are only used on one page.
• Fonts should be preloaded and served with font-display: swap so text is never invisible while a font downloads.
• Interaction to Next Paint (INP) — the newest Core Web Vital — punishes heavy JavaScript that blocks the main thread. Trimming third-party scripts helps here as much as it helps load time.

Aim for a good experience, not a perfect score. A store at 100% in a lab test can still feel slow to a real shopper on a mid-range phone, and a store at 80% can feel instant. Optimise the number shoppers feel.

Checkout is its own problem

Checkout deserves separate treatment because it cannot be page-cached and it runs every plugin hook and external call on every load — address validation, tax, shipping rates, fraud scoring. Each synchronous call adds its full round trip while the customer waits, and each one can hang. It is also the page where slowness costs the most, converting frustration directly into abandoned carts.

Because it is such a common and specific failure, it has its own deep dive: why WooCommerce checkout gets slow, and what to fix first. If checkout is your worst page, start there.

The order to work in

Do these in sequence. Each step tells you whether the next one is even necessary:

• Record your three baseline numbers: TTFB, mobile LCP, and logged-in checkout with a full cart.
• Move to a current PHP version and confirm your hosting is not oversold.
• Check autoloaded options and trim what does not belong.
• Find slow queries and add the indexes they need — before removing any plugin.
• Add object caching (Redis) and page caching, with cart, checkout and account excluded.
• Fix images, then defer non-critical JavaScript and CSS.
• Put timeouts and fallbacks on every external call in the checkout path.
• Re-measure the same three numbers and compare.

The majority of the improvement comes from the first four steps — the ones with no visible “score” attached. That is not a coincidence.

When it is worth bringing someone in

If you have worked through the front-end and hosting steps and the store is still slow, the cause is almost certainly a database query or a plugin doing expensive work on every request — and finding it means profiling the application, not guessing. That is the point where an hour with someone who does this regularly saves you weeks of trial and error, and usually costs less than the bigger hosting plan you were about to buy to paper over it.