Caching
Debug a cached response
Inspect freshness, validators, age, and transferred size to explain whether a response came from a browser cache, CDN, or origin.
Caching bugs are hard to spot from server logs alone. The browser or a CDN may serve a response your origin never saw. The Network panel is where I start when something looks stale or too fast to be real.
Open DevTools, go to Network, and reload a page twice. Select the same static resource after each load, like a CSS or image file.
Look for these clues:
Cache-Controland its freshness lifetimeETagorLast-ModifiedAge, which may reveal time spent in a shared cache- a
304status after conditional validation (memory cache)or(disk cache)in the size column
On the first load, the size column shows the actual byte count, such as 42.1 kB. On the second load, Chrome often shows (disk cache) and 0 B transferred. That means the browser never asked the network for the body.
Developer tools include a Disable cache checkbox. It works while the tools stay open and is useful for comparing cached and uncached behavior side by side. Turn it on, reload, and watch the same resource fetch from the network every time.
Be careful when testing. A hard reload (Cmd+Shift+R on Mac), a normal reload, disabled cache, and a private window can all produce different results. Write down exactly which one you used before you tell someone “caching is broken.”
If you suspect a CDN, look at Age and response headers your CDN adds (often cf-cache-status, x-cache, or similar). An Age of 300 means the response sat in a shared cache for five minutes before it reached you.
Try this on your own site: reload twice, pick one cached asset, and explain out loud where it came from on the second load. Browser cache, CDN, or origin? The headers and size column give you the answer.
Quick check
Result
You got of right.
Lesson completed