Warmup Cache Request for E-commerce Sites: Speed Up Product Pages

A warmup cache request on an e-commerce site is not the same job as warming a blog. Product pages carry live stock counts, personalized pricing, cart widgets, and currency variations. Cache them wrong and you either serve stale prices or you serve no speed benefit at all. This guide covers how to run a warmup cache request that actually works on WooCommerce and similar stores.

Why E-commerce Sites Need a Different Cache Warmup Strategy

A blog has mostly static pages. A store has pages built from constantly changing data: stock levels, prices, reviews, and cart contents. A generic warmup cache request that treats every URL the same way will either break checkout or leave dynamic elements uncached and slow.

The core challenge is separating what stays the same for every visitor from what changes per session. Product title, description, images, and base price are usually identical for every guest visitor. Cart contents, wholesale pricing, and inventory countdown widgets are not. A warmup strategy for e-commerce has to draw that line clearly before it touches a single URL.

Category pages, product pages, and the shop archive are almost always safe to cache and warm. Cart, checkout, and account pages are almost never safe to fully cache, regardless of how fast that would make them.

The Real Cost of a Cold Product Page

A cold product page after a cache purge can push Time to First Byte past 500ms on a mid-size catalog, compared to under 100ms for a warm one. That gap matters more on a store than a blog, because product pages are where purchase decisions happen.

Conversion data across e-commerce studies consistently shows that every 100ms of added latency can reduce conversion rate by roughly 1%. A store doing $50,000 a month in revenue can lose real money to a slow product page during a busy sales window, not just a slightly annoyed visitor.

The damage compounds during high-traffic events. A flash sale or a Black Friday spike hits your catalog right after a deployment or cache clear, which is exactly when the cache is coldest and server load is highest. Without a warmup cache request running ahead of that traffic, the first wave of shoppers rebuilds every page from scratch under peak load.

What You Can and Cannot Cache on a WooCommerce Store

Product pages, category archives, the main shop page, and search results are generally cacheable for guest visitors, as long as pricing is not personalized by role or login status. WooCommerce ships with this exclusion logic built in for a reason: the platform assumes cart, checkout, and my-account pages are dynamic and should not be fully cached.

Never fully cache the cart page, checkout page, or account dashboard. Caching these risks a serious bug where one visitor sees another visitor’s cart contents, since the cached HTML gets served to every subsequent guest regardless of session. This is not a theoretical risk. Store owners have reported exactly this failure after misconfigured full-page caching.

Product pages need a second look if you run role-based or wholesale pricing. If a logged-in wholesale buyer and a guest see different prices on the same URL, that page needs private cache or Edge Side Includes rather than a single public cached version. LiteSpeed Cache offers ESI specifically for this case, letting the surrounding page stay cached while the price block renders per visitor.

Warmup Cache Request Methods for E-commerce Compared

Method	Handles Cart Fragments	Handles AJAX/JS Content	Best For
WP Rocket Preload	Partial, via helper plugin	No, HTML only	Small to mid-size catalogs
LiteSpeed Cache + ESI	Yes, via ESI blocks	No	LiteSpeed-hosted WooCommerce stores
Dedicated WooCommerce plugin (Mamba Cache)	Yes, session-aware	No	Stores needing granular WooCommerce logic
Headless browser warmup (Puppeteer)	Yes, full render	Yes	Large catalogs, JS-heavy themes
k6 or curl loop warmup	No	No	Simple HTML-only warmup at scale

A plain curl or wget loop is enough for catalogs where product pages are pure server-rendered HTML. If your theme loads reviews, related products, or pricing widgets through JavaScript after page load, a curl-based warmup cache request will cache an incomplete page. Puppeteer or a similar headless browser waits for the network to go idle before capturing the page, which catches those JS-rendered elements.

Handling Cart Fragments, Pricing, and Stock Before You Warm Up

