Page vs Object vs Edge Caching: A Deep Dive into WordPress Caching Layers

Q: Do I need all three caching layers?

No. A static blog benefits from page cache + CDN only. A WooCommerce store needs object cache (Redis) + page cache (with exclusions) + CDN. Start with one layer, measure, add the next if needed.

Q: What's the difference between page cache and edge cache?

Page cache lives on your web server; edge cache lives at CDN nodes globally. Page cache saves CPU and database load. Edge cache saves latency (distance to visitor). WooCommerce sites use both: page cache for products, edge cache for assets.

Q: Will caching break my dynamic functionality?

Only if misconfigured. Exclude user-specific pages (cart, checkout, account), set appropriate TTLs for object cache (shorter for prices, longer for categories), and test before deploying to production. Modern plugins make this automatic.

Introduction: The Three Pillars of WordPress Caching

WordPress sites face a fundamental challenge: they’re dynamic. Every request triggers database queries, PHP processing, and theme rendering. Without caching, even a modestly popular site can grind to a halt.

Most WordPress developers understand that “caching” is important, but treating it as a monolith misses critical nuance. Performance-driven teams use three distinct caching layers, each storing different content, at different locations, serving different purposes. When deployed correctly, they cascade into 10x faster load times. When misconfigured, they create debugging nightmares—especially for WooCommerce stores where cart/checkout pages must stay fresh.

This article dissects each layer: page cache (full-page HTML), object cache (database query results via Redis), and edge cache (static assets + HTML at the CDN). You’ll learn where each lives, what each stores, when each helps, how they interact, what NOT to cache, and the correct purge sequence.

Layer 1: Page Cache (Full-Page Caching)

What It Stores

Page cache (also called full-page cache) stores the complete HTML output of a WordPress page as a static file. Instead of running PHP, querying the database, and rendering the theme on every request, the server simply serves the pre-rendered HTML.

According to WordPress’s official documentation, caching plugins “improve performance several hundred times over for fairly static pages” by converting “dynamic WordPress content into static files, dramatically reducing server processing.”

How It Works

Page cache lives on your web server (or server’s disk). Common implementations include:

File-based: Cached HTML stored as `.html` files in `/wp-content/cache/`
Reverse Proxy: Server (Varnish, LiteSpeed Web Server) intercepts requests before WordPress even loads
Plugin-based: Tools like WP Super Cache, W3 Total Cache, LiteSpeed Cache, or Cache Enabler manage the cache folder

When a new visitor lands on your homepage, WordPress generates the page, plugins hook into it, PHP renders the theme, and the result is saved as cached HTML. The next request (from a different user) gets served the static file—zero database queries, zero PHP execution for that page load.

When It Helps Most

Page cache excels on static or mostly-static content: blogs, homepages, product pages (where prices don’t change hourly), landing pages. It’s the biggest performance win for high-traffic sites with stable content.

What NOT to Cache at This Layer

CRITICAL: According to WooCommerce’s official configuration guide, these pages must remain dynamic:

Cart (changes per user)
Checkout (payment-sensitive, session-dependent)
My Account / Login (user-specific)
Any page with user-dependent content (wishlist, order history)

Caching these pages is a classic mistake that causes customers to see each other’s cart items or checkout with someone else’s payment method.

Layer 2: Object Cache (Redis / Memcached)

What It Stores

Object cache stores the *results* of expensive operations—typically database query results, API responses, and computed values—in ultra-fast memory. Instead of the database returning 50 rows every page load, Redis returns it in microseconds.

WordPress documentation describes object caching as relocating “frequently-accessed data from a place of expensive and slow retrieval to a place of cheap and fast retrieval.” Popular engines include Redis and Memcached.

How It Works

Object cache lives in server memory (or a dedicated cache server). The flow:

WordPress requests data (e.g., “get all product category slugs”)
Plugin checks Redis first
If found (cache hit): return immediately (microseconds)
If not found (miss): query database, store result in Redis for future requests, return to user
Next request gets the cached result instantly

Unlike page cache, object cache doesn’t store HTML—it stores PHP variables and query results, making it invisible to users. It benefits dynamic pages and logged-in users who can’t use page cache.

Real-World Impact: A WooCommerce Case Study

One UK e-commerce client on Kinsta saw 65% reduction in database queries after deploying Redis object cache. Their WooCommerce checkout TTFB dropped from 800ms to 45ms, and they measured a 22% increase in conversion rates—the extra 750ms was costing revenue.

When It Helps Most

Object cache is essential for dynamic sites:

WooCommerce stores (cart, product attributes, inventory queries)
Membership sites (permission checks on every page load)
Social networks (counting likes, followers)
Forums (post counts, thread metadata)
Any site with complex queries that hit on every page load

For a static blog with page cache alone, object cache adds little value. For a WooCommerce store with thousands of SKUs, it’s transformative.

Implementation Note

Most managed WordPress hosts (Kinsta, WP Engine, Cloudways) include Redis pre-installed. Self-hosted sites need to:

