WooCommerce slow? Why stores slow down and how to fix it

A WooCommerce store slows down for three reasons. Its most important pages, the cart, checkout and account pages, cannot be served from a page cache, so every request runs PHP and database queries. The database grows with orders, sessions, background jobs and leftover plugin data. And plugins accumulate, each adding queries and scripts. The fixes, in order of impact: hosting with enough PHP capacity and an object cache, correct page caching for everything else, fewer plugins, a cleaned database, then images and front-end scripts.

The rest of this guide shows how to find which of those is hurting your store, and what each fix involves.

Why is a WooCommerce store slower than a normal WordPress site?

A brochure site on WordPress serves almost every page from a cache. The visitor gets a stored copy of the HTML, and PHP barely runs.

A store cannot do that everywhere. Once a shopper adds something to the cart, their pages are personal: the cart count, the totals, shipping rates and their address. Caching plugins and hosts deliberately skip the cache for cart, checkout and account pages, and usually for any visitor with items in the cart. Those requests go all the way to PHP and MySQL, every time.

So a store is only as fast as its uncached page. That is the number to measure and the one cheap hosting fails on. A shopper who reaches checkout and waits four seconds for each step is the most expensive visitor to lose. The uncached checkout is the first thing we measure when a store comes to our e-commerce development team with a speed complaint.

How do you find what is actually slow?

Measure before changing anything. Three checks cover most cases.

Time to first byte, cached and uncached. This prints how long the server takes to start responding:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/product/sample-product/
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/cart/

Run each a few times. A cached product page should answer in well under half a second. If the cart page takes more than a second with an empty cart, the server side is the problem, and front-end tweaks will not fix it.

What runs on the slow page. The free Query Monitor plugin shows, for any page, the number of database queries, the slowest ones, and which plugin made them. Install it on a staging copy if you can, load the cart and checkout, and look for a plugin responsible for hundreds of queries or a single query taking most of the time.

What real shoppers experience. PageSpeed Insights shows Core Web Vitals from real Chrome users if your store has enough traffic, separately for mobile and desktop. Check a product page and a category page. Our Core Web Vitals checker explains what each score means against Google's thresholds.

What fixes make the biggest difference?

In the order we apply them.

Hosting with enough PHP workers

A PHP worker handles one uncached request at a time. If a host gives you two workers and five shoppers hit checkout together, three of them wait. Managed WordPress hosts publish worker counts per plan; shared hosts often do not. A small store needs fewer workers than a busy one, but it needs more than a brochure site, and it needs a current, supported PHP 8 version. Moving a store from cheap shared hosting to a decent managed or VPS plan is often the single biggest improvement, and it usually costs tens of dollars a month more, not hundreds.

An object cache

WooCommerce and WordPress repeat many of the same database lookups on every request. A persistent object cache, usually Redis, keeps those results in memory between requests. It is the main way to speed up the pages that cannot be page-cached. Many managed hosts include Redis; turning it on is minutes of work.

Page caching set up correctly

Product, category and content pages should be cached for anyone with an empty cart. Cart, checkout and account pages must not be. Good caching plugins and host-level caches handle WooCommerce's exclusions automatically; check that yours does, and that a page builder or a plugin has not disabled caching site-wide.

Fewer, better plugins

Every active plugin runs code on every request. Filters, wishlists, currency switchers, upsell tools and abandoned cart plugins are the usual offenders, because they hook into product and cart queries. Use Query Monitor to see what each costs. Remove what nobody uses, and replace heavy plugins with lighter ones that do one job. A store with sixty plugins is rarely a store that needs sixty.

A cleaner database

Over time, tables fill with data that slows queries:

• Orders on the old storage. WooCommerce's High-Performance Order Storage moves orders into their own tables instead of the general WordPress posts tables. It has been the default for new stores since late 2023; older stores have to switch it on and migrate. See WooCommerce's HPOS documentation and check your plugins for compatibility first.
• Scheduled actions. WooCommerce runs background jobs through Action Scheduler. Completed jobs are cleaned up automatically, but failed and pending ones can pile up into hundreds of thousands of rows when a plugin misbehaves. The list is under WooCommerce, Status, Scheduled Actions.
• Expired sessions and transients, and autoloaded options left behind by plugins you deleted years ago.

Take a full backup before any database clean-up, and do it on staging first.

Images and front-end weight

Large product photos hurt mobile LCP on product and category pages. Serve them in WebP at the size they are displayed; the image compressor shows how much a typical photo shrinks. Then check scripts: a theme that loads slider, animation and page-builder libraries on every page, or plugins that load their scripts sitewide when they are needed on one page.

What does not help much?

• A CDN on its own. It speeds up images and static files. It does nothing for a slow checkout.
• Minifying CSS and JavaScript when the server takes three seconds to respond. Fix the server first.
• "Speed" plugins that promise one-click fixes. Many add their own overhead, and some break checkout scripts. Configure one caching solution properly instead.
• More RAM on a plan with too few PHP workers. The queue is the problem, not the memory.

When should you stop fixing WooCommerce and move?

Speed work on WooCommerce is usually a few days, and the result holds if someone keeps the store tidy. It stops holding when nobody does: plugins get added, updates get skipped, and in a year the store is slow again. If that pattern is the real problem, the fix is a platform that maintains itself. Shopify vs WooCommerce sets out the trade, and how to choose an e-commerce platform covers the wider decision.

If you want the store fixed rather than moved, we do WooCommerce speed work, and a website maintenance plan keeps it fast afterwards. For the WordPress side in general, speeding up WordPress covers the fixes that apply to any WordPress site.