A page becomes reassuring after it is cached. The recorded review deliberately reproduced uncached search terms and routes instead.
Later observation found a detail route at 96 ms, a PDF path at 13 ms and a deep search at 11 ms. After changes, the recorded values were 8, 4 and 3 ms. Rechecking only familiar warm pages would have missed those paths.
I start with a first-time visitor
Repeatedly loading a familiar page is not enough for me to call the site fast. A first-time visitor may reach a cold path. I design that visit before celebrating my own warm one.
A cache miss is not automatically a failed page
Some R2 lookups returned 404 for a missing cached screen, followed by a valid lightweight response. Storage misses and user-visible failures were therefore kept separate.
Follow the entire chain: cache lookup, origin query, transformation, response and the next request. A cold visitor still needs the intended content and status.
A reproducible test matrix
- Separate previously visited addresses from unfamiliar inputs.
- Identify the real cache key. An arbitrary query parameter does not establish a bypass.
- Record input, hit/miss state, CPU, elapsed time, status and content version.
- Test uncached list, detail, search and HEAD paths separately.
- Use an isolated test keyspace where necessary rather than clearing all production caches.
Design what the first visitor receives
The Cache API documentation describes data-center-local behavior. Warming a key in one location does not prove a hit everywhere. Observe CPU separately from network waiting.
Include language and version
Check that an English request cannot receive a Korean body or stale deployed content. Record language, content version and the actual key along with the URL.
The operational principle I keep is simple: explain the cold first visit before celebrating the warm second one.