A CDN dashboard reports a 55% cache hit ratio for a site's static assets. What does that number actually mean, and what are the usual reasons an edge cache misses on files that never change?

## What the number is Cache hit ratio is `hits / (hits + misses)` over a time window, at whatever scope the dashboard is aggregating — usually the whole property, sometimes per PoP. A hit means the edge server answered from its own stored copy without contacting your origin. A miss means it had to fetch. Two variants matter and they diverge: - **Request hit ratio** — the share of *requests* served from cache. - **Byte hit ratio** — the share of *bytes* served from cache. A site can serve 95% of requests from the edge and still push half its bytes from origin, because the misses are the big video and image objects. If you are optimising origin egress cost or origin bandwidth, byte hit ratio is the honest number; if you are optimising user-perceived latency, request hit ratio is closer to what users feel. A hit ratio also has a floor you cannot beat. Every distinct object must be fetched at least once per PoP, so a site with a huge catalogue of rarely-requested objects and a global footprint will never approach 100%, no matter how well it is configured. ## Why a file that never changes still misses **1. Cache-key fragmentation from the URL.** The cache key is built from the request URL, so `/app.8f3a1c.js` and `/app.8f3a1c.js?utm_source=newsletter` are two separate objects holding identical bytes. Campaign parameters, session identifiers spliced into links, cache-busting parameters added by well-meaning code, and third-party tracking suffixes all multiply one object into hundreds — each of which has to be fetched from origin the first time it is seen at each PoP. The fix is to normalise the key: strip or allow-list query parameters at the edge for asset paths, and sort the ones you keep, so equivalent requests collapse onto one object. **2. A lifetime shorter than the request interval.** If an object is cached for five minutes but a given PoP sees a request for it every eight minutes, the copy is expired on every arrival and every request is a miss. For genuinely immutable, content-hashed assets the answer is a long lifetime — the URL changes when the content does, so there is no reason to expire it early. **3. Independent caches at each PoP.** Edges do not share one global cache. Splitting worldwide traffic over dozens of PoPs means each one sees a fraction of the volume, and a moderately popular object may be requested too rarely at any single PoP to stay resident. Most CDNs offer a shield or upper-tier cache — a designated intermediate cache all PoPs miss into — which converts many origin fetches into one and lifts the effective hit ratio for exactly this long tail. **4. Eviction.** Edge storage is finite and managed roughly least-recently-used. A large catalogue competing with popular objects means older entries are evicted before their lifetime expires, so "cached for a year" is an upper bound, never a promise. **5. Responses the CDN will not store.** `Cache-Control: no-store` or `private` on an asset response, or a `Set-Cookie` attached to static files because the whole site shares one hostname and a framework sets a session cookie on every response, will stop most CDNs from caching. This is the one that most often surprises people, because the file looks perfectly static. **6. Deploys.** Every new content-hashed filename is, by definition, cold everywhere. A dip in hit ratio right after each release is expected and is not a defect. ## Diagnosing it rather than guessing Sample real URLs from logs and look at how many distinct keys map to what should be one object. Compare the same asset requested with and without a query string: ```bash curl -sI 'https://example.com/app.8f3a1c.js' curl -sI 'https://example.com/app.8f3a1c.js?utm_source=news' ``` Most CDNs report cache status in a response header (the name is a per-provider convention), and the standard `Age` header on a response tells you the copy was served from a cache rather than freshly fetched. Then break the ratio down by path prefix and by PoP: a low ratio concentrated on one path is usually a headers or key problem, while a low ratio spread evenly across small PoPs is usually traffic dilution, and the fixes are different. ## The judgment part A higher hit ratio is not automatically the goal. Raising it by caching things that should not be cached is a correctness bug, and the last few percent of a long tail may cost more engineering than the origin traffic it saves. What a strong answer shows is that you know what the number measures, which of the causes above your data points at, and which fix follows from that cause.