WordPress Caching Explained: Page, Browser, Object, and CDN Layers

Caching makes WordPress faster by reusing work that has already been completed. The confusion begins when several systems use the word “cache” for different things. Knowing the layers makes configuration and troubleshooting much easier.

Page cache

A page cache stores the finished HTML for a request. Instead of running WordPress, querying the database, and rendering templates for every visitor, the server can return that saved response. This is especially effective for public pages that look the same to many users.

Personalized areas need exclusions. Carts, checkouts, accounts, previews, and pages controlled by session cookies should never receive another visitor’s cached HTML.

Browser cache

Browser caching tells a visitor’s device how long it may reuse static files such as images, fonts, CSS, and JavaScript. Long lifetimes reduce repeat downloads, while versioned filenames or query strings allow changed assets to refresh safely.

Object cache

An object cache stores results WordPress may need repeatedly, often database query results or computed objects. Persistent object caching can reduce database work across requests, but it is not a substitute for efficient queries. Confirm that the hosting platform supports the selected technology and monitor memory usage.

CDN and edge cache

A content delivery network serves assets—and sometimes full pages—from locations closer to visitors. Edge caching can reduce latency and origin load, but purge rules must stay coordinated with WordPress. Otherwise an updated page may remain stale at the edge after the local cache is cleared.

Common causes of stale content

  • Only one of several cache layers was purged.
  • A cache lifetime is longer than the publishing workflow expects.
  • Logged-in and logged-out visitors follow different rules.
  • A cookie or query parameter creates unexpected cache variations.
  • Minified assets were rebuilt but their version did not change.

Configure from the outside in

Document which system owns each layer: the host, a WordPress plugin, the browser policy, or the CDN. Avoid enabling two plugins that both perform page caching or asset combination. After any change, test a cold anonymous request, a repeat visit, a logged-in session, and a personalized journey.

Good caching is deliberately boring. Visitors receive fresh content, private pages remain private, and the team knows exactly which layer to clear when a change does not appear.

Scroll to Top