Ecommerce Caching

E-commerce Caching

Overview

Implement multi-layer caching for e-commerce applications covering CDN edge caching, application-level caching (Redis), and full-page caching with cart-aware invalidation. This skill addresses the unique challenges of caching commerce pages — personalized content (cart count, logged-in state), frequently changing inventory and prices, and the need for instant cache purging when products or prices change.

When to Use This Skill

• When product and collection pages are slow due to database queries and API calls
• When implementing a CDN or edge caching strategy for a storefront
• When adding Redis caching for product data, inventory, and session management
• When building cache invalidation logic that reacts to product, price, or inventory changes
• When optimizing time-to-first-byte (TTFB) for high-traffic sale events

Core Instructions

Step 1: Determine your platform and what you can control

Step 2: Platform-specific caching configuration

---

Shopify

Shopify handles CDN and full-page caching automatically. Your optimization levers are:

Theme performance (Liquid): 1. Reduce the number of Liquid {% render %} calls in your product and collection templates — each render tag adds rendering time 2. In Online Store → Themes → Edit code, avoid loops that query the catalog repeatedly; use {% liquid %} blocks for conditional logic 3. Enable Shopify's Lazy loading for product images in Theme settings — this prevents below-fold images from blocking page load

App performance: 1. Audit your installed apps in Apps → App usage or with Shopify's Storefront Performance dashboard (Online Store → Themes → View report) 2. Apps that inject scripts into every page (especially checkout) can add 200–500ms per page load 3. Remove unused apps — even inactive apps with installed scripts slow down your store 4. For apps that add storefront JavaScript, check if they support Delayed loading (loads after page interactive) in their settings

CDN image optimization: Shopify automatically serves images via its CDN with WebP conversion and responsive sizing. To ensure you're using this: 1. Always use Shopify's Liquid img_url filter to generate image URLs — this routes through the Shopify CDN 2. Add width and height attributes to all <img> tags in your Liquid to prevent Cumulative Layout Shift 3. In Online Store → Themes → Customize → Theme settings → Images, verify lazy loading is enabled

---

WooCommerce

WooCommerce runs on your hosting infrastructure. Implement a three-layer caching stack:

Layer 1: PHP Object Cache (Redis) 1. Your hosting must support Redis (WP Engine, Kinsta, Cloudways, and most managed WordPress hosts do — check your control panel) 2. Install Redis Object Cache (free, wordpress.org) 3. Go to Settings → Redis and click Enable Object Cache 4. This caches all WordPress and WooCommerce database queries in Redis; most stores see 60–80% reduction in database load

Layer 2: Page Cache 1. Install WP Rocket ($59/yr — the most effective WordPress page cache plugin) or LiteSpeed Cache (free, if your host uses LiteSpeed) 2. In WP Rocket: go to Cache → Enable caching for logged-in WordPress users — keep this off; cached pages should only serve anonymous visitors 3. Enable Preload cache: WP Rocket will crawl and pre-cache your product and shop pages 4. Enable Separate cache file for mobile if your mobile and desktop layouts differ significantly

Layer 3: CDN 1. Configure Cloudflare (free tier available) as your CDN:

• Add your domain to Cloudflare and point DNS to Cloudflare's nameservers
• Install the Cloudflare WordPress plugin to enable cache purging from wp-admin
• Set Caching level to Standard in Cloudflare dashboard
• In WP Rocket, enable Cloudflare integration in the CDN settings — this allows WP Rocket to purge Cloudflare cache when you update products

2. Or use BunnyCDN ($1/mo for bandwidth) which integrates with WP Rocket natively

Cache invalidation for WooCommerce: WP Rocket and LiteSpeed Cache automatically purge cached pages when products are updated via the wp-admin. For programmatic updates, add this to your child theme's functions.php:

// Purge product page cache when inventory or price changes
add_action('woocommerce_product_set_stock', function($product) {
    if (function_exists('rocket_clean_post')) {
        rocket_clean_post($product->get_id()); // WP Rocket
    }
    if (class_exists('LiteSpeed_Cache_API')) {
        LiteSpeed_Cache_API::purge_post($product->get_id()); // LiteSpeed
    }
});

---

Custom / Headless

Cache layers for a headless Node.js storefront:

Browser → CDN (Cloudflare/Fastly) → Application server → Redis → Database
          [Static assets: 1yr]     [Product data: 5min]  [Catalog queries]
          [Product pages: 5min]
          [Cart: never]

HTTP cache headers by content type:

// middleware/cacheHeaders.js
export function setCacheHeaders(req, res, next) {
  const path = req.path;

  // Cart, checkout, account — never cache (personalized)
  if (path.startsWith('/cart') || path.startsWith('/checkout') || path.startsWith('/account')) {
    res.setHeader('Cache-Control', 'private, no-store');
    return next();
  }

  // Product pages — 5 min at CDN, serve stale while revalidating
  if (path.match(/^\/products\/[\w-]+$/)) {
    res.setHeader('Cache-Control', 'public, max-age=60, s-maxage=300, stale-while-revalidate=600');
    res.setHeader('Surrogate-Key', `product product-${path.split('/').pop()}`);
    return next();
  }

  // Collection pages
  if (path.match(/^\/collections\/[\w-]+$/)) {
    res.setHeader('Cache-Control', 'public, max-age=120, s-maxage=600, stale-while-revalidate=1200');
    res.setHeader('Surrogate-Key', `collection collection-${path.split('/').pop()}`);
    return next();
  }

  // Static assets with content hash in filename — immutable for 1 year
  if (path.match(/\.(js|css|png|jpg|webp|woff2|svg)(\?|$)/)) {
    res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');
    return next();
  }

  next();
}

Redis product cache (cache-aside pattern):

// lib/productCache.js
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

export async function getCachedProduct(productId, fetchFn) {
  const key = `product:${productId}`;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const product = await fetchFn();
  // Non-blocking write — serve response immediately
  redis.setex(key, 300, JSON.stringify(product)).catch(() => {});
  return product;
}

export async function invalidateProduct(productId, productSlug, collectionIds = []) {
  const keys = [
    `product:${productId}`,
    `product:slug:${productSlug}`,
    ...collectionIds.map(id => `collection:${id}`),
  ];
  await redis.del(...keys);
}

Personalized content (cart count, inventory) loaded client-side after cached page:

<!-- Serve the cached page with placeholder for personalized data -->
<span id="cart-count" data-hydrate="true">0</span>

<script>
  // Load personalized data after the cached page renders
  fetch('/api/session-data', { credentials: 'include' })
    .then(r => r.json())
    .then(data => {
      document.getElementById('cart-count').textContent = data.cartCount;
    });
</script>

// GET /api/session-data — NOT cached, reads from Redis
export async function sessionData(req, res) {
  res.setHeader('Cache-Control', 'private, no-store');
  const sessionId = req.cookies.session_id;
  const cartCount = sessionId ? await redis.get(`cart:count:${sessionId}`) : '0';
  res.json({ cartCount: parseInt(cartCount ?? '0') });
}

Event-driven cache invalidation:

// React to product/price changes from your webhook or admin
export async function onProductUpdated({ productId, productSlug, collectionIds }) {
  // 1. Invalidate Redis cache
  await invalidateProduct(productId, productSlug, collectionIds);

  // 2. Purge CDN (Cloudflare example)
  await fetch(`https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/purge_cache`, {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${CF_TOKEN}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({ tags: [`product-${productSlug}`] }), // tag-based purge (Cloudflare Enterprise)
    // For free/Pro Cloudflare, use files: [`https://store.com/products/${productSlug}`]
  });
}

Best Practices

• Use `stale-while-revalidate` — serve cached content instantly while fetching a fresh version in the background; this eliminates cache miss latency for users
• Cache the page, hydrate personalization client-side — cache full HTML for anonymous visitors and load cart count / inventory via a fast no-store API call
• Invalidate on stock-status change, not every inventory update — a quantity change from 50 to 49 doesn't need a purge; 1 to 0 (out-of-stock) does
• Strip tracking parameters for better CDN hit rates — ?utm_source=email&utm_campaign=spring creates unique cache entries; strip these at the CDN or in your URL normalization
• Monitor cache hit rate — target 90%+ at CDN; use X-Cache response headers to identify frequent cache misses

Common Pitfalls

Related Skills

• @flash-sale-scaling
• @edge-commerce
• @database-optimization-commerce
• @monitoring-alerting-commerce

E-commerce CDN and Reverse Proxy Caching Configuration

Problem/Feature Description

Prism Goods is a fast-growing direct-to-consumer brand that recently moved its storefront to a Node.js application behind Varnish and a CDN. Page load times are acceptable in testing but the team is seeing poor cache hit rates in production (around 30%) because cache headers are inconsistent across page types, tracking parameters from ad campaigns are generating thousands of unique cache keys, and the Varnish configuration is not stripping session cookies from cacheable pages.

