30 WooCommerce Performance Tips That Actually Work (2026)

Cart fragments fire on every page load

Tip #1

Every page on your WooCommerce store fires a hidden AJAX request called wc-ajax=get_refreshed_fragments. It exists to update the cart icon in your header. And it boots the entire WordPress + WooCommerce stack to do it.

That's a full PHP execution on every page load that nobody sees in performance tests. Your users feel it though. If you don't use a mini-cart widget, one line fixes it:

wp_dequeue_script('wc-cart-fragments');

If you do use a mini-cart, at least limit this to shop pages - don't let it fire on your blog posts. I've seen this single change cut server load by 30% on stores with decent traffic.

Redis is evicting your customers' shopping carts

Tip #2

If you're using Redis for object cache, check your maxmemory-policy setting. The default is usually allkeys-lru, which means when Redis runs out of memory it evicts any key - including active WooCommerce cart sessions.

Customer fills a cart, browses for 10 minutes, goes to checkout: empty cart. Because Redis silently deleted their session during a traffic spike.

maxmemory-policy volatile-lru

Now Redis only evicts keys that have a TTL set. Your persistent cache keys survive; sessions with expiry get cycled naturally. Also run:

redis-cli INFO stats | grep evicted_keys

If that number keeps climbing, you need more memory or fewer cached things.

HPOS with sync enabled doubles every order write

Tip #3

WooCommerce's High Performance Order Storage moves orders from the slow wp_posts/wp_postmeta tables to dedicated tables. Real improvement. But by default it runs in compatibility mode with sync enabled - meaning every order write goes to both the old tables and the new ones. You're not saving database load, you're doubling it.

After verifying HPOS works and your plugins are compatible, disable sync: WooCommerce → Settings → Advanced → Features. You'll cut order-related database writes in half overnight.

Product lookup tables go stale silently

Tip #4

WooCommerce maintains a denormalized table called wp_wc_product_meta_lookup - it caches product prices, stock status, ratings. The problem: if you import products via CSV, use a bulk editor, or sync from an ERP, the lookup table doesn't update. WooCommerce only refreshes it through its own hooks.

So your prices are correct in wp_postmeta but the lookup table shows old data. Product sorting is wrong, filters show stale stock, on-sale products don't appear in sale queries.

Fix: WooCommerce → Status → Tools → Regenerate product lookup tables. I run into this at least once a month with stores that do any external data sync.

WooCommerce fires database writes you don't know about

Tip #5

WooCommerce periodically updates woocommerce_tracker_last_send, _transient_wc_count_comments, and various usage tracking options. Each one is a write to wp_options on an autoloaded row - which invalidates the entire alloptions cache ( catches these too.

Never use pm = dynamic for WooCommerce

Tip #18

PHP-FPM has three process management modes: static, dynamic, and ondemand. For WooCommerce, never use dynamic. It tries to scale workers up when needed, but the scaling has latency - forking new PHP processes takes time. During a checkout surge, customers wait while FPM spins up workers.

• 
  High-traffic stores: use pm = static. Workers are always warm, no fork overhead, predictable memory.


• 
  Spiky traffic: use pm = ondemand. Workers scale to zero between bursts, fork on demand. At least it's honest about the cold start.

Dynamic pretends to be smart about both scenarios and fails at both. Pick one.

Open source: I published my nginx config templates for WooCommerce at - 13 modules that find exactly this stuff: slow queries, bloated autoload, orphaned transients, heavy callbacks. All local, nothing leaves your server.

If any of these tips helped, the plugin will find more issues specific to your store.