A common confusion: you finish a website, refresh it repeatedly, and it is instant every time. Two days later you open it and it takes a moment. You suspect the server, or the network, but testing produces nothing conclusive.
Here is the thing taken apart, using our own site. Every number below is measured.
Two numbers first
The same page, requested from Auckland:
Cache hit: 45 milliseconds. You do not perceive a wait — the click and the page arrive together.
Cache miss: 210 to 520 milliseconds. Somewhere in that range you notice a pause.
A tenfold difference on the same page, the same server and the same connection. The only variable is whether that request found something in the cache.
Where the cache is, and why it empties
That middle layer is usually a CDN — Cloudflare, for instance. It has locations worldwide, and the one nearest New Zealand is in Auckland. When the first visitor arrives, that location has no copy, so it fetches one from your origin server, stores it, and serves it. Later visitors get the stored copy without the round trip.
The trouble is in “stores it”.
Many people assume a longer cache time settles this — set it to a year and it stays a year. That reading is wrong in a way that matters.
Cache duration is a ceiling, not a promise. A CDN location has storage shared by many thousands of sites, and it evicts by how often things are requested. On a site without much traffic, a copy will be pushed out within hours to make room for busier content, whatever number you configured.
Which produces exactly the symptom: fast while you keep refreshing because the copy is still there, slow the next day because it has been evicted and the request has to travel all the way back to the origin.
The pattern is unkind — the less traffic a site has, the more often a visitor lands on the slow request, and low-traffic sites are usually the ones where each visitor matters most.
Where those 210 to 520 milliseconds go
Broken down: from Auckland to our origin server in Sydney — open a connection, complete the TLS handshake, send the request, wait, receive — is about 110 milliseconds. That is physical distance and it is not negotiable.
Measured, the CDN’s fetch to the origin is slower still and varies a lot, because it establishes a fresh encrypted connection each time rather than reusing an open one.
If the origin also has to run database queries and assemble the page, add tens to a couple of hundred milliseconds. Plenty of sites lose their time here. But note: however far you optimise the server, the physical round trip remains as long as anything still has to go and fetch.
Three common responses, and what is wrong with each
Increase the cache duration. Does nothing, for the reason above. This is the most common mistake, and people often believe it worked because they happened to test while the cache was still warm.
Request your own site on a schedule to keep the cache warm. Right instinct, hard to do correctly. A CDN caches per location, so requests sent from your server only warm the location nearest the server. Visitors in Auckland still miss.
Buy a better server. Improves the processing part, changes neither the physical round trip nor the eviction. Most expensive, least effective.
The actual fix is to take the origin out of the path
If a page’s content does not change between releases — true of most business website pages — then it does not need fetching from an origin at all.
Generate the pages ahead of time and deploy them into the CDN’s network alongside the code. Their status changes: they are no longer a cache, they are a deployment artefact. Caches get evicted; deployment artefacts do not. They sit there until the next release.
Measured on this site after the change: every page steady between 40 and 60 milliseconds, dozens of consecutive requests with none above 100. Before, it was 45ms on a hit and 520ms on a miss. Now there is no miss state.
The dynamic parts — admin, form submissions, the AI chat endpoint — still go to the origin. They should never have been cached, and there are few of them.
There is a cost, and it should be stated
This approach introduces its own problem: each release redistributes the files, so the first visitor to each location pays again — around 340 milliseconds, measured. The slowness moves from “when the cache expires” to “just after we publish”.
The answer is to absorb it in the release process: after publishing, request every page a few times from your own end so the locations fill before visitors arrive.
One detail is easy to miss. A CDN location contains many servers and requests spread across them, each filling separately. Two passes left four of our pages still slow; six passes brought it to zero.
Measuring your own
No tools required. Request your home page with curl and look at time_starttransfer — the time from sending the request to receiving the first byte. Take five readings, then five more a day later. If they differ several times over, eviction is what you are seeing, not a server problem.
Look at the cf-cache-status response header while you are there. HIT means it was served from the cache; MISS means that request went back to the origin. The slow ones will almost all be misses.
Decide what to do once you know which it is. The sites we deliver use the structure described above by default, not as an upgrade.