The team wants a complete, consistent caching configuration that covers their Node.js middleware (for setting HTTP cache headers on every response type) and their Varnish VCL (for full-page caching at the reverse proxy). They need different caching rules for product listing pages, individual product pages, static assets, and cart/checkout flows. The configuration must also integrate with their CDN's targeted purging feature so that individual products can be purged without flushing everything. An important constraint is that their marketing team appends UTM and other tracking parameters to all URLs in ad campaigns, so the caching layer must handle these without fragmenting the cache.

Output Specification

Produce the following files:

• middleware/cache-headers.ts — Express/Node.js middleware that sets appropriate Cache-Control (and related) headers for each type of request path
• varnish.vcl — A Varnish 4.1 VCL configuration with vcl_recv, vcl_backend_response, and vcl_deliver subroutines covering product pages, collection pages, static assets, cart/checkout, and homepage
• docs/caching-strategy.md — A short document (bullet points are fine) summarising the TTL decisions made for each page type and explaining the CDN purging approach

The output should be complete enough that a developer can review the strategy and the operations team can deploy it.

Cache Invalidation System for a Live Commerce Platform

Problem/Feature Description

Vanta Shop runs a high-traffic online store with thousands of products. Their marketing team regularly updates prices for promotions, and the warehouse team adjusts inventory levels throughout the day. The current setup caches all product and collection pages at the CDN, but after price changes or inventory updates the site sometimes shows stale prices or incorrect stock availability for up to 10 minutes — until the cached pages expire naturally. During a recent sale, several customers checked out at the wrong price because the cache hadn't expired yet.

The engineering team needs a cache invalidation system that reacts to catalog events in real time. When a product's price changes, the right pages must be cleared immediately. Inventory changes are trickier: every warehouse adjustment should not flush the cache (there can be hundreds per hour), but customers must see accurate in/out-of-stock status. The team also has a requirement that product pages must be cacheable at the CDN edge for anonymous users, yet each visitor still sees their own live cart count and current inventory status — so the personalization approach must not break CDN caching.

Additionally, the collection listing pages are generated from a complex JOIN across several tables and the DBA wants to move that query to a pre-computed structure in PostgreSQL that can be updated without blocking concurrent reads.

Output Specification

Produce the following files:

• src/cache-invalidator.ts — A TypeScript CacheInvalidator class with handlers for product update, price change, inventory change, and bulk catalog update events. Include a brief JSDoc comment on each method explaining when it fires and what it does.
• src/personalization-api.ts — An Express route handler for a /api/personalization endpoint that returns cart count and inventory for a given product, with appropriate cache headers
• src/product-page-renderer.ts — A function that renders a product page HTML string. The rendered page should include placeholders for cart count and inventory status that are populated by a client-side script calling the personalization API
• db/collection-listing.sql — SQL statements to create and maintain the collection product listing data structure in PostgreSQL, along with the necessary index
• package.json — With the required dependencies listed

The code does not need to run end-to-end (stubs for external services like CDN purge APIs are fine), but the logic, structure, and configuration choices must be complete and correct.

Product Caching Service

Problem/Feature Description

Meridian Commerce is a mid-size online retailer whose Node.js backend makes heavy database calls on every product page request — fetching product data, variants, and images on each hit. During a recent flash sale, response times spiked to over 3 seconds and the site nearly went down under load. The engineering team wants to introduce an application-level caching layer that sits between the application and the database, so that frequently accessed product data is served from memory rather than hitting the database on every request.

The team uses TypeScript throughout their stack and already has a Redis instance available. They need a reusable ProductCache class that handles get, set, invalidation, and bulk cache warming — complete with sensible resilience settings for production. Performance is critical: cache writes must never block response delivery, and warming hundreds of products at once must be done as efficiently as possible. A separate scripts/warm-cache.ts script should also be provided that demonstrates warming the cache for a given collection.

Output Specification

Produce the following files:

• src/product-cache.ts — A TypeScript ProductCache class with methods for:
• Getting a product by ID
• Getting a product ID by slug
• Setting / caching a product (with TTL)
• Fetching with cache-aside logic (cache miss triggers fetch, result is cached)
• Invalidating a product (removing all keys related to it)
• Bulk warming the cache for a collection of products
• src/redis-client.ts — A module that creates and exports a configured Redis client instance
• scripts/warm-cache.ts — A standalone script that demonstrates warming the cache for a collection of products (can use mock/stub data)
• package.json — With the required dependencies listed

Input Files

The following type definitions are provided as inputs. Extract them before beginning.

=============== FILE: src/types.ts =============== export interface ProductVariant { id: string; title: string; price: number; inventoryQuantity: number; }

export interface Product { id: string; title: string; slug: string; status: 'active' | 'draft' | 'archived'; collectionIds: string[]; variants: ProductVariant[]; updatedAt: string; }