A slow WooCommerce store is not a mystery and it is rarely one bad plugin. WooCommerce is slow for structural reasons: it is WordPress with a heavy commerce layer bolted on, every page is dynamic PHP, the cart and checkout cannot be cached the easy way, and the product catalog leans hard on database tables that were never built for it. No single fix covers all of that. The reason "I installed a caching plugin and it is still slow" is so common is that caching only solves one of six different bottlenecks. Below is the way I actually optimize a WooCommerce site: six layers, what each one fixes, why it works, and what it leaves for the next layer.
How do I speed up a slow WooCommerce site?
Speeding up WooCommerce is a layered job, not a single switch. First, put the site on hosting with real CPU and PHP 8.x. Second, add full-page caching so catalog pages (shop, category, product) serve as static HTML. Third, add a persistent object cache (Redis) so the pages that cannot be page-cached, cart, checkout, account, and every cache miss, stop re-running the same database queries. Fourth, fix the database: clear autoloaded option bloat, delete expired transients, convert tables to InnoDB, and enable HPOS. Fifth, move product search and filtering off MySQL onto Elasticsearch once the catalog is large. Sixth, trim the front end: cart fragments, asset bloat, images, and a CDN. Each layer addresses a different bottleneck, which is why a store needs most of them, not just one.
Jump to:
- Why WooCommerce is slow by default
- Layer 1: Hosting and the PHP runtime
- Layer 2: Cache the pages that can be cached
- Layer 3: Add a persistent object cache
- Layer 4: Fix the database
- Layer 5: Move search and filtering off MySQL
- Layer 6: Trim the front end
- How to measure it
- Common pitfalls
- FAQ
Why WooCommerce is slow by default
Plain WordPress serving a blog post is cheap. The post is one row, the template is simple, and a full-page cache can turn the whole thing into static HTML that never touches PHP again. WooCommerce breaks every part of that.
A WooCommerce product is a custom post type with a long tail of metadata: price, sale price, stock status, SKU, dimensions, attributes, variations. All of it lives in wp_postmeta as key/value rows, so a "products under 50 dollars, in stock, in this category" query becomes a stack of JOIN and meta_query clauses against a table that can hold millions of rows. That is slow, and it gets slower as the catalog grows.
Worse, the pages that matter most for revenue, cart, checkout, and my-account, are per-user and per-session. They show your cart, your addresses, your orders. A normal full-page cache cannot serve those, because caching one shopper's checkout and showing it to the next is a data leak. So the highest-value pages are exactly the ones that fall through to live PHP and live database queries on every single request.
On top of that, WooCommerce adds an AJAX call (wc-cart-fragments) that fires on nearly every page to keep the mini-cart widget current, every order is written into already-busy core tables, and a stack of extension plugins each add their own queries and assets. None of these is a bug. They are the cost of running a real store on WordPress. Optimization is the work of paying that cost down, one layer at a time.
Layer 1: Hosting and the PHP runtime
The problem. WooCommerce executes a lot of PHP per request and issues dozens to hundreds of database queries. On budget shared hosting you share a CPU with hundreds of other sites, get throttled, and run an old PHP build. Every later optimization is measured against this baseline, so a weak baseline caps everything above it.
The fix. Run on hosting with dedicated or burstable CPU (a VPS, a managed WooCommerce host, or a container) and put the site on a current PHP release. PHP 8.x is dramatically faster than PHP 7.x for the same code, and the opcode cache (OPcache) must be on so PHP is not recompiling every file on every request. Give PHP enough memory to finish its work:
// wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Why it works. Faster CPU and a newer PHP runtime reduce the time of the one thing WooCommerce cannot avoid: executing code. OPcache removes the recompile tax. More memory keeps large catalog and admin operations from dying halfway. If you hit memory errors, PHP Memory Limit: How to Fix 'Allowed Memory Size Exhausted' walks through the full set of places the limit is set.
What it does not solve. A fast server still rebuilds the same page from scratch on every visit. You have made the work fast; you have not stopped doing the work repeatedly. That is the next layer.
Layer 2: Cache the pages that can be cached
The problem. Without page caching, every visit to the shop page, a category page, or a product page runs the full WordPress and WooCommerce PHP stack and its database queries, even though the result is identical for every logged-out visitor.
The fix. Put a full-page cache in front of the catalog. This can be a caching plugin (WP Super Cache, W3 Total Cache, WP Rocket, LiteSpeed Cache) or a server-level cache (Nginx FastCGI cache, Varnish). The catalog pages, which are the same for everyone, get stored as ready-made HTML and served without touching PHP. The critical part is configuration: WooCommerce ships a set of "do not cache" cookies and pages, and every serious caching plugin knows to exclude cart, checkout, and my-account. Confirm that exclusion exists rather than assuming it.
Why it works. A page cache turns a repeated, expensive computation into a single cheap file read. For a logged-out visitor browsing products, response time drops from "run all the PHP" to "send a file." This is the single biggest win for catalog and landing-page speed, and it is what Core Web Vitals and crawl budget care about most.
What it does not solve. Three things still run live: the cart, checkout, and account pages (per-user, uncacheable); every request from a logged-in user (caches are usually bypassed for them); and the very first request after a cache entry expires (the "cache miss" that has to rebuild the page). All of those still hit PHP and the database at full cost. That is the next layer.
Layer 3: Add a persistent object cache
The problem. WordPress has an internal object cache, but by default it lasts only for the single request. The moment the page finishes rendering, it is thrown away. So an uncacheable page like checkout, or a cache-miss rebuild, re-runs the same get_option() lookups, term queries, and product reads it ran a second ago for the previous visitor. The database answers the same questions over and over.
The fix. Add a persistent object cache backed by Redis (or Memcached). Install Redis on the server and a drop-in plugin such as Redis Object Cache, then enable it:
wp plugin install redis-cache --activate
wp redis enable
wp redis statusThis writes an object-cache.php drop-in into wp-content/ that routes WordPress's object cache to Redis, where entries survive across requests.
Why it works. Query results, options, and computed values now persist in memory between requests and between users. The checkout page that cannot be page-cached still benefits, because the building blocks it assembles are served from Redis instead of MySQL. Cache-miss rebuilds get cheaper for the same reason. This is the layer that speeds up the pages page caching could not touch.
Why you need both Layer 2 and Layer 3. They are not alternatives. Page caching serves whole static pages to logged-out catalog traffic. Object caching speeds up the dynamic pages and the cache misses underneath. A store with page caching but no object cache has fast product pages and a slow checkout. A store with object caching but no page cache rebuilds every catalog page, just slightly faster. You want the pair.
What it does not solve. Object caching makes repeated questions cheap, but the first time each question is asked, and any question that cannot be cached, still goes to the database. If the database itself is slow, you have only moved the bottleneck. That is the next layer.
Layer 4: Fix the database
This is the layer most "speed up WooCommerce" advice skips, and on an older or busy store it is often the biggest single win.
Problem: autoloaded option bloat. Every WordPress request loads all wp_options rows marked autoload = 'yes' into memory. Plugins (especially ones you have removed) leave large autoloaded rows behind. Find the offenders:
SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;A healthy autoload total is well under 1 MB. Check it:
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';If it is several megabytes, set stale rows to autoload = 'no' or delete dead-plugin options. Every request gets lighter immediately.
Problem: expired transients. WooCommerce and its extensions store cached fragments as transients in wp_options. Without a persistent object cache (Layer 3), expired transients are not always cleaned up and the table bloats. Clear them:
wp transient delete --expired
wp transient delete --allProblem: MyISAM tables and missing indexes. Old installs sometimes still have MyISAM tables, which lock the whole table on writes. WooCommerce is write-heavy (orders, stock, sessions), so MyISAM serializes traffic. Convert everything to InnoDB; MyISAM to InnoDB Conversion covers why and how. While you are in the schema, the right column types matter too, see MySQL Field Types and Sizes.
Problem: orders crammed into core tables. Historically every WooCommerce order was a shop_order post in wp_posts with its details scattered across wp_postmeta, the same tables your content and products use. On a store with tens of thousands of orders, that is a lot of contention.
The fix: enable HPOS. High-Performance Order Storage (HPOS, formerly Custom Order Tables) gives orders their own dedicated, properly indexed database tables. It is the default for new WooCommerce installs and an opt-in migration for existing ones, under WooCommerce → Settings → Advanced → Features. Enabling it on an established store triggers a one-time sync of existing orders into the new tables; do it on staging first, let the sync finish, then switch over.
Why this layer works. Smaller autoload payloads cut fixed cost off every request. Cleared transients shrink wp_options so its lookups are fast. InnoDB lets reads and writes happen concurrently instead of queuing. HPOS moves order traffic onto tables built and indexed for it, so order admin, reports, and checkout writes stop fighting your posts table. For the SQL side of verification, the MySQL Cheat Sheet has the inspection commands.
What it does not solve. A tuned database is fast at the queries it is good at: fetching rows by primary key or a clean index. It is still bad at one specific thing WooCommerce asks of it constantly: text search and multi-attribute filtering across wp_postmeta. That is the next layer.
Layer 5: Move search and filtering off MySQL
The problem. Product search (?s=...) and layered/faceted filtering ("show in-stock blue medium shirts under 40 dollars, sorted by price") are the hardest thing you can ask MySQL to do in WooCommerce. Search becomes LIKE '%term%' scans that cannot use an index, and faceted filters become deep wp_postmeta JOIN stacks. Both are fine on a small catalog and fall off a cliff somewhere past a few thousand products, exactly when the store is succeeding.
The fix. Move search and filtering onto a search engine built for it: Elasticsearch, via the ElasticPress plugin. ElasticPress indexes your products and routes the relevant WP_Query calls to the search cluster instead of MySQL. The full setup is in How to Use ElasticPress with WP_Query.
Why it works. A search engine stores data in an inverted index, so a text query is a fast index lookup, not a table scan, and it returns results ranked by relevance instead of just "contains the string." Faceted counts come from native aggregations rather than JOIN math. Search latency stops growing with catalog size.
Why this is a layer, not the first move. Elasticsearch is real infrastructure: another service to host, monitor, and keep in sync. Adding it to a 300-product store is overhead with no payoff. Adding it to a 50,000-product store is the difference between a usable shop and a broken one. Decide deliberately: ElasticPress vs MySQL FULLTEXT compares the two engines head to head, and Do I Need ElasticPress? is the honest checklist for whether your store is past the threshold. If you do adopt it, Elasticsearch vs OpenSearch for ElasticPress explains why ElasticPress officially targets Elasticsearch.
What it does not solve. Now the server is fast, pages are cached, the database is tuned, and search scales. The HTML still has to render in the browser. That is the last layer.
Layer 6: Trim the front end
The problem. Even a perfectly fast backend can feel slow if the page ships a megabyte of render-blocking CSS and JavaScript, unsized images, and WooCommerce's own overhead. Two WooCommerce-specific costs stand out.
Cart fragments. WooCommerce uses wc-cart-fragments, an AJAX script that calls admin-ajax.php to keep the mini-cart current, and it is uncacheable by design. Recent WooCommerce versions load it more conditionally rather than on every route, but plenty of themes and custom builds still pull it in site-wide, including on pages with no cart widget, where those calls just pile up. If your setup still loads it everywhere, stop it where it is not needed:
add_action( 'wp_enqueue_scripts', function () {
if ( is_cart() || is_checkout() ) {
return;
}
wp_dequeue_script( 'wc-cart-fragments' );
}, 11 );Keep it on the cart and checkout pages, where the live cart count genuinely matters, and drop it everywhere else.
Assets and images. Trim plugin-injected CSS and JS, defer non-critical scripts, and serve images in modern formats at the right size. Put a CDN in front of static assets so they load from an edge near the visitor.
Why it works. This layer targets perceived speed and Core Web Vitals: Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. The backend decides how fast the response leaves the server; the front end decides how fast the page becomes usable. Both are needed for a store that feels fast and ranks well.
Why it is last. Front-end work is real, but doing it first is painting a house with a cracked foundation. If the server is slow, the database is thrashing, and search times out, a CDN and minified CSS will not save the store. Optimize from the inside out: runtime, caching, database, search, then the front end.
How to measure it
Optimize against numbers, not vibes. Install Query Monitor to see, per page load, how many database queries ran, which were slowest, and how much time was PHP versus database. Run product search and a filtered category page with it active; that is where the ugly query counts hide. Watch the cart and checkout pages specifically, since those bypass page caching and tell you whether Layers 1, 3, and 4 are doing their job.
For the front end, use the browser's Lighthouse panel and a real-user view of Core Web Vitals in Google Search Console. Measure before and after each layer so you know which change bought which improvement. "The site feels faster" is not a metric; a checkout page that went from 2.1 seconds to 600 milliseconds is.
Common pitfalls
- Stacking caching plugins. One page-cache plugin, configured correctly, beats three fighting each other. Overlapping caches cause stale carts and checkout bugs.
- Page-caching the cart or checkout. This serves one shopper's cart or details to the next visitor. Always confirm cart, checkout, and my-account are excluded.
- Enabling HPOS on production without staging. The order-sync migration should run and finish on staging first. Verify, then switch.
- Adding Elasticsearch too early. On a small catalog it is moving parts with no payoff. Cross the threshold first.
- Optimizing the front end while the backend is on fire. A CDN cannot fix a thrashing database. Inside out.
- Never reindexing after bulk imports. A large product import can outrun WooCommerce's sync hooks and leave caches and the search index stale; see wp_insert_post Consuming Large Amounts of Memory for the import side of this.
