How to Speed Up WooCommerce: A Complete Guide

To speed up WooCommerce, page-cache the catalogue but exclude cart, checkout and account pages, add a persistent object cache like Redis, clean out database bloat (expired transients and session rows), audit heavy plugins, and run each store on its own PHP workers. Together these fix the four causes: uncacheable pages, repeated queries, table bloat and resource contention.

A standard WordPress blog can serve almost every visitor a cached HTML page, so PHP barely runs. WooCommerce cannot. Cart contents, the logged-in account area and checkout are unique per visitor, so a large share of your traffic hits PHP and the database directly. On top of that, WooCommerce adds product, order, session and inventory data that turn one page load into hundreds of queries.

So the slowness is rarely one thing. It is usually a stack: pages that skip the cache, a database that has quietly bloated, a plugin or two loading assets on every page, and a hosting plan where a traffic spike runs you out of PHP workers at the worst moment. This guide works through each cause, with the WooCommerce-specific detail and the commands to fix it.

WooCommerce is harder because a large part of its traffic is personal and therefore uncacheable. Cart, checkout, My Account and any page showing basket contents change per visitor, so they must run PHP and hit the database on every request. A brochure WordPress site can serve 95% of requests from a static cache; a busy store often cannot cache the pages that matter most for revenue.

WooCommerce also stores far more data. Every order writes rows across several tables. Every visitor, logged in or not, gets a session. Products carry variations, attributes and metadata. Inventory, coupons and tax rules add more lookups. The result is a database that grows quickly and query counts that climb with catalogue size and order history.

The practical consequence: you cannot speed up a store by turning on a caching plugin and walking away. You need caching rules that respect the cart, a way to reduce repeated database work, ongoing database housekeeping, and enough PHP capacity to absorb checkout spikes. Miss any one of those and the store still feels slow under real load, even if your homepage scores well in a synthetic test.

Cache the catalogue aggressively and exclude the personal pages by URL and by cookie. Configure your page cache to never serve cart, checkout and account pages, and to bypass the cache entirely for any request carrying a WooCommerce cart or session cookie. Then test with a real item in the basket, because most broken-cart bugs come from a cache that ignores those cookies.

The mechanism matters. When a visitor adds to cart, WooCommerce sets cookies such as woocommerce_items_in_cart and woocommerce_cart_hash, plus a session cookie like wp_woocommerce_session_. Your cache must treat the presence of those cookies as a signal to bypass. If it does not, one shopper can be served another shopper's cached cart, or a stale empty cart is served to someone who just added an item. That is the classic exclusion leak, and it is worse than being slow.

For the pages you genuinely cannot cache, the goal shifts from avoiding PHP to making each PHP request cheap. That is where object caching comes in, covered next. But get the exclusions right first: a fast checkout that occasionally shows the wrong cart will cost you far more than a slow one.

Yes, a persistent object cache is one of the biggest wins for a busy WooCommerce store. WooCommerce makes the same database lookups over and over within a single request and across requests. A persistent object cache (Redis is the common choice) keeps those results in memory, so PHP stops asking the database the same questions. On cart and checkout pages, which you cannot page-cache, this is often the single largest speed-up available.

Without a persistent object cache, WordPress rebuilds its object cache from scratch on every request. With one, expensive results (option lookups, product data, term relationships) survive between requests. For a store doing real traffic this can cut database load sharply and drop time-to-first-byte on the dynamic pages that never see the page cache.

Object caching is not a cure for a badly bloated database or a plugin running a slow query on every page. It hides repeated work; it does not fix work that should not happen at all. Pair it with the database cleanup and plugin audit below, and measure before and after so you know the object cache is actually being hit.

Database bloat slows WooCommerce because every uncached request reads from tables that have grown far larger than they need to be. The usual culprits are expired transients and autoloaded rows in wp_options, an ever-growing WooCommerce sessions table, Action Scheduler logs, post revisions, and orphaned rows in wp_postmeta. Clean these regularly and product queries, cart operations and the admin all get faster.

