Website Caching Layers Explained: The Layers Preventing Your Updates from Appearing
Making a change to your website and watching it go live can be one of the most satisfying parts of managing a site. But the frustration comes when you clear your browser cache, only to find that loading the page in “incognito” mode or from a different device shows the old version—the one you just updated. Annoying, right?
There’s a good reason for this: your website files aren’t stored in just one place. They’re duplicated across multiple caches—one on your visitor’s device, one at the CDN’s edge, one in your server’s storage, and (in the case of WordPress) one inside your site’s code. And they’re all perfectly designed. except when they get out of sync and show versions that don’t match.
This can sound confusing, and it is. Here’s a simple guide to understanding the way different types of caching work, and what each cached copy of your site is responsible for.
First layer: browser cache on your visitor’s device
The browser cache is the layer you’re most familiar with, even if you’ve never heard it called that. It’s the reason your favorite websites load so fast after the first visit—and why sometimes your own updates are invisible to you.
Cloudflare describes caching as storing copies of files so they can be reused in the future. In the case of your browser, Chrome, Firefox, Safari, or any other will use standards like HTTP response headers like Cache-Control, Expires, and ETag to store a copy of key elements of your site—usually things like the CSS, JavaScript, images, and fonts(stackharbor.com/en/knowledge-base/wp-cache-layers-page-object-browser, published 2025-06-13).
Once they’re downloaded once,(arcadiaservers.com/blog/wordpress-caching-explained-page-cache-object-cache-and-browser-cache, published 2026-06-10) points out, they’re loaded from the local browser cache—subsequent visits skip right over that network request, treating your visitor’s device itself as another node in your content delivery network.
Middle layers: page caches and CDN-style edge caches
In addition to the individual copies on each visitor’s device, your browser, CDN, hosting stack, or WordPress plugins may also create copies of your site. But these copies generally focus on much “coarser” elements than static images and fonts.
You might know this as the “server cache.” [ calls it a page cache,(stackharbor.com/en/knowledge-base/wp-cache-layers-page-object-browser, published 2025-06-13) includes CDNs, and Stackharbor looks at a comparison of Nginx, Varnish, and a WordPress stack with WP Super Cache.
The idea with this kind of cache is simple: serve users a completed version of a page, if it already exists. This gives speed, especially for users accessing your site who aren’t logged in, whose preferences you don’t need to know, and whose content doesn’t change from, say, one login session to the next.
If you’re familiar with the idea of only accessing the database when you need to, page caches are a natural extension of that.(g7cloud.com/knowledge-base/performance-speed/wordpress-object-caching-redis-memcached-guide, published 2025-12-21) shows how if a valid page cache exists, the web server can return it with almost no PHP or DB work. On its own, page caching works in interesting ways with dynamic content:.
Deep inside: object cache and how it speeds database-driven pages
Page cache interacts with static content, and doesn’t really work for logged-in content.(elementor.com/blog/what-is-object-cache-and-how-to-enable-it, published 2025-11-19) explains that this is where object caching enters: this layer is focused on accelerating how pages are built, not about saving them themselves.
Object cache stores results of individual database queries… as opposed to the HTML that would be produced after all of a page’s dynamic elements come together. So as a concrete example,(arcadiaservers.com/blog/wordpress-caching-explained-page-cache-object-cache-and-browser-cache, published 2026-06-10) explains, you can take advantage of object caching without impacting logged-in users.(whitelabelcoders.com/blog/what-is-the-difference-between-object-caching-and-page-caching-in-wordpress, published 2026-06-24) shows how object caching interacts with data stores like Redis or Memcached to cache results at the PHP level, which speeds up WordPress’s own page generation even if each visitor is seeing a (potentially) unique version of that page.
This shows the importance of a balanced ecosystem: most content delivery networks (CDNs), product hosting systems, or larger-scale WordPress hosting properties will focus on a mix of all three caching layers to get the best balance of speed, security, and reliability.
Building a mental model
Once you have the three layers in mind, you can start to build those instincts that experts use to quickly identify where the cache is hiding that spun-up local copy.(elementor.com/blog/what-is-object-cache-and-how-to-enable-it, published 2025-11-19) lists them in order:
- browser cache: stores webfiles (CSS, JS, images, fonts) locally on your device for faster repeat visits
- page cache: stores full HTML responses keyed by URL, skipping PHP
- object cache: handles individual calls within the WordPress runtime, usually via Redis or Memcached
This has parallel effects: as(elementor.com/blog/what-is-object-cache-and-how-to-enable-it, published 2025-11-19) and(airlift.net/page-cache-vs-object-cache, published 2026-07-14) explain, then, a browser’s cache holds static assets you can imagine are downloaded once; page caches hold one static representation of a web page; and object caches keep smaller pieces of information that WordPress needs on hand for generating larger pages, or for handling more complicated and dynamic aspects.
You can imagine these as different steps of a workflow: all the individual page elements are collected and served (by the browser cache, first), then each request might itself be stored (in the page cache) to avoid having to do the generation work over and over, and finally even the data parts of keeping your site running smoothly are kept in fast-access storage via the object cache.
These have different lifecycle guarantees: page cache is restricted to users who are logged out, forbidden to store pages that include logged-in state, and object caches make no attempt to store full pages or assets themselves, just the pieces of the data a WordPress page would need.
And there you have it: now that you can see how the different caches are operating, you have a concrete mental model for what they’re each trying to achieve, and what you need to do to flush each of the caches that might be storing a version of your site.