Caching means storing a copy of something that was expensive to generate so it can be reused instead of recreated from scratch. On the web, this happens at three distinct layers, and each one solves a slightly different problem. Understanding all three makes it much easier to figure out why a page is still slow even after you think you have “turned caching on.”
Browser caching
When your browser downloads a file, such as a stylesheet or image, it can store a local copy so the next visit does not require downloading it again. Whether and for how long this happens is governed by HTTP response headers, most importantly Cache-Control, which tells the browser how long a resource can be reused before it needs to be re-fetched. This behavior is formally defined in RFC 9111, the IETF’s HTTP Caching specification, which sets out exactly how directives like max-age and no-cache should be interpreted by browsers and intermediate caches. A misconfigured or missing Cache-Control header is one of the most common reasons repeat visitors do not get any speed benefit at all.
Server-side caching
On the server, caching happens at multiple levels. Object caching stores the results of expensive database queries or computed values in fast memory, so a dynamic page does not have to rebuild the same data on every request. Full-page caching goes further, storing an entire rendered HTML page and serving it directly for subsequent visitors, bypassing the application and database layer almost entirely for pages that do not change per visitor. Full-page caching delivers the biggest performance gains but needs careful configuration for logged-in users or personalized content, which generally cannot be served from a shared cache.
CDN edge caching
A content delivery network extends caching beyond your own server by storing copies of your content on servers, called edge nodes, distributed around the world, physically closer to your visitors. When someone requests your site, the CDN can serve a cached copy from the nearest edge location instead of routing the request all the way back to your origin server, cutting both network latency and load on your infrastructure. This differs from origin server caching in a fundamental way: the origin server is still the single source of truth and handles anything the edge cannot serve from cache, while edge nodes exist purely to reduce distance and repeated origin requests.
How the layers work together
A well-configured site uses all three layers in sequence. A CDN edge node checks whether it already has a fresh copy of the requested resource; if not, it asks the origin server, which may itself serve the response from an object or full-page cache rather than rebuilding it from the database; the response then travels back through the CDN to the visitor’s browser, which stores its own copy according to the Cache-Control headers attached to it. Each layer that successfully serves a cached response removes work from every layer behind it.
When diagnosing a slow site, check each layer independently: are your Cache-Control headers actually set and reasonable, is server-side object or page caching enabled, and is a CDN actually caching your static assets rather than passing every request straight through. Fixing one layer while leaving another misconfigured often produces disappointing results, since the slowest layer in the chain determines a large part of the experience.
Common caching pitfalls
A frequent problem is caching a page that should never be cached, such as a shopping cart or a personalized dashboard, which can result in one visitor seeing another visitor’s cached content, a serious and embarrassing failure mode. Another common issue is a cache that never invalidates properly after content changes, leaving visitors seeing outdated information long after you have published an update. Whenever you enable or adjust any caching layer, test by making a visible content change and confirming, from a fresh browser session, that the update actually appears within the expected cache lifetime, rather than assuming the configuration is correct. For more detail, see the IETF (RFC 7336), which covers the framework for how interconnected content delivery networks and edge nodes distribute cached content.
