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!