WooCommerce and Full-Page Caching

April 3, 2026

Advanced

High

The Caching Problem WooCommerce Creates

Full-page caching is the single most effective performance optimization for WordPress. It stores a ready-made HTML copy of each page and serves it directly, bypassing PHP execution and database queries entirely. A cached page that takes 200ms to serve might take 2-3 seconds uncached. The difference is dramatic.

But WooCommerce breaks the fundamental assumption that makes page caching work: that the same URL serves the same content to every visitor.

The moment a visitor adds an item to their cart, WooCommerce starts a PHP session. That session means the visitor’s experience is now personalized — the cart icon shows a count, the mini-cart shows their items, and pricing may reflect their user role or location. A cached page cannot reflect any of this, so most caching plugins stop serving cached pages to visitors with active WooCommerce sessions.

Who Gets Cached and Who Does Not

The typical caching behavior on a WooCommerce site creates two distinct visitor populations:

Anonymous visitors — no items in cart, not logged in, no active session. These visitors get fully cached pages and experience fast load times. They represent the majority of traffic from search engines and social media.

Session visitors — have added an item to cart, are logged in, or have triggered any WooCommerce session cookie. These visitors bypass the page cache entirely and hit the full WordPress/WooCommerce PHP stack on every page load.

This split is where the lab-vs-field performance gap comes from on WooCommerce sites. A lab test in PageSpeed Insights visits as an anonymous user and gets the cached version. Your field data in CrUX includes both populations — and the session visitors pulling the metrics down are often your most valuable users: the ones actively shopping.

Why the Cart Fragment Script Matters Here

WooCommerce loads a script called wc-cart-fragments on every page. This script fires an AJAX request on page load to check the current cart state and update the cart icon and mini-cart widget. That AJAX request hits the server uncached every time, even on pages that are otherwise fully cached.

The cart fragment request is a separate concern from page caching, but it compounds the problem. Even when a page is served from cache, the cart fragment AJAX call adds a server round-trip that affects Time to Interactive and can delay rendering if the cart widget is in the header.

The Session Cookie Problem

WooCommerce sets several cookies that caching plugins use to determine whether to serve a cached page:

woocommerce_items_in_cart — set when items are added to cart
woocommerce_cart_hash — hash of cart contents
wp_woocommerce_session_* — the main session cookie

When any of these cookies are present, caching plugins typically bypass the cache. The challenge is that these cookies can persist even after the cart is emptied, depending on the caching plugin’s configuration. A visitor who added an item and then removed it may continue receiving uncached pages for the duration of their session.

Some caching configurations are more aggressive — they serve cached pages regardless of WooCommerce cookies and rely on JavaScript (like cart fragments) to update dynamic elements client-side. This approach delivers faster page loads but requires careful testing to ensure cart state, pricing, and user-specific content display correctly.

Pages That Should Never Be Cached

Regardless of configuration, certain WooCommerce pages must never be cached because their content is inherently user-specific:

Cart page — shows the visitor’s specific items, quantities, and pricing
Checkout page — contains form state, payment fields, and order details
My Account pages — order history, addresses, account details

Most caching plugins automatically exclude these pages based on WooCommerce’s default page settings. Problems arise when custom checkout flows, one-page checkouts, or AJAX-based carts use non-standard URLs that the caching plugin does not know to exclude.

Object Cache vs Page Cache

For the session visitors who bypass page caching, object caching becomes the primary performance lever. Object caching (Redis or Memcached) stores database query results in memory, so even when WordPress must execute PHP for every page load, it does not have to query the database for every piece of data.

On a WooCommerce site with object caching, an uncached page load might take 800ms instead of 200ms (cached) — a meaningful regression, but far better than the 3+ seconds it would take without any caching layer.

The cache hit ratio of your object cache indicates how effectively it is reducing database load. On a well-configured WooCommerce site, object cache hit ratios above 90% are typical and significantly improve the experience for session visitors.

Why This Makes CWV Optimization Harder

The caching split means that optimizing a WooCommerce site for Core Web Vitals requires addressing two different performance profiles. The cached experience and the uncached experience are effectively different sites from a performance perspective, and the field data in CrUX reflects both.

This is one of the reasons WooCommerce CWV optimization requires a different approach than optimizing a standard WordPress site. It is not a plugin problem — it is an architecture problem that requires understanding how WooCommerce sessions, caching layers, and browser behavior interact under real traffic conditions.

Tools That Can Help

WP Rocket handles WooCommerce caching well out of the box — it automatically excludes cart, checkout, and my-account pages, and includes options for cart fragment optimization. Its “Delay JavaScript Execution” feature can also help with the frontend impact of the cart fragment script.

LiteSpeed Cache (for LiteSpeed web servers) has deep WooCommerce integration including ESI (Edge Side Includes) support, which lets you cache the page body while keeping the cart widget dynamic — the best of both worlds, though it requires a LiteSpeed server.

Redis Object Cache or Object Cache Pro provide the persistent object caching layer that helps session visitors who bypass page cache. Most managed WordPress hosts include Redis; you just need the WordPress plugin to connect to it.