How to Speed Up WooCommerce: A Front-End Performance Guide

A standard WordPress site and a WooCommerce storefront are not the same performance problem. WooCommerce adds session management, cart fragment AJAX requests, dynamic pricing queries, and database tables that a plain WordPress install does not have. The result is a heavier baseline load time even before you add a theme and a plugin stack on top. The fixes are mostly specific rather than generic; general WordPress performance advice will get you some of the way there, but the meaningful gains come from addressing what WooCommerce itself adds.

This guide covers front-end and storefront performance: shop pages, product pages, archive pages, and the checkout flow. WooCommerce admin performance (the dashboard, order list, and product editor) is a different problem covered separately.

Why WooCommerce Is Slower Than Standard WordPress

Three things make WooCommerce storefronts slower than a standard WordPress site by default.

The first is cart fragments. By default, WooCommerce sends an AJAX request on every page load to update the mini-cart widget, even on pages where there is no cart widget and no reason to check. This request is called wc-ajax=get_refreshed_fragments and it fires on every page in the store regardless of whether the visitor has ever interacted with the cart. The request blocks other resources from loading on slow connections and adds to the request count on every page.

The second is session handling. WooCommerce creates a PHP session record for every visitor, including those who have never interacted with the cart. These session records accumulate in wp_woocommerce_sessions. On a busy store, this table grows to millions of rows, and database queries that touch it slow down proportionally with the row count.

The third is query count. Product archive pages run more database queries than a standard WordPress blog archive: pricing queries, stock status checks, variable product attribute lookups, and potentially promotional logic all add to the query count on each page load.

Fixing the Cart Fragment Problem

The cart fragments AJAX request should only fire when a visitor has items in their cart, not on every page load. The WooCommerce native approach is to dequeue the wc-cart-fragments script on pages that do not need it.

Add this to your theme's functions.php or a custom plugin:

add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_cart() && ! is_checkout() && ! is_account_page() ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
} );

This removes the cart fragments script from all pages except the cart, checkout, and account pages. The mini-cart widget will not update dynamically immediately after a product is added to the cart; to work around this, set WooCommerce to redirect to the cart page after adding items (in WooCommerce > Settings > Products), or accept that the count updates on the next page load rather than in real time. For most stores, the performance gain outweighs this trade-off.

If you are using a theme or page builder with a header cart, test this change carefully before deploying to production. Some header cart implementations rely on fragment refresh for their real-time count display.

Configuring Page Caching for WooCommerce

Page caching stores a static HTML version of a page and serves it without hitting PHP or the database. WooCommerce complicates this because certain pages must not be cached: the cart, checkout, and account pages contain user-specific content that must be generated fresh on every request.

Most caching plugins handle WooCommerce exclusions automatically when WooCommerce is detected. If you are configuring exclusions manually, add these URL patterns to your excluded pages list:

• /cart/
• /checkout/
• /my-account/
• Any page using the [woocommerce_cart] or [woocommerce_checkout] shortcode

Product pages and shop archive pages can and should be cached. A product page with static pricing, stock status, and description is safe to cache for several minutes. If your pricing or stock levels change frequently, set a shorter cache TTL on product pages rather than excluding them from caching entirely.

Adding Redis Object Caching

Object caching stores the results of expensive database queries in memory so subsequent requests retrieve cached results rather than querying the database. For WooCommerce, this primarily benefits product catalogue queries, pricing lookups, and any database-intensive operation that repeats across page loads.

Follow the Redis object cache setup guide to install and configure Redis. With a running Redis instance and the Redis Object Cache plugin enabled, WooCommerce's expensive repeated queries are served from memory on subsequent requests. A cache hit rate above 80% is a reasonable target for a WooCommerce store with a stable product catalogue.

Optimising Product Images

Product images are the single largest contributor to page weight on most WooCommerce shop pages. A shop archive showing 24 products with 400x400 JPEGs at 200-400KB each is loading 5-10MB of images before a visitor has scrolled anywhere. Two changes have the largest impact: compressing images on upload and lazy loading images that are not in the initial viewport.

For compression, install Imagify, ShortPixel, or Smush. These convert uploaded images to WebP format and compress them automatically. WebP images are 30-50% smaller than JPEG at equivalent visual quality. After installing, run the bulk optimisation tool to recompress your existing image library.

WordPress has had native lazy loading since version 5.5: the loading="lazy" attribute is added automatically to images below the fold. WooCommerce product images receive this attribute by default in recent versions. Confirm it is active by inspecting a product image element on your shop page; if loading="lazy" is absent, check whether your theme or page builder is overriding WooCommerce's default image output.

Reducing Plugin Overhead

Every active plugin adds PHP execution time and potentially database queries to every page load. WooCommerce stores accumulate plugins over time: payment gateways, review tools, loyalty programmes, wishlist functionality, currency switchers. The cumulative overhead is often more significant than any individual plugin.

