What It Actually Means
It is usually the single highest-return performance improvement available, because most systems spend most of their time repeatedly producing identical results.
Where It Happens
Several layers, and knowing they exist explains a lot of confusing behaviour.
In the browser. Images, stylesheets and scripts held locally so a returning visitor does not download them again.
At a CDN. Copies held on servers around the world, close to visitors.
At the web server. Whole pages stored ready-made, so the application does not run at all for most requests. On a content site this is transformative.
In the application. Expensive calculations and query results kept in memory for a period.
In the database. Its own internal caching of frequent queries.
A request can be answered at any of these, and a change to your site has to work its way through all of them before everyone sees it.
The One Real Danger
Stale content. Somebody updates a price, a phone number or an opening time, and visitors keep seeing the old one because a cached copy is still being served.
That is the failure mode worth understanding, because it produces a specific and very common experience: the change looks correct to the person who made it, because their browser or session bypasses the cache, and wrong to everyone else. Hours can be spent debugging something that was never broken.
Two rules avoid most of it. Clear the cache after publishing changes, ideally automatically. And check in a private browsing window, which is the quickest way to see what an ordinary visitor sees.
What Should Not Be Cached
Anything personal or session-specific. A logged-in view, a basket, a price that varies by customer.
The serious version of this failure is a cached page containing one user’s information being served to another. It happens when whole-page caching is applied to pages that should have been excluded, and it is a data breach rather than a bug. Any caching setup on a site with logged-in users needs its exclusions checked deliberately.
What To Ask
- What is cached, and for how long? There should be an answer per layer.
- Is the cache cleared automatically when content is published? If it is manual, it will be forgotten.
- Are logged-in pages excluded? The important one.
- How do we check what a visitor actually sees? Private window, and ideally from another network.
- Is there a way to bypass it for testing? Usually a query string, and it should be known rather than discovered.
Where It Fits
For a content-heavy site, page caching is frequently the difference between a site that feels slow and one that feels immediate, and it costs almost nothing.
For an application, the useful targets are the specific expensive operations rather than everything: a report that takes seconds to assemble, a query run on every page load, a call to a slow third party. Measuring first and caching what is actually slow is considerably more effective than caching broadly and hoping, and it avoids introducing staleness where there was no performance problem to solve.
More terms are in the glossary.
