Every "best WordPress speed plugin" post on the internet assumes you're running a blog. WooCommerce isn't a blog. The cart, the checkout, the My Account page, the wp-admin Orders screen — none of these can be cached the way a static homepage can. Most generic speed-plugin recommendations stop being useful the moment a customer adds something to their cart.
This post is the WooCommerce-specific version of that ranking. I've spent the last three years tuning WC stores ranging from 50 SKUs to 80,000, on hosting from $5/month shared up to managed dedicated. I've installed every plugin on this list, watched it work, watched some of them break checkout in ways I had to apologise to clients for, and pulled some of them off two days later. This isn't another regurgitated affiliate listicle — it's notes from the field.
Quick honesty up-front: I make AcceleratorWP, a structural performance plugin. I'll mention it once at the bottom. Most of this post isn't about us. If you're going to add a speed plugin to your WooCommerce site, here's how the field actually looks in 2026.
If you want the broader (non-WC) comparison, the general WordPress speed-plugin ranking lives here — same voice, broader scope.
How I'm ranking these (WC-specific)
Three things matter, in this order:
- Did it move TTFB on
/shop,/cart, and/checkout? Not on the homepage. Not on a static page Lighthouse run. On the pages a real shopper actually hits, where caching either can't help or hurts. - Did it stay out of the way of Stripe, PayPal, and Klarna? A plugin that speeds up your category pages but causes the payment iframe to render at zero width is worse than no plugin at all. WooCommerce checkout has more moving parts than people realise.
- Does it scale past 5,000 products? A lot of plugins look great on a 200-product demo store and fall over at 10,000 SKUs with a thousand active orders in Action Scheduler.
Lighthouse scores aren't on that list on purpose. A 100/100 in Lighthouse on an empty cart tells you nothing about whether the page that actually books revenue is fast.
1. WP Rocket — still the default, with WC-specific caveats
WP Rocket is the most boring entry on this list because it just works for the parts of WC that can be cached: the shop archive, single-product pages for guest visitors, the homepage, the about page, the blog. Page caching, gzip, JS defer, lazy load, integration with Cloudflare. Install it, tick maybe four boxes, the public side of your store is faster.
The WooCommerce-specific gotcha: WP Rocket detects WooCommerce on activation and automatically excludes /cart, /checkout, /my-account, and the cart fragments AJAX endpoint from caching. Good — those are the pages where caching would actually break things (a logged-in customer seeing another customer's cart count is a refund-or-worse incident). But the implication is that WP Rocket does nothing on those exact pages. The cart and checkout are running full PHP every single request, just like before.
Where it's annoying: the "Optimize CSS Delivery" feature (which removes render-blocking CSS) has a long history of stripping Elementor product page styling on WC stores, leading to checkouts that render unstyled for a second before settling. Start with that toggle off. Same with "Combine JavaScript files" — it interacts badly with Stripe's payment-element JS more often than I'd like.
Use it when: you have a small-to-medium WC store, most of your traffic is browsing public product pages, and you want one thing to install and forget. The $59/year is worth it.
Skip it when: most of your traffic is logged-in customers (membership store, subscription product, B2B portal). The pages your customers see can't be cached, and you're paying for a feature that doesn't run on the requests that matter.
2. LiteSpeed Cache — free, fantastic on LiteSpeed servers, broken on anything else
If your host runs LiteSpeed Web Server, OpenLiteSpeed, or routes through QUIC.cloud, this is the best free speed plugin you can install on a WC store. The cache is served by the web server itself, not PHP — WordPress doesn't even boot for cached requests. That's a meaningful win on the public side of WC.
The genuinely useful WC-specific feature is ESI (Edge Side Includes): it lets you cache the page shell while leaving the cart icon (the bit that says "3 items, $89.99") as a dynamic fragment. Most cache plugins skip the cache entirely on any page with a cart fragment; LiteSpeed punches a hole and caches everything else.
The catch most stores trip over: on non-LiteSpeed hosts the plugin falls back to a generic PHP-based cache that's worse than what WP Rocket gives you, and the ESI feature does nothing. Check your host before installing — most managed WC hosts (Kinsta, WP Engine, Pressable, Hostinger Premium WordPress) run NGINX or Apache, not LiteSpeed.
Use it when: your host runs LiteSpeed. SiteGround, NameHero, A2 Hosting, Hostinger basic shared, and a handful of others fall in this bucket. ESI alone is worth installing.
Skip it when: you're on Apache or NGINX. Use WP Rocket.
3. Object Cache Pro — the paid plugin that earns its money on large stores
This is where the "free vs paid" calculus on WC genuinely flips. Object Cache Pro is a commercial replacement for the standard WordPress object cache layer, written specifically for Redis. It costs $95/month for a single site. That's a lot of money for a plugin until you realise what it replaces.
WooCommerce's internal data model is heavy on options, transients, term meta, and product meta. On a large catalog (5,000+ products), a single page load can do 300+ get_option, get_post_meta, and get_term calls. With no object cache, each one is a database round-trip. With the free Redis Object Cache plugin (next entry), they hit Redis. With Object Cache Pro, they hit Redis through a much smarter client that handles connection pooling, pipelining, and async writes, and the difference at scale is measurable.
Measured on a real client store I migrated: 80,000 product catalog, 2,000 concurrent shoppers during a Black Friday hour. Switching from free Redis Object Cache to Object Cache Pro dropped average TTFB from 380ms to 210ms, on the same hardware. Saved the client from having to scale up their hosting tier mid-event.
Use it when: 5,000+ products, real concurrent traffic, and your TTFB on /shop is above 250ms. Or you're on a managed host that doesn't include a curated object cache (most are bundling it now — check before paying).
Skip it when: small store, low traffic, or your hosting (Kinsta, WP Engine, Cloudways, Pantheon) already ships Object Cache Pro as part of the plan. Don't pay twice.
4. Redis Object Cache (free) — the entry-level object cache that gets you 70% of the gain
If you can't justify $95/month but you have a Redis instance available (most VPS hosts let you apt install redis-server for free), the free Redis Object Cache plugin by Till Krüss is the right answer. It plugs WordPress's object cache layer into Redis, no code changes, one click to activate.
What you don't get: the async write batching, pipelining, and tuned client that Object Cache Pro ships. What you do get: the bulk of the win from putting WC's option/meta/transient reads in memory instead of MySQL.
On the same 80,000-product client store, free Redis Object Cache took TTFB from 580ms (no object cache) to 380ms. That's the lion's share of the available gain — Object Cache Pro on top added another 170ms but cost real money. For most stores, free Redis Object Cache is enough.
Use it when: you have any kind of WC store and your host exposes Redis. This is the single highest-ROI free plugin on this list.
Skip it when: your host doesn't run Redis (most shared hosts don't), or your managed host already enables an object cache automatically.
5. Perfmatters — for stripping the assets WooCommerce loads where it doesn't need to
Perfmatters doesn't cache anything. It does one thing for WC stores specifically: it lets you turn off WooCommerce assets on pages where WC has no business loading them.
The default WC behaviour is to enqueue several CSS and JS files on every single page — woocommerce.css, wc-cart-fragments.js, the select2 library, a few sprite icons. On a WC store, those load on your About page, your contact form, your blog posts, anywhere. Perfmatters' script manager lets you navigate to a specific URL, see every asset loading there, and click to disable it on that URL or globally.
The cart fragments script is the famous one. It's a JS bundle that fires an AJAX request to update the cart icon count on every single page load, including pages with no cart icon. On a busy store this is responsible for a measurable chunk of admin-ajax traffic; disabling it on non-shop pages is a free win.
I covered the WooCommerce-specific version of this dequeue pattern in a longer post about disabling WooCommerce on non-shop pages — same theme, more depth on the dependency safety nets you need.
Use it when: you have a content-heavy WC store (e.g. a blog + shop combo) and the Network tab shows WC assets loading on URLs that have no shop content. The $25/year is the cheapest line item in this entire post.
Skip it when: you have a small store with five plugins and no non-shop content. The configuration overhead doesn't pay back.
6. WP-Optimize — database cleanup that actually matters for WC
WP-Optimize is half a caching plugin (mediocre) and half a database cleanup tool (genuinely useful on WC stores). The DB half is what you install it for.
WooCommerce accumulates four kinds of cruft faster than any other plugin:
- Expired transients — WC creates transients for cart sessions, shipping zone caches, tax rate lookups, and currency conversion rates. They expire on schedule but the rows stay in
wp_options. On a year-old WC site I've seen 200,000+ expired transients still sitting in the database. - Action Scheduler logs — every recurring task WC schedules (renewal emails, subscription rebills, abandoned cart triggers) leaves a row in
wp_actionscheduler_logs. Six-month-old stores carry millions. - Order metadata — WC stores every cart line, every shipping address change, every customer note as
wp_postmeta. Old orders accumulate. - Variation post meta — variable products create a separate post for each variation. A 1,000-product catalog with 5 variations each = 6,000 posts, all with their own metadata.
WP-Optimize cleans all of this. Run it once a month on a busy WC store and it'll trim 200+ MB off the database easily, which makes backups faster and admin queries snappier.
Use it when: your WC store is older than six months. Run it manually, watch the numbers, schedule monthly if you trust the result.
Skip it when: the store is fresh, or you're already running Action Scheduler Optimizer (next entry).
7. Action Scheduler Optimizer — the silent killer of large WC stores
This is the plugin nobody talks about because nobody knows Action Scheduler is the problem. But on a WC store with subscriptions, abandoned cart automation, or any kind of recurring email logic, Action Scheduler runs millions of jobs over a year, and the wp_actionscheduler_actions and wp_actionscheduler_logs tables grow without bounds.
I've audited stores where Action Scheduler tables were 4GB on disk. WC was making SELECT FROM wp_actionscheduler_actions WHERE status='pending' queries on every cron tick, taking 2-3 seconds each. The admin dashboard was unusable.
The fix is either run a stand-alone Action Scheduler cleanup plugin, or — and this is what most managed WC hosts do internally — set Action Scheduler's retention to 7 days and aggressively prune completed/failed actions. There are several free plugins that do this; the most maintained right now is Marcin Dudek's WP Multitool, which includes a dedicated Action Scheduler Optimizer module. ($199/year, also covers a dozen other diagnostic tools.)
You can also do this by hand:
DELETE FROM wp_actionscheduler_logs WHERE log_date_gmt < DATE_SUB(NOW(), INTERVAL 7 DAY);
DELETE FROM wp_actionscheduler_actions WHERE status IN ('complete', 'failed') AND scheduled_date_gmt < DATE_SUB(NOW(), INTERVAL 7 DAY);Schedule it weekly. The tables stay sane.
Use it when: you run WC Subscriptions, AutomateWoo, abandoned cart recovery, or any plugin that uses Action Scheduler for background jobs.
Skip it when: small store with no automation. Action Scheduler isn't a problem yet.
8. NitroPack — auto-pilot, but read the WC failure modes first
NitroPack is the "you install it and never think about it" speed plugin. It routes your traffic through their CDN, generates critical CSS server-side, optimises images, defers JS, all automatically. For a content site this often works wonderfully. For WooCommerce it's more complicated.
What goes wrong on WC stores specifically:
- Critical CSS generation is page-by-page. NitroPack's critical CSS engine visits each unique URL, screenshots it, extracts above-the-fold CSS. For a 10,000-product catalog this takes weeks to complete, and during that time pages render unstyled for a second before settling — a noticeable trust killer on a shop.
- Image optimisation occasionally munges product photos. Photographers and jewellery stores hate this. The auto-WebP conversion shifts colours subtly enough that nobody notices until a customer returns a product because "it looked browner in the photo."
- Pricing is per-pageview. A WC store with seasonal traffic spikes can blow through pageview tiers without warning. The $40/month plan caps at a number that a Black Friday spike will obliterate.
Use it when: you have a small-to-medium WC store, you have budget, you don't want to spend any time tuning, and your products aren't visually sensitive.
Skip it when: photography sites, large catalogs, or anywhere a flash of unstyled content during peak hours would cost you actual sales. Also when you want any kind of fine-grained control over what the plugin is doing.
9. Disable Cart Fragments (free, single-purpose) — the smallest plugin that moves the most needle
This is the single most installed "WC speed fix" plugin out there, and for good reason. It exists to disable WooCommerce's wc-cart-fragments.js script on pages where it doesn't need to fire, which (for most stores) is everywhere except the shop, cart, and checkout pages.
The cart fragments script is responsible for keeping the cart icon count fresh as the customer adds items. It fires an AJAX request on every page load to do this. On a busy WC store with 1,000 page views an hour, that's 1,000 extra admin-ajax requests an hour, each one booting full WordPress.
Disabling it on non-shop pages is a single config toggle and saves a meaningful amount of server load. The downside is the cart icon won't auto-update on the pages where you disabled it, but most themes only show the cart icon on shop pages anyway.
Use it when: any WC store. If you're running Perfmatters this is already covered; otherwise install this and forget it.
Skip it when: every page on your site needs the cart count to be live (rare — usually a membership shop or single-page checkout flow).
10. WP Super Cache — the boring free option that still works
WP Super Cache is the boring grandparent of WordPress caching plugins. Maintained by Automattic, free forever, simple to configure, generates static HTML files served directly by Apache or NGINX. Like WP Rocket, it auto-detects WC and excludes the cart/checkout/account routes. Like WP Rocket, it does nothing for those exact pages.
For a small WC store on shared hosting where the $59/year for WP Rocket is real money, WP Super Cache is genuinely fine. You won't get the WP Rocket polish — no automatic database cleanup, no JS optimisation toggles, no Cloudflare integration — but the basic page cache works.
Use it when: shared hosting, tight budget, store is mostly public catalog browsing.
Skip it when: you have any budget at all. WP Rocket pays back the $59 in time-not-spent-configuring within a week.
What's not on this list, on purpose
- Hummingbird (WPMU DEV). Works, but the free tier is crippled to upsell the bundle. Better options exist.
- Smush, Imagify, ShortPixel. Image optimisers, not speed plugins. WC stores need image optimisation, but the category here is "speed plugins that change how WC runs," not "media library tools."
- Caching plugins that claim full checkout caching. Run away. Any plugin that promises to cache
/checkoutis either lying about what it caches, or is dangerously broken. - W3 Total Cache. Powerful, free, but the UI hasn't been updated in a decade and the WC integration is fragile. Skip.
So which one should you actually install?
If you skipped to the bottom looking for an answer:
- Small WC store (under 500 products), shared hosting, tight budget: WP Super Cache + Disable Cart Fragments. Free. Won't break things.
- Small-to-medium WC store, content + shop combo, any budget: WP Rocket ($59/yr) + Perfmatters ($25/yr). The first caches the public pages, the second strips WC assets from non-shop URLs. They don't fight.
- Medium store, on LiteSpeed host: LiteSpeed Cache (free) + Object Cache Pro if budget allows. ESI on the cart fragment is a meaningful win.
- Large store, 5,000+ products, real concurrent traffic: Object Cache Pro + WP Rocket + Action Scheduler cleanup. If your TTFB is still above 250ms on the cart and checkout, that's the gap structural plugins fill.
- You don't want to think and have budget: NitroPack. Watch the pricing, test critical CSS rendering carefully.
Where AcceleratorWP fits (the one mention)
Quick disclosure as promised: I make AcceleratorWP and it sits in a different category from everything above. The plugins on this list cache responses, optimise assets, or trim database cruft. AcceleratorWP runs at the mu-plugin layer and decides which plugins boot at all on a given request — which means WooCommerce doesn't load on your About page, the WC analytics tracker doesn't fire on a REST call to fetch posts, and the cart fragments AJAX endpoint can be isolated from the rest of the plugin stack.
Architecturally we sit a layer below WP Rocket and friends, which is why you can run both. Caching plugins replay stored HTML for the requests they can cache; we cut the work for the requests they can't — cart, checkout, account, admin-ajax, REST.
On real WC store benchmarks (Hello Elementor + WC + Bookly + MailPoet + Jetpack + Akismet, vanilla install, no other speed plugins), accepting the setup wizard's defaults moved PageSpeed Insights mobile by −31% LCP and −54% Speed Index, with TBT dropping from 90ms to 0. 5 runs per state, median value, no caching layer involved. The full methodology and PSI URLs are in the LinkedIn thread we shipped with the release.
The deep-dive companion posts if you want the structural angle: how to disable WooCommerce on non-shop pages covers the dequeue pattern with the WC-specific failure modes, the load-WordPress-plugin-on-specific-pages walkthrough generalises the technique to any plugin, and the cache-free performance survey puts both in context with the other techniques that compound with them.
What I'd really love is for the next "best WooCommerce speed plugins" post you find on Google to be honest about which plugins broke a real checkout, which ones save real money, and which ones are affiliate revenue dressed up as advice. Maybe this is one. Send corrections and disagreements to my inbox — I update the post when I'm wrong.