Website Caching Explained: Page Cache vs Object Cache vs CDN Edge Cache

Overview

A cache keeps a reusable result closer to the next request. Instead of rebuilding a page, querying a database, or downloading an asset from the origin server every time, the system can serve a stored copy. The result can be lower origin load, faster response times, and more predictable performance. Caching does not replace suitable web hosting, efficient application code, or a reliable deployment process, but it can reduce repeated work at several points in the delivery path.

The three layers in this guide solve different problems:

• Page cache: stores a rendered HTTP response, usually HTML. It is particularly effective for public pages that are the same for many visitors.
• Object cache: stores individual pieces of application data, such as database query results, settings, or computed values. Redis object cache is a common example, but the correct implementation depends on the application and hosting environment.
• CDN edge cache: stores responses and static assets at geographically distributed edge locations, reducing the distance between a visitor and the cached content.

These layers can work together. A request might reach a CDN edge cache first. If the edge has no usable copy, it can request a page from the origin, where a server-side page cache may respond without running the full application. If the page must be generated, the application may use an object cache to avoid repeating database work. Each layer needs its own rules, expiration period, and invalidation method.

Cacheability is the starting question. Public product descriptions, blog posts, documentation, images, stylesheets, and versioned JavaScript files are often suitable for caching. Account pages, checkout steps, shopping carts, admin screens, and content containing private or user-specific data generally require bypass rules or carefully designed private caching. For a wider audit, use this website caching checklist to review cache headers, TTLs, and purging behavior.

Checklist by scenario

For a mostly public WordPress site

• Start with one page-cache mechanism: a host-level cache, web-server cache, or cache plugin. Avoid enabling overlapping full-page systems before you understand which layer is authoritative.
• Confirm that anonymous visitors receive cached HTML for suitable pages. Check response headers and compare the first request with a repeat request.
• Exclude logged-in users, previews, search results, and other personalized responses unless your setup explicitly supports them.
• Use long-lived browser caching for versioned static assets, while ensuring that asset filenames or query strategies change when files are updated. See the guide to browser caching for images, fonts, CSS, and JavaScript.
• Use an object cache only when the application benefits from it and the host supports it correctly. Object caching is not a substitute for page caching on a site whose main bottleneck is repeated HTML generation.

For WooCommerce or another ecommerce application

• Cache public catalog pages only when prices, stock, region, and customer-specific content are handled safely.
• Bypass or isolate the cart, checkout, account, payment, and order-confirmation paths.
• Test add-to-cart, login, logout, coupons, stock changes, and currency or tax selection from a clean browser session.
• Confirm that cache purging follows product, category, price, and inventory updates where stale content would affect a purchase.
• Review the practical rules in Bypass Cache on Login, Cart, and Personalized Pages before increasing TTLs.

For a custom application or API

• Define which responses are public, private, or uncacheable before adding a CDN rule.
• Set explicit Cache-Control behavior rather than relying on assumptions made by a proxy or framework.
• Use object caching for repeated, expensive data access, but establish a key format and invalidation approach.
• Consider server caching such as Nginx FastCGI cache or Varnish only after mapping request methods, cookies, authorization, and purge requirements.
• Measure cache hits and misses separately from application response time so that a fast cache hit does not hide a slow origin.

For a CDN or edge-caching rollout

• Begin with static assets and clearly public responses before caching dynamic HTML.
• Choose TTL settings that reflect how often content changes and how quickly stale content must disappear.
• Decide whether purging will be manual, event-driven, tag-based, path-based, or handled through versioned URLs.
• Inspect headers at the browser, CDN, and origin. A CDN cache miss may be caused by cookies, query strings, response headers, or a rule that bypasses caching.
• Use the CDN and Edge Caching Setup Guide when documenting cache rules and bypass patterns.

What to double-check

Cache headers: Check Cache-Control, Age, ETag, Last-Modified, and any provider-specific cache-status headers. A browser may cache an asset even when the CDN does not, and a CDN may cache a response even when the browser is told not to. Identify which layer served each response.

TTL settings: A longer TTL usually reduces repeated origin requests but increases the time stale content may remain available. Set TTLs according to content risk, not simply according to the largest value supported by a tool. Shorter TTLs can be appropriate during frequent publishing or inventory changes; versioned static assets can generally use a longer browser lifetime when deployments change their URLs.

Varying inputs: Cookies, authorization headers, device classes, languages, query parameters, and geographic or account information can produce different responses. If those inputs are ignored in a cache key, one visitor may receive another visitor's content. If they are included too broadly, the cache may fragment into many low-hit-rate variants.

Purge behavior: Test what happens after publishing an article, editing a menu, changing a product, or deploying code. Purging only the homepage may leave category or detail pages stale. Conversely, purging everything after every small change can create an avoidable origin load spike.

Origin performance: Caching can make a site feel fast for hits while misses remain slow. Measure time to first byte on cache hits and misses, database time, application time, and network time. If the origin is consistently slow, use the TTFB troubleshooting checklist to determine whether caching is the bottleneck or only masking it.

Common mistakes

• Adding multiple page caches without ownership: Decide which system controls HTML caching, purging, and bypass logic. Conflicting plugins, web-server rules, and CDN settings make failures difficult to diagnose.
• Caching personalized responses: A response containing account details, cart contents, or authorization-dependent data must not be treated like a public page.
• Assuming a cache hit without checking: A page can be fast because the origin is fast, because the browser has a copy, or because an edge cache served it. Inspect headers and test from more than one location.
• Using object cache as a universal fix: Redis or another object cache can reduce repeated data lookups, but it will not automatically fix oversized images, slow third-party scripts, poor DNS performance, or an uncacheable checkout flow.
• Purging too broadly or not at all: Document what changes trigger a purge and verify the result after deployments. The guide to busting cache safely during deployments can help turn this into a repeatable release step.
• Ignoring cache keys: Uncontrolled query parameters and cookies can cause repeated misses, while incomplete keys can serve the wrong variant. Keep only meaningful variations in the cache key.

When to revisit

Review the caching design before seasonal traffic changes, major campaigns, migrations, platform upgrades, or a change in publishing and deployment workflows. Revisit it when adding login features, personalization, subscriptions, international pricing, a new CDN, a cache plugin, or a different web hosting stack. Tool changes can alter default headers, purge APIs, cache keys, or exclusions even when the visible configuration appears unchanged.

Use this short operational review:

1. List every caching layer: browser, application, server, CDN, and any managed hosting layer.
2. Record the owner, cache key, TTL, bypass conditions, and purge method for each layer.
3. Test public, logged-in, cart, checkout, API, and recently changed pages.
4. Compare cache-hit and cache-miss response times, origin load, and error behavior.
5. Update deployment documentation and repeat the tests after configuration or workflow changes.

A sound website caching strategy is not the one with the most layers. It is the one whose layers have clear responsibilities, safe boundaries, observable behavior, and a dependable way to remove stale content. Keep this checklist with your deployment notes and revisit it whenever the application, hosting environment, or delivery path changes.