Performance
Edge cache
Edge cache is the copy of a page or file stored at an edge location close to visitors. A request answered there never travels back to your origin.
How it is measured
Check the response headers for a status like `cf-cache-status: HIT` or `x-cache: Hit from cloudfront`, and the `age` header to see how old the stored copy is. A time to first byte under 100 ms for HTML far from your origin usually means an edge hit.
Whether a response is stored depends on its cache headers, cookies, and the cache key. `s-maxage` controls shared caches without affecting the browser, which is why it is the usual way to cache HTML at the edge.
Worked example
A Ghost blog serves each article with `Cache-Control: public, s-maxage=300, stale-while-revalidate=60`. A reader in Frankfurt gets the page in 48 ms from the edge. At the 5 minute mark the first request after expiry takes 520 ms while the edge fetches a new copy, and the next ones are 50 ms again.
Purging a single URL after an edit takes effect in about 2 seconds, while purging the whole zone drops every page back to cold origin timings.
How it differs
An edge cache is storage at the edge. A CDN is the network of those locations plus routing, TLS, and often security. Cache hit ratio is the measure of how often the edge cache answers. The edge cache is the thing, the ratio tells you how well it is working.
Common errors
Caching a page that varies by cookie and serving one user's view to another. Setting a long TTL with no purge plan. Letting query strings multiply cache entries. Assuming one hit means every region is warm. Forgetting that each edge location has its own cold start.
In practice
Choose a short shared TTL for HTML plus stale-while-revalidate, and long TTLs for fingerprinted assets. Build a purge step into your deploy. Test one cached URL from two regions and check the cache status header.