Caching Layers Explained: Browser, Page, and Server

Caching is mentioned in almost every performance guide, but the term covers multiple distinct systems
working at different levels. Understanding the browser cache, page cache, and server-side caches
helps you configure each appropriately and diagnose problems when content is not updating. This
guide explains each caching layer, how they interact, and optimal configuration for WordPress
publisher sites.

I. Browser Caching

Browser caching stores downloaded resources on the visitor’s device. Subsequent page loads use local
copies instead of downloading again.

A. What Gets Cached

• Static assets: CSS stylesheets, JavaScript files, images, fonts, and other files that
  rarely change.
• HTML pages: Can be cached but usually have shorter cache times due to content updates.
• API responses: REST API responses can include caching headers for appropriate caching.

B. Cache Control Headers

• Cache-Control: Primary header controlling cache behavior. Directives like
  max-age=31536000 specify how long to cache.
• Expires: Legacy header specifying absolute expiration date. Cache-Control takes
  precedence when both present.
• ETag: Unique identifier for a specific version of a resource. Allows conditional requests
  to verify cached version is still valid.
• Last-Modified: Timestamp when resource last changed. Used for conditional requests
  similar to ETag.

C. Optimal Cache Durations

• CSS and JavaScript: Use long cache times (1 year) with fingerprinted filenames. File
  changes create new URL, bypassing cache.
• Images: Long cache times (1 year) for static images. Content images rarely change once
  published.
• HTML pages: Short or no caching for dynamic content. Visitors should see current content.
• Fonts: Very long cache times (1 year). Font files never change once published.

II. Page Caching

Page caching stores complete HTML output for pages. When a cached page exists, WordPress does not
need to run at all—the cached HTML is served directly.

A. How Page Caching Works

• First request: WordPress generates the page normally. After output is complete, the
  caching system stores the HTML.
• Subsequent requests: Before WordPress loads, the caching system checks for a cached
  version. If found, it is served immediately.
• Cache bypass: Logged-in users, requests with certain cookies, or specific query strings
  may bypass cache.

B. Plugin vs Server-Level Caching

• Plugin caching (WP Super Cache, W3 Total Cache): Works on any hosting. PHP must still
  load minimally to check cache status.
• Server-level caching (Nginx FastCGI, LiteSpeed): Cache is checked before PHP loads at
  all. Typically faster than plugin solutions.
• Recommendation: Use server-level caching when available. Fall back to plugin caching on
  shared hosting.

C. Cache Invalidation

• Time-based expiration: Cache expires after configured time (e.g., 12 hours). Simple but
  may serve stale content after updates.
• Event-based purging: Cache purges when content changes. Post updates, comment additions,
  or setting changes trigger purge.
• Manual purging: Clear cache manually after significant changes. Most caching plugins
  provide admin interface for this.

III. Object Caching

Object caching stores database query results and computed values in memory. This speeds up WordPress
processing when page caching does not apply.

A. WordPress Object Cache

• Default behavior: WordPress has a built-in object cache that only lasts for the current
  request. Not persistent.
• Persistent object cache: Redis or Memcached stores object cache between requests. Speeds
  up logged-in users and admin.
• What gets cached: Options, post data, user information, taxonomy relationships, and
  plugin-stored transients.

B. When Object Cache Helps

• Logged-in users: Page cache typically excludes logged-in users. Object cache helps these
  requests.
• Admin dashboard: Dashboard pages are not page-cached but benefit from object cache.
• Complex sites: Sites with many plugins making database queries see larger benefit.

IV. CDN Caching

Content Delivery Networks cache content at edge servers distributed globally, reducing latency for
geographically distant visitors.

A. What CDNs Cache

• Static assets: All CDNs cache CSS, JavaScript, images, and other static files.
• HTML pages: Some CDNs offer full page caching at the edge (Cloudflare APO, Fastly).
• API responses: CDNs can cache API responses based on headers and configuration.

B. CDN Configuration

• Cache headers: CDNs respect origin server Cache-Control headers. Ensure proper headers
  are set.
• TTL overrides: CDN settings can override origin headers. Use for additional control.
• Purging: Most CDNs provide API and dashboard for cache purging. Integrate with WordPress
  for automatic purge on updates.

V. How Caching Layers Interact

Multiple caching layers can work together or conflict. Understanding the interaction helps optimize
configuration.

A. Request Flow Through Cache Layers

• Step 1: Browser checks its local cache. If valid cached version exists, no network
  request is made.
• Step 2: If browser cache misses, request goes to CDN edge server.
• Step 3: CDN checks its cache. If hit, serves without contacting origin server.
• Step 4: If CDN cache misses, request goes to origin server’s page cache.
• Step 5: If page cache misses, WordPress generates page using object cache to speed
  database access.

B. Common Configuration Problems

• Cache not purging: Content updated but visitors see old version. Check all cache layers
  for stale content.
• Too long browser cache: Visitors cannot see updates because browser serves old cached
  files.
• Conflicting TTLs: Different cache layers with conflicting durations cause unpredictable
  behavior.
• Over-caching: Caching pages that should be dynamic (logged-in user pages, cart pages).

VI. Recommended Configuration

A. Static Assets

• Browser cache: 1 year max-age with immutable flag for fingerprinted URLs.
• CDN cache: Match or exceed browser cache TTL.
• Versioning: Use query strings or filename hashing so new versions get new URLs.

B. HTML Pages

• Browser cache: Short or no caching (max 5 minutes) for dynamic content. Ensures visitors
  see updates.
• Page cache: 12-24 hours for article pages. Purge on update.
• CDN cache: If full page caching at edge, match page cache TTL with proper purge
  integration.

C. Cache Exclusions

• Logged-in users: Exclude from page cache. Use object cache to speed up.
• Admin pages: Never page cache WordPress admin.
• Forms and dynamic features: Contact forms, search results, and similar features may need
  cache bypass.
• Preview pages: Content previews should bypass cache to show latest draft.

VII. Troubleshooting Cache Issues

• Content not updating: Clear page cache, CDN cache, and browser cache in order. Test in
  incognito mode.
• Checking cache status: View response headers for Cache-Control, X-Cache, and other cache
  indicators.
• Inconsistent behavior: Different results for different users often indicates cookie-based
  cache bypass or geographic CDN edge differences.
• Performance still slow: Verify caching is actually working. Check for cache bypass
  triggers like query strings or cookies.

VIII. Conclusion

Effective caching requires understanding and configuring multiple layers. Browser caching eliminates
network requests for returning visitors. Page caching eliminates WordPress processing for anonymous
visitors. Object caching speeds up WordPress when it must run. CDN caching reduces latency for
geographically distant visitors. Each layer serves a distinct purpose, and together they can reduce
server load dramatically while improving user experience. The key is proper configuration at each
layer with coordinated cache invalidation when content changes.

Which caching layer was most confusing to set up? Share your experience in the
comments!