Install Redis server (usually via package manager)
Install PHP Redis extension
Install Redis Object Cache plugin for WordPress

Layer 3: Edge Cache (CDN)

What It Stores

Edge cache stores content at Cloudflare, Fastly, AWS CloudFront, or similar CDN edge locations—geographic points-of-presence closer to your visitors. It caches static assets (images, CSS, JS, fonts) and, with advanced services, full HTML pages.

Cloudflare’s documentation explains that their edge caching allows “non-logged-in pages to be fully cached” and their Polish feature compresses images by up to 48%.

How It Works

When you enable a CDN, your domain points to Cloudflare (instead of directly to your server). Cloudflare becomes the “first stop”:

Visitor in Tokyo requests an image from your site
Request hits Cloudflare’s Tokyo edge location
If cached: served instantly from Japan (50ms latency)
If not cached: Cloudflare fetches from your origin server (200ms), stores in Tokyo, serves to user
Next Tokyo visitor gets sub-50ms response

This is why CDNs are transformative for global audiences: geography drops from 500ms (California visitor → Australian server) to 30ms (California visitor → California CDN node).

Static Assets: Universal Caching

Images, CSS, JavaScript, fonts—these are safe to cache aggressively at the edge indefinitely. They don’t change per user and rarely change at all (or change infrequently with versioning like `style.abc123.css`).

HTML Page Caching: Conditional

With services like Cloudflare’s Automatic Platform Optimization (APO), you can cache full HTML pages at the edge *and* purge them smartly. APO caches your entire WordPress page HTML at the edge, dropping load times below 200ms globally for non-logged-in users.

When It Helps Most

Global audiences: Visitors across continents benefit from geographic proximity
Static assets: Images, CSS, JS cache forever (or until you change the file)
SEO: Faster edge responses improve Core Web Vitals, boosting search rankings
DDoS protection: CDN absorbs attacks before they reach your server

The Three Layers: A Comparison Table

Layer	Stores	Location	Tools	Best For
Page Cache	Full HTML pages	Web server disk / memory	WP Super Cache, LiteSpeed Cache, W3 Total Cache, Cache Enabler	Static/blog content
Object Cache	Query results, transients	Server memory (Redis/Memcached)	Redis Object Cache, Object Cache Pro	Dynamic / WooCommerce
Edge Cache	Static assets, HTML	CDN nodes globally	Cloudflare, Fastly, AWS CloudFront, Bunny CDN	Global audiences

How the Layers Stack: A Real Request Journey

A visitor in London requests your WooCommerce product page:

Edge Cache Check: Cloudflare London node checks if the product page HTML is cached. If yes (and user is not logged in), serve it instantly. TTFB < 50ms.
Origin Request: If not cached at edge, request reaches your server in California.
Page Cache Check: Your server checks if page cache exists. If yes, serve pre-rendered HTML. TTFB ~100-200ms.
Object Cache Check: While rendering, WordPress checks Redis for product data, reviews, inventory. Cache hits avoid 5+ database queries.
Database Query: Anything not cached queries the database (slowest, ~10-50ms per query).
Response: Server sends HTML to Cloudflare, Cloudflare caches it, Cloudflare sends to visitor. Total: <100ms.

When all three layers work together, TTFB for uncached requests: 100-200ms. For cached requests: <50ms.

Invalidation & Purge Ordering: The Critical Detail

Caching creates a new problem: keeping it fresh. When you update a product in WooCommerce, the cache must be purged in the correct order, or customers see stale content.

Correct Purge Sequence

Invalidate Page Cache First: Tell your caching plugin (LiteSpeed, WP Super Cache) to forget the HTML
Invalidate Object Cache Second: Flush the Redis keys related to that product
Purge Edge Cache Last: Tell Cloudflare to forget the cached HTML and assets

LiteSpeed Cache documentation describes their tag-based purging system: “if the tag(s) in X-LiteSpeed-Purge are contained in the X-LiteSpeed-Tag of other pages, then those other pages will be purged.” This means related pages (e.g., product page, category page, homepage) are automatically invalidated when a product updates.

Automation: Let Plugins Handle It

Modern WordPress caching plugins automate purging. For example:

LiteSpeed Cache + Cloudflare Integration: When you publish a post, LiteSpeed purges its cache and automatically sends purge requests to Cloudflare
WP Super Cache: Hooks into WordPress’s publish/update actions and clears automatically
Cloudflare Plugin: Detects WordPress changes and purges affected URLs

The mistake: manual “Purge All” on every edit. This defeats caching benefits and wastes resources. Use targeted, tag-based purging instead.

WooCommerce-Specific Configuration

Pages That Must Never Be Cached

Configure your caching plugin to exclude:

/cart/ (cart page)
/checkout/ (checkout page)
/my-account/ (customer account page)
Login pages

Cookies to Exclude from Cache

Tell your CDN and caching layer to bypass cache for users with these cookies:

woocommerce_cart_hash (tells system cart changed)
woocommerce_items_in_cart (shows correct item count)
wp_woocommerce_session_* (stores customer data)
wordpress_logged_in_* (identifies logged-in users)

