A higher cache hit ratio can mean less origin work. It can also hide the requests that matter most. A cached icon and a multi-gigabyte download each count as one request, so a single percentage is never a complete account of delivery performance.
Define the percentage before comparing it
Request hit ratio is cache hits divided by the requests in the measured population. Providers may report bypasses, revalidations, stale responses, and shield hits differently. Read those definitions before comparing dashboards or setting a target.
Segment by content class. Product images, personalized HTML, and public JSON have different reuse patterns. A dashboard that combines them can fall even when the cache policy is correct—for example, when logged-in traffic grows.
Follow the bytes as well as the requests
Consider 1,000 requests: 900 cached icons of 1 KB each and 100 uncached files of 1,000 KB each. Request hit ratio is 90%, but the icons represent less than 1% of the transferred payload bytes. This example assumes decimal KB and ignores protocol overhead.
Byte offload should be checked against actual origin egress. Shielding, revalidation, compression, and retries can make origin traffic differ from a simple edge hit/miss calculation.
A 90% request hit ratio can hide expensive misses
Look for keys that split identical content
A cache key determines which requests can share an object. If an analytics query parameter creates a new key on every visit, identical images may repeatedly miss. If the response varies by language or encoding, removing that distinction can serve the wrong representation.
Inventory the query parameters, headers, and cookies that influence the response. Remove a dimension only after proving that it cannot change the bytes or access decision. Keep signed URLs and authorization controls in the review.
| Pattern | Investigation |
|---|---|
| Unique tracking queries | Can this parameter be excluded without changing the response? |
| Frequent full purges | Can deployment use versioned assets and a narrower purge? |
| Short lifetimes everywhere | Which public objects tolerate a longer shared TTL? |
| Session cookies in every key | Should the request bypass instead of creating private variants? |
Improve reuse without changing correctness
Use content-hashed paths for immutable assets and keep them available during deploys. Assign explicit shared cache lifetimes to public responses. Invalidate mutable content narrowly, and observe the resulting origin fetches rather than assuming that a successful purge API call proves freshness.
Do not increase hit ratio by caching checkout, account pages, or responses that vary on credentials. Test with separate sessions and inspect both headers and bodies. A cache configuration is correct only when its access boundary is correct.
Build a dashboard that explains origin load
Track request hit ratio, byte hit ratio or origin egress, origin request rate, and latency by cache status. Break each down by path group and region where possible. Keep revalidations and errors visible.
Compare like-for-like periods, accounting for traffic mix and releases. A lower ratio during a new content launch may be expected; a sudden miss spike on unchanged versioned files deserves investigation.