The most common quiet killer is autoloaded data in wp_options. Every request loads all rows marked autoload = yes into memory. Plugins that dump large serialised blobs there add weight to every single page load, cached or not. Expired transients pile up in the same table. On stores that take a lot of traffic, the wp_woocommerce_sessions table and Action Scheduler tables (wp_actionscheduler_actions, wp_actionscheduler_logs) can grow to hundreds of thousands of rows if nothing prunes them.

WP-CLI makes the routine cleanup a one-liner. wp transient delete --expired clears stale transients. wp db query lets you inspect the biggest autoloaded options. wp db optimize rebuilds fragmented tables. Set a monthly job for the safe ones and review the heavy tables by hand a few times a year. On G7Cloud each store has its own MariaDB database with WP-CLI and phpMyAdmin available, so this housekeeping never touches anyone else's data.

There is no magic number; what matters is what each plugin does on every request. Ten well-behaved plugins can be faster than three that each run a database query and load their own CSS and JavaScript on every page. The real question is not how many plugins you have, but how much work they do per page load and which of them run on the front end when they only need to run in the admin.

WooCommerce extensions are frequent offenders because many load assets site-wide when they are only needed on a single template. A currency switcher, a wishlist, a reviews add-on and a page builder can each enqueue scripts on every page, so a product listing pulls in code it never uses. The cost shows up as extra queries, larger pages and more render-blocking assets, all of which hit the uncacheable pages hardest.

Audit with Query Monitor. It shows you, per page, how many queries ran, which plugin or theme fired them, how long each took, and which scripts and styles loaded. Sort by time, find the plugin adding the most query time on your key templates, and decide whether it earns its place. For assets, dequeue plugin CSS and JavaScript on templates that do not need them, so the wishlist script no longer loads on the checkout.

This is the same principle we cover in why WordPress performance shouldn't depend on plugins: reach for a plugin when it earns its keep, and remove the ones whose cost you cannot justify with a measurement. A leaner plugin set is usually the cheapest speed-up on a mature store.

Give your store enough PHP workers and its own resources so a traffic spike cannot exhaust them. A PHP worker is a process that handles one request at a time. Cached pages barely touch them, but every cart, checkout and account request occupies a worker for the whole request. When more uncacheable requests arrive than you have workers, the rest queue, and shoppers see a checkout that hangs or times out.

This is why a WooCommerce store feels fine on a normal day and falls over during a sale. A marketing email or an ad campaign sends a burst of shoppers straight to cart and checkout: exactly the pages the page cache cannot help with. Each one holds a worker. If you are on a plan with a low worker count, or sharing capacity with other sites, the queue builds and response times climb precisely when every conversion counts.

On G7Cloud every store runs in its own dedicated container, so a checkout spike on another shop is not your problem, and the resources you provision are the resources you get. Combine that with the caching and database work above and the goal is simple: keep as much traffic as possible on the page cache, make the uncacheable requests cheap with object caching, and have enough workers left to absorb the checkout burst. Our monitoring checks each site every minute so a resource problem alerts you rather than a customer.

Work in this order: measure first, then fix the biggest cause you find. Optimising blind wastes effort on things that were never slow. Start by diagnosing where the time goes, then apply caching, object caching, database cleanup, a plugin audit and enough PHP capacity, re-measuring after each change so you know what actually moved the number.

Measurement is the step most people skip. Watch time-to-first-byte on the four page types above, because TTFB is where server-side slowness shows up before anything renders. Use Query Monitor to see the query count and the heaviest plugins per template. If your logs show a flood of admin-ajax.php with wc-ajax=get_refreshed_fragments, that is cart fragments. Enable the slow query log to catch the specific queries dragging on your busiest pages.

Speed is a revenue lever as well as a technical score: slow stores lose sales, as we cover in how slow websites kill conversions. If you are weighing WooCommerce against a hosted platform while you are here, WooCommerce vs Shopify walks through the trade-offs, and the Core Web Vitals guide for WordPress covers the front-end metrics Google measures once your server side is fast.