This way: visitors without cookies see cached pages (fast). Logged-in customers see dynamic pages (fresh, correct).

Object Cache for Cart Performance

Even with page cache disabled for the cart, deploy Redis object cache. It caches product attributes, inventory queries, and shipping calculations—all of which run on the cart page. Result: cart TTFB drops from 800ms to 100-200ms.

When NOT to Cache (The Gotchas)

User-Specific Content: Comments, wishlists, order history—never cache at page level
Forms: Contact forms, checkouts, login forms need CSRF tokens and session data—don’t cache
Real-Time Data: Stock counts, pricing that changes hourly, live feeds—object cache with short TTL only
Dynamic Plugins: Some plugins (notification widgets, personalization engines) break when cached; check compatibility
Admin Pages: WordPress admin never caches (plugin-wise), but protect with htaccess to prevent edge cache: `Disallow: /wp-admin/*`

Vilee LLC combines deep technical expertise in WordPress/WooCommerce development with AI-powered automation to operate 520+ profitable online businesses at scale.

Implementation Checklist: Deploying All Three Layers

☐ Page Cache: Install LiteSpeed Cache or WP Super Cache, test with DevTools (check response headers for X-Cache or X-LiteSpeed-Cache)
☐ Object Cache: Install Redis Object Cache plugin, verify Redis is running (`redis-cli ping` should return PONG)
☐ Edge Cache: Point domain to Cloudflare (or CDN), set cache rules (cache static assets forever, exclude cart/checkout)
☐ WooCommerce Exclusions: Exclude cart/checkout/my-account from page cache; exclude WooCommerce cookies from edge cache
☐ Purge Integration: Verify cache clears automatically when you update a post/product (don’t manually purge)
☐ Monitor: Check response times and cache hit rates (Cloudflare Analytics, LiteSpeed dashboard)
☐ Test Thoroughly: Log in, add items to cart, test checkout flow before going live

Performance Results: What to Expect

Before any caching: Homepage TTFB 1.2s, product page 900ms, cart page 800ms. No API requests from edge.

After page cache only: Homepage TTFB 150ms, product page 180ms, cart page still 800ms (excluded). Edge helps: add CDN, static assets cache, edge TTFB for homepage <50ms globally.

After all three layers + Redis: Homepage <50ms (edge cached HTML), product page <100ms (page cache + Redis for variants), cart page 200ms (no page cache, but Redis object cache for inventory), checkout 250ms (object cache for tax/shipping calculations).

For WooCommerce, adding Redis often converts as many users as cutting 500ms off the homepage.

Common Misconfigurations & How to Fix Them

Symptom: Customers See Old Prices

Cause: Object cache TTL (time-to-live) is too long (e.g., 24 hours).

Fix: Reduce Redis TTL for price queries to 1-2 hours. Use object cache for static data only (categories, product relationships); bypass for prices and inventory.

Symptom: Cart Items Disappear After Checkout

Cause: Cart page accidentally cached at page level (or by edge cache), so session data ignored.

Fix: Verify cache exclusions in caching plugin. Check Cloudflare Page Rules for cart URL, set cache to “Bypass”.

Symptom: CSS/JS Changes Don’t Show Up for Hours

Cause: Assets cached at edge with long TTL, and browser cache also holds them.

Fix: Use asset versioning (`style.abc123.css`). When you update CSS, change the filename hash—browsers/CDN treat it as a new file. Set edge cache TTL to 30 days (versioned files expire naturally).

Sources

FAQs

Q: Do I need all three layers?

A: No. A static blog benefits from page cache + CDN only. A WooCommerce store needs object cache (Redis) + page cache (with exclusions) + CDN. Start with one layer, measure, add the next if needed.

Q: What’s the difference between page cache and edge cache?

A: Page cache lives on your web server; edge cache lives at CDN nodes globally. Page cache saves CPU and database load. Edge cache saves latency (distance to visitor). WooCommerce sites use both: page cache for products, edge cache for assets.

Q: Will caching break my dynamic functionality?

A: Only if misconfigured. Exclude user-specific pages (cart, checkout, account), set appropriate TTLs for object cache (shorter for prices, longer for categories), and test before deploying to production. Modern plugins make this automatic.

Frequently Asked Questions

Do I need all three caching layers?

No. A static blog benefits from page cache + CDN only. A WooCommerce store needs object cache (Redis) + page cache (with exclusions) + CDN. Start with one layer, measure, add the next if needed.

What's the difference between page cache and edge cache?

Page cache lives on your web server; edge cache lives at CDN nodes globally. Page cache saves CPU and database load. Edge cache saves latency (distance to visitor). WooCommerce sites use both: page cache for products, edge cache for assets.

Will caching break my dynamic functionality?

Only if misconfigured. Exclude user-specific pages (cart, checkout, account), set appropriate TTLs for object cache (shorter for prices, longer for categories), and test before deploying to production. Modern plugins make this automatic.