Honestly: nobody thinks about caches for fun. Not until the site is slow, someone in the meeting says “just turn on the cache” and the next question is already in the room: which one?
Because there are three. They sit behind one another, and every further one costs time. A cache is always the same thing: a finished copy, so the same work does not have to be done twice. The only interesting part is where that copy sits and how far it is from your visitor.
A visitor opens your page
not there, so keep going
not there, so keep going
not there, so keep going
The three layers, in plain language
The browser cache: the copy at the visitor
The fastest cache is the one where no request leaves at all. The browser still has the file on the device and takes it from there. No network, no waiting.
The catch is obvious: on a first visit this cache is empty. For every new visitor, which means everyone your campaign is bringing in right now, it does not exist. The browser cache rewards regulars. It never sees new customers.
The CDN cache: the copy nearby
A CDN is a network of servers in many countries that serves your site from whichever location is closest to the visitor. What you save is not only work, it is distance: a visitor in Sydney gets their answer from Sydney instead of Frankfurt.
The big lever is caching the page itself, not just images and scripts. Everybody does it for images, almost nobody does it for the page. And that is exactly where the waiting sits that your visitor spends in front of a blank screen.
The origin cache: the finished page on your server
If the request does reach you, the third layer decides how expensive it gets. The origin cache keeps the fully built page ready instead of assembling it every single time.
This is where the gap is widest. With a copy: send it out. Without one: query the database, calculate prices, render templates, check availability. Hence the jump from 150 to 600 milliseconds in the diagram.
To a visitor, by the way, these three layers are indistinguishable. All they notice is whether the page is there instantly or not.
HIT and MISS: the two words that matter
Caches always describe their outcome with the same words. Two of them are enough to start:
- HIT: the copy was there and went straight out. The good case.
- MISS: the copy was not there, so the request had to go one layer deeper.
As soon as you look at a dashboard or a server log, a few in-between states show up. You do not have to memorise them, you just need to place them: EXPIRED means the copy was too old and got refreshed. STALE means an old copy went out on purpose to save time. REVALIDATED means the copy was checked and was still valid. BYPASS, PASS, DYNAMIC and NONE all mean the same thing in variations: for this request, the cache was not involved.
One point matters here because it usually gets lost: these words apply per layer. A HIT at the CDN and a MISS in the origin cache are two separate statements. Only together do they tell you who actually answered.
Why this is not just a technical detail
The time to the first byte, called TTFB in reports, is the floor everything else stands on. While it runs, your visitor sees nothing. No image, no headline, no button. The browser cannot show what it has not received yet.
Two consequences that reach beyond engineering:
Google grades what real visitors experience. Rankings use Core Web Vitals from real Chrome visits, not the test run on your agency’s laptop. Which cache layer answered is therefore a ranking factor, even though it never appears on an invoice.
Waiting costs you exactly where you can least afford it. You send paid traffic to landing pages. Those visitors arrive for the first time, so they have no browser cache, and they often land on URLs carrying campaign parameters. If a copy is missing anywhere, that exact visit pays the waiting time.
And here is the trap modern hosting platforms set. Responses from the edge cache look fantastic, while a miss next to them can be ten times slower. In an average that difference disappears completely. Which is why the hit rate is the number that counts, not the mean.
So a cache is not a switch you flip once. It is a rate, and rates move.
What breaks a cache in daily life
Three things explain most poor hit rates, and none of them usually comes from the engineering corner:
- Campaign parameters. If every link carries a
?utm_source=..., many caches treat that as a different address and therefore a separate copy. In the worst case every campaign click gets a MISS. Well-configured caches ignore known tracking parameters when they look up a copy. But somebody has to tell them to. - Cookies. If a response sets or reads a cookie, many caches treat it as personal and do not cache it at all. A newly added tool, a consent banner, an A/B test: things like these can halve a good hit rate overnight without anyone touching “performance”.
- Every release. After a deploy the cache starts out empty. The first visitors afterwards pay for rebuilding it. At ten deploys a week that is not an edge case, it is Tuesday.
None of the three is visible in an average. They are visible when you know the hit rate per layer and when it dropped.
What you can tell your developers
Your servers know every one of these answers. They just tell nobody until someone asks them to. There is a standard header for it, and the browser hands it over on every visit:
Server-Timing: cdn-cache;desc="HIT", fm-fpc;desc="MISS", db;dur=48
Translated: the CDN had the copy, the origin cache did not, and the database took 48 milliseconds. Four lines in the server config are enough.
fastmon reads both layers separately, from every real visit, and puts the hit rate right next to load time. Pageviews without a value show up as “Unknown”, and that is a statement too: nobody currently knows what happens there.
Note: Which header names fastmon recognises and what each status means is in our Server-Timing docs. That link is exactly what your developers need.
What to take away
Three layers, one order, one question: who answered? The browser cache only helps people coming back. The CDN decides the distance, provided you cache the page itself too. The origin cache decides how expensive a miss becomes.
And the hit rate is not a setting you tick off. It is a number you keep an eye on. Real user monitoring shows it to you from every real visit instead of estimating it in a lab.