Cache hit ratio is the percentage of requests that a cache answers from its stored copies rather than forwarding them to the origin server. In content delivery, it is the primary measure of how well a CDN, edge cache or reverse proxy offloads the origin and shortens response times for users.
The basic formula is simple: hits divided by the sum of hits and misses, multiplied by 100. A ratio of 95 percent means that only 5 of every 100 requests travel to the origin. Behind that single number, however, lie important choices about what counts as a request, which responses are cacheable and how the cache key is built.
How the cache hit ratio is calculated
When a request reaches an edge server, the cache looks up a stored object by its cache key, usually built from the host, path and selected query parameters. If a fresh copy exists, the response is a hit. If no copy exists, or the copy has expired and must be fetched again, the response is a miss and the edge contacts the origin or an upstream cache tier.
CDNs report more detailed cache statuses than a simple hit or miss. How these statuses are grouped changes the reported ratio considerably, so the definition used by a provider should always be checked.
| Status | Meaning | Usually counted as |
|---|---|---|
| HIT | Fresh copy served from the cache | Hit |
| MISS | No copy in cache, fetched from upstream | Miss |
| EXPIRED | Copy existed but its lifetime had ended | Miss |
| REVALIDATED | Origin confirmed the copy is still valid | Hit in some reports, miss in others |
| STALE | Expired copy served while refreshing or on error | Hit |
| BYPASS or DYNAMIC | Response marked uncacheable | Often excluded from the ratio |
Excluding uncacheable traffic produces a flattering ratio that describes only cacheable content, while including it shows the true offload of the origin. Both views are useful, but they must not be compared with each other.
Request hit ratio and byte hit ratio
There are two common ways to measure success. The request hit ratio counts requests, while the byte hit ratio counts transferred data. A site can show a high request ratio thanks to many small icons while large video segments still come mostly from the origin.
| Metric | Formula | Best indicator of |
|---|---|---|
| Request hit ratio | Hit requests divided by all counted requests | Origin request load and latency |
| Byte hit ratio | Bytes served from cache divided by all bytes | Origin bandwidth and egress cost |
| Origin offload | Share of traffic that never reaches origin | Overall protection of the origin |
For cost control, the byte hit ratio usually matters more, because cloud providers bill origin egress by volume. For origin capacity and latency, the request hit ratio is the more relevant figure.
Factors that raise or lower the ratio
A cache hit ratio is the result of cache policy, traffic patterns and network topology together. The same configuration can produce very different numbers for a news site with a few viral pages and an online catalog with millions of rarely viewed products.
| Factor | Effect when unfavorable | Typical improvement |
|---|---|---|
| Cache lifetime (TTL) | Short max-age causes frequent refetches | Longer TTLs with versioned file names |
| Cache key design | Query strings and cookies fragment the cache | Ignore irrelevant parameters, normalize keys |
| Vary header | Many variants per URL | Limit variation to headers that truly matter |
| Long-tail content | Rare objects are evicted before reuse | Larger caches or tiered caching |
| Number of edge locations | Each location warms its own cache | Origin shield to consolidate misses |
| Frequent purges | Content repeatedly removed from cache | Targeted purges by tag or URL |
Tiered caching and an origin shield are especially effective on global networks. Instead of hundreds of points of presence each fetching from the origin, misses are funneled through one or a few parent caches, so the origin sees one request where it previously saw many.
Directives such as stale-while-revalidate also lift the effective ratio, because an expired object can still be served immediately while a background request refreshes it.
What counts as a good cache hit ratio
There is no universal target, because achievable values depend on the content type. Versioned static assets can reach very high ratios, while personalized or frequently changing content cannot. The ranges below are typical orientation values, not guarantees.
| Content type | Typical request hit ratio | Limiting factor |
|---|---|---|
| Versioned static assets | Often above 95 percent | Cold caches at rarely used locations |
| Images and media libraries | Roughly 80 to 95 percent | Long tail of rarely viewed files |
| Video streaming segments | High for popular titles, lower for catalog | Size of library and popularity spread |
| Public HTML pages | Wide range, often 40 to 90 percent | Short TTLs and purges on updates |
| Personalized pages and APIs | Low or near zero | Responses differ per user |
Pitfalls when interpreting the metric
A rising ratio is not automatically good news. If caching rules accidentally store personalized responses, the ratio improves while users receive other people’s data, which is a serious security failure rather than an optimization.
- Segment the metric by content type, path or hostname, because a single global figure hides problem areas.
- Watch the ratio after deployments, since a changed cache key or new query parameter can halve it overnight.
- Pair it with origin metrics such as origin request rate and response time to confirm the real effect.
- Do not lengthen TTLs blindly: without versioned URLs or reliable purging, users may see outdated content.
Put simply
Imagine a library branch that keeps popular books on its own shelves. When a reader asks for a book that is already there, they get it at once. When it is not, the branch must order it from the central warehouse, which takes longer.
The cache hit ratio is the share of requests served from local shelves. A higher share means faster service for readers and less work for the warehouse. On the internet, the branch is a nearby server and the warehouse is the website’s main server.
In practice
An online retailer serves product images, scripts and pages through a CDN. Its dashboard shows a request hit ratio of only 62 percent, and origin servers struggle during sales. Analysis of the cache keys reveals that marketing tracking parameters create thousands of distinct URLs for the same product image.
The team configures the CDN to ignore tracking parameters in the cache key, adds content hashes to script and style file names with a one-year max-age, and enables an origin shield in the region closest to the origin. Product pages receive a five-minute TTL with stale-while-revalidate.
Within a week, the overall request hit ratio rises to about 91 percent, and origin requests fall by roughly three quarters. The next seasonal sale runs without scaling the origin cluster, and median page load times drop noticeably for visitors far from the data center.