What is a cache hit ratio?

What is a cache hit ratio?

Cache hit ratio is the share of cacheable requests that are served from cache instead of being fetched from the origin. If 1,000 eligible requests reach a CDN edge and 800 are answered from stored objects, the request cache hit ratio is 80 percent. The remaining 200 are cache misses, revalidations, bypasses, or requests that the cache cannot serve.

The metric matters because it connects performance, cost, and resilience. A higher hit ratio usually means fewer origin requests, lower origin bandwidth, lower application load, and faster responses for users. But it is not a goal to maximize blindly. A site can have an impressive global hit ratio while its checkout, search, account, or API routes still overload the origin. A site can also raise its hit ratio by caching content that should never be shared.

Request hit ratio versus byte hit ratio

There are two common versions of the metric. Request hit ratio counts requests. Byte hit ratio counts transferred bytes. They answer different questions.

A high request hit ratio means the cache is answering many lookups. This is useful for understanding origin request load. It matters for applications where generating each response is expensive, even when the responses are small.

A high byte hit ratio means the cache is serving most of the data volume. This is useful for understanding bandwidth savings. A few large videos, images, or downloads can dominate byte hit ratio even if many small HTML or API requests are misses.

Healthy analysis looks at both. If request hit ratio is high but byte hit ratio is low, large files may be bypassing cache or expiring too quickly. If byte hit ratio is high but request hit ratio is low, small dynamic requests may still be hitting the origin heavily. Neither metric should be reviewed only as one global average.

What counts as a hit or miss

Cache status labels vary between platforms, but the underlying states are similar. A hit is served from a stored object that is fresh enough to use. A miss means the cache did not have a matching usable object and had to fetch from the origin or another cache layer. A bypass means policy intentionally skipped cache, often because of cookies, authorization, request method, headers, route rules, or response directives. A revalidation checks whether an expired object is still valid before reuse.

These distinctions matter. A low hit ratio caused by deliberate bypass on authenticated routes is not necessarily a problem. A low hit ratio caused by random query strings on static assets is usually fixable. A high revalidation rate may be acceptable for content that changes often, but it still creates origin dependency.

The inputs that shape hit ratio

Cache hit ratio is shaped by cacheability, TTL, cache keys, traffic distribution, purge behavior, and the number of edge locations that need to warm their local caches. Public static assets with versioned URLs and long TTLs usually produce strong hit ratios. Dynamic pages with cookies, broad Vary headers, short TTLs, or frequent purges often do not.

The cache key is especially important. A cache key that includes every query parameter may treat tracking tags or cache-busting strings as separate objects, lowering hit ratio. A cache key that ignores meaningful parameters can serve the wrong response. Cookies, language, content encoding, device type, and authorization state can all affect whether two requests are truly equivalent.

Traffic distribution matters too. A global CDN has many edge locations. The first request for an object at each edge may be a miss. Very large catalogs with long-tail traffic can have lower hit ratios because many objects are requested rarely. Origin shield or tiered caching can help by consolidating misses through an intermediate cache, but it still depends on route policy and object reuse.

How to evaluate the metric

Start by segmenting. Review hit ratio by hostname, path pattern, content type, status code, response size, cache status, region, and user journey. A single number across the whole site is useful for trend awareness, but it is too blunt for decision-making. Separate static assets from HTML. Separate public APIs from authenticated APIs. Separate successful responses from redirects and errors.

Then compare cache metrics with origin metrics. A rising hit ratio should normally reduce origin request rate, origin bandwidth, and origin CPU or application work for the affected routes. If it does not, the cached traffic may not be the traffic causing load. Conversely, a small hit-ratio improvement on a high-cost dynamic page can be more valuable than a large improvement on tiny assets that were cheap to serve.

Use response headers and logs to confirm why objects miss. Look for Cache-Control directives, Set-Cookie, Authorization, Vary, response status, request method, query parameters, and route-level CDN rules. If a route is intended to cache but consistently misses, the answer is usually visible in this evidence.

Improving hit ratio safely

The safest improvements usually start with public assets. Use versioned filenames for CSS, JavaScript, images, fonts, and other static files, then apply long TTLs. Remove meaningless query parameters from the cache key where appropriate, such as tracking tags, but preserve parameters that change the response. Normalize URLs only when the application behavior is well understood.

For HTML and APIs, start with route classification. Public pages may be cacheable for seconds or minutes. Product data may be cacheable if freshness expectations and invalidation rules are clear. Personalized, authenticated, or state-changing responses should be kept private or uncached unless the architecture deliberately separates public and private fragments.

Avoid broad full-site purges when targeted purges or versioned URLs would work. Full purges can create a cache stampede: many edges miss at the same time and send traffic back to the origin. During busy periods this can make a healthy origin look broken. Request collapsing, tiered caching, and origin shielding can reduce the effect, but good purge hygiene is still important.

Security and abuse considerations

A high cache hit ratio is not always good. If private responses are cached and reused, the metric may improve while privacy fails. If security challenge pages or error responses are cached too broadly, users may see stale blocks or misleading failures. If a cache key ignores important request attributes, one user or variant may receive another user's content.

Attackers may also try to lower hit ratio. Random query strings, unique paths, scraping deep catalogs, and forced cache misses can shift load back to the origin. Bot controls, rate limits, query normalization, route-specific cache policy, and origin access restrictions help prevent the cache from being turned into a bypassable speed bump.

The practical goal is not the highest possible cache hit ratio. It is the highest safe hit ratio for the routes that benefit from caching, with private data protected, dynamic work controlled, and enough logging to explain every miss that matters. When reviewed this way, cache hit ratio becomes an operational tool rather than a vanity metric.