The practical approach is to audit what is active and remove anything not in use. Deactivated plugins add no overhead. The problem is plugins that load on the front-end, inject JavaScript into every page, or run database queries on every request regardless of context.

Use Query Monitor to identify which plugins are adding the most database queries per page load on your shop and product pages. Sort by query count, identify the top contributors, and check whether each is providing active value. A plugin adding 20 database queries per page that is used by 5% of your customers is probably not worth keeping in its current form.

Cleaning Up the WooCommerce Database

WooCommerce accumulates data over time that is no longer needed and that slows down queries against the affected tables.

The most significant table to clean is wp_woocommerce_sessions. Every visitor gets a session record, and old records are not aggressively cleaned up by default. On a busy store, this table can grow to millions of rows. Before running any cleanup, check the count of expired rows:

SELECT COUNT(*) FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();

Then delete them:

DELETE FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();

Run these via phpMyAdmin or your host's database tools. The WooCommerce status page under WooCommerce > Status > Tools also includes buttons to clear transients and expired sessions. Running these periodically keeps the database tables lean. A WooCommerce-aware database cleanup plugin like Advanced Database Cleaner can automate this on a schedule.

Hosting and Server Environment

The server environment is the floor that every other optimisation is built on. Shared hosting degrades under WooCommerce session load in a way that a VPS does not, because session writes on shared hosting compete with other customers' database connections for the same underlying resources. A VPS with dedicated database resources handles WooCommerce session throughput without the contention problem.

The combination that produces the best WooCommerce performance is Nginx with FastCGI caching or a page cache plugin, PHP-FPM with OPcache enabled, MariaDB, and Redis for object caching. A 2GB RAM VPS handles this stack comfortably for most store traffic levels.

Frequently Asked Questions

Why is WooCommerce so much slower than a standard WordPress site?

WooCommerce adds several performance costs that a plain WordPress install does not have. Every page load triggers a cart fragments AJAX request to update the mini-cart widget, even for visitors who have never added anything to their cart. Session records are created for every visitor and accumulate in the database without aggressive cleanup. Product archive pages run significantly more database queries than a blog archive because of pricing lookups, stock status checks, and variable product attribute resolution. On shared hosting, all of these are compounded by resource contention from other accounts on the same machine. The fixes in this guide address each of these specifically rather than applying generic WordPress performance advice that only partially solves the problem.

How do I stop WooCommerce from firing an AJAX request on every page load?

The wc-cart-fragments script, which is responsible for the AJAX request, can be dequeued on pages that do not need a live cart count. The code in the cart fragments section of this guide removes it from all pages except the cart, checkout, and account pages, which are the only ones that need to reflect real-time cart state. If you use WP Rocket, it handles this automatically via its WooCommerce settings panel. The trade-off is that the mini-cart widget will not update in real time immediately after a product is added to the cart; configure WooCommerce to redirect to the cart page after adding items, or accept that the count updates on the next page load rather than instantly.

Does WooCommerce need Redis?

Not strictly, but it makes a measurable difference on any store with meaningful traffic. Without Redis, WordPress repeats expensive database queries on every page load to fetch the same menus, options, pricing data, and product metadata. With Redis, those results are cached in memory after the first request and served from there on subsequent ones. The gains are most visible on product archive pages and checkout-adjacent pages where WooCommerce runs the most queries. The Redis setup guide covers installation; on Arcadia WordPress hosting, Redis is pre-installed and you can skip straight to enabling the plugin.

What is the fastest server setup for a WooCommerce store?

The combination that produces the best results is Nginx with FastCGI page caching, PHP-FPM with OPcache enabled, MariaDB, and Redis for object caching. Nginx's FastCGI cache serves cached product pages without hitting PHP at all, which handles the majority of front-end traffic. Redis eliminates repeated database queries for the requests that do reach PHP. PHP-FPM with OPcache means the PHP runtime is not recompiling scripts on every request. MariaDB performs better than MySQL for the read-heavy queries WooCommerce generates. A 2GB RAM VPS running this stack handles most WooCommerce store traffic without difficulty; 4GB gives you comfortable headroom for concurrent users and background jobs like order processing and scheduled inventory updates.

Quick Wins Checklist

• Remove the cart fragments script on non-cart pages
• Confirm page caching is active and excludes /cart, /checkout, /my-account
• Enable Redis object caching
• Run an image compression bulk job on the product image library
• Verify loading="lazy" is on product images below the fold
• Clear WooCommerce transients and expired sessions
• Audit active plugins and deactivate anything unused on the front end
• Confirm OPcache is enabled on the server (check via a phpinfo page)

Your Storefront Is Running Faster

You have addressed the main sources of WooCommerce's front-end overhead: cart fragments, page caching, Redis object caching, image weight, and session table bloat. The checklist above covers anything still outstanding.

If Redis is not yet set up, the Redis object cache guide walks through the full installation. For WooCommerce admin performance (the order list, dashboard, and product editor), that is a different problem worth addressing once the front end is in good shape.