WooCommerce runs a script called wc-cart-fragments that fires an AJAX request on nearly every page load to keep the mini-cart widget current. This request is not cacheable, since cart contents differ by visitor, and it can account for a large share of total server requests on a busy store.

Before setting up any warmup cache request, check whether this fragment request fires on pages where you don’t actually need it. Open browser DevTools, filter the Network tab by wc-ajax, and see if get_refreshed_fragments loads on product and category pages. If your theme doesn’t display a mini-cart outside the cart and checkout pages, disable the script there with wp_dequeue_script('wc-cart-fragments'), scoped to those templates only.

Stock and pricing freshness is the other risk. If your cache TTL is longer than how often stock changes, a warmed product page can show “in stock” after the last unit sold. Set a shorter TTL on high-turnover products, or configure your caching plugin to purge and re-warm a specific product page automatically when its stock or price updates, rather than waiting for the cache to expire naturally.

How to Set Up a Warmup Cache Request for Product Pages

Step 1: Confirm Your Caching Layer Excludes Dynamic Pages

Before adding any warmup tool, verify cart, checkout, and account URLs are excluded from full-page caching in your existing plugin settings. WP Rocket, LiteSpeed Cache, and W3 Total Cache all exclude these by default, but always confirm manually since a misconfigured theme can add custom cart endpoints your plugin does not recognize.

Step 2: Build a Priority URL List

Do not warm your entire catalog with equal priority. Start with the shop homepage, top-level category pages, and your best-selling products. Warming category pages before individual products primes shared template fragments, such as the header and sidebar, that every product page reuses.

Export your top 100 to 500 products by traffic or revenue from your analytics tool, and put that list first in your warmup queue. A 10,000-product catalog does not need every page warmed on every cycle. Bestsellers and current landing pages carry most of the traffic.

Step 3: Configure Warmup Tool Exclusions

Whichever tool you use, explicitly exclude /cart/, /checkout/, /my-account/, and any custom subscription or membership URLs from the warmup URL list. Most dedicated WooCommerce cache plugins, including Mamba Cache, exclude these by default, but manual cron-based setups need this added explicitly.

Step 4: Schedule Warmup After Every Purge and Before Peak Traffic

Trigger the warmup cache request automatically after any product update, price change, or stock change that clears cache for that page. Set a secondary scheduled run before known high-traffic windows, such as an hour before a scheduled sale launch.

Warming Dynamic Fragments and AJAX Endpoints

A curl or wget loop only captures the initial HTML response. If your theme loads reviews, related products, or a price widget through JavaScript after the page loads, that content is missing from a curl-warmed cache.

Puppeteer solves this by rendering the page like a real browser and waiting for network activity to settle:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  const urls = require('./product-urls.json');

  for (const url of urls) {
    await page.goto(url, { waitUntil: 'networkidle0', timeout: 30000 });
    console.log(`Warmed: ${url}`);
    await new Promise(r => setTimeout(r, 300));
  }

  await browser.close();
})();

This script visits each product URL, waits until network requests finish, and moves to the next one with a 300 millisecond delay. Run it as a scheduled job after deployments or price syncs, invoked through a CI/CD pipeline or a simple cron entry calling node warmup.js.

For high-scale warmup across thousands of URLs, k6 offers concurrent request handling that a single-threaded curl loop cannot match, though it does not render JavaScript the way Puppeteer does.

Best Practices for Warming Cache on Large Catalogs

Sequence warmup logically. Warm the shop homepage and top category pages first, since product pages often depend on shared template fragments those pages also load. This order reduces redundant work across the warmup run.

Set concurrency based on server capacity, not catalog size. A dedicated WooCommerce cache plugin with configurable concurrency lets you run 1 to 10 parallel requests depending on your hosting tier. Shared hosting should stay near the low end, while a dedicated server can handle higher concurrency safely.

Warm desktop and mobile variants separately if your theme serves different markup by device. Rotate user agents in your warmup script to match real traffic patterns, since a crawler using only a desktop user agent leaves the mobile cache cold.

Version your warmup URL list. Keep the list of priority product and category URLs in version control alongside your deployment scripts, so a new team member or a new environment can reproduce the same warmup behavior without guesswork.

Multi-Currency and Geolocation Considerations

A server-side crawler runs from a single IP address and geographic location. If your store uses WooCommerce geolocation for per-country pricing or currency, a warmup cache request from your server only primes the cache for that one location’s pricing variant.

Visitors from other countries or currencies will still hit an uncached page on their first visit, since the cached version reflects only the crawler’s detected location. A CDN with edge caching across multiple regions, such as Cloudflare or QUIC.cloud, partially solves this by caching responses at each edge location as real traffic from that region arrives, but a single-origin crawler cannot pre-warm every currency variant on its own.

If multi-currency coverage matters for your store, consider running warmup requests from multiple regions using cloud functions or a distributed load-testing tool, one per currency zone you need pre-warmed.

How to Verify Product Page Cache Is Actually Warm

Check response headers on a sample of product URLs after a warmup run:

curl -I https://yourstore.com/product/example-item/

Look for a cache-hit header specific to your stack, such as x-litespeed-cache: hit or a plugin-specific header confirming the page came from cache rather than PHP. A miss means the crawler has not reached that URL yet, or the page failed to cache due to a redirect or an error response.

Test cart functionality immediately after any warmup change. Add a product to cart as a guest, reload a cached product page, and confirm the mini-cart widget still reflects the correct item count. This single test catches the most common warmup mistake: cached cart fragments showing stale or shared data.

Monitor cache hit ratio over a full day, not just immediately after a purge. A healthy e-commerce warmup setup should show hit ratio recovering to 90% or higher within minutes after a purge, and staying above that baseline through normal traffic.

Common E-commerce Cache Warmup Mistakes

Warming cart or checkout pages by accident. Double check your exclusion list every time you add a new payment gateway, subscription plugin, or custom checkout flow, since new plugins can introduce new dynamic URLs your exclusion list does not yet cover.

Ignoring JavaScript-rendered content. If your warmup tool only captures raw HTML and your theme loads pricing or stock badges through JavaScript, the cached page looks fine to the crawler but shows a broken or empty state to real visitors.

Treating every product with equal priority. Warming 10,000 low-traffic product pages on the same schedule as your 50 bestsellers wastes server resources and delays warmup for the pages that matter most.

Forgetting stock and price freshness. A long cache TTL paired with frequent stock changes creates a real risk of showing “in stock” on a sold-out product. Match TTL to how often your inventory actually changes.

FAQ

Can I warm the cache for WooCommerce cart and checkout pages?

No. Cart and checkout pages display unique content for every visitor. Caching them can expose one customer’s cart or checkout session to another user. Always exclude these pages from full-page caching and cache warmup.

Does cache warmup work with dynamic pricing plugins?

Partially. Cache warmup works well when prices are identical for all guest visitors. If pricing changes based on user roles, login status, memberships, or wholesale tiers, use private caching or Edge Side Includes (ESI) instead of serving a single public cached version.

How often should I run a warmup cache request on a store?

Run a warmup cache request automatically after every product update, price change, stock update, or cache purge. It’s also a good idea to trigger a warmup before planned high-traffic events such as sales, product launches, or promotional campaigns.

Do I need a headless browser to warm e-commerce pages?

Only if your store relies on JavaScript to render important content after the initial page load. For server-side rendered pages, a simple curl or wget script is enough to generate cached pages effectively.

Can a warmup cache request handle multiple currencies?

Not from a single server location. A crawler running from one IP address usually warms the cache only for that region’s currency and pricing. Multi-currency stores typically require warmup requests from multiple geographic locations or a global CDN with edge caching to ensure every currency variant is cached properly.