What Is a Cache Hit? Cache Hit Ratio Explained and Improved

Raising a CDN's cache hit ratio from 95% to 99% cuts requests reaching the origin by 80%, from 50,000 to 10,000 per million. A cache hit is a request answered from a stored, still-fresh response without contacting the origin. Cache hit ratio is hits divided by cacheable requests, multiplied by 100. This guide gives the formula with a worked example, target ranges by content type, the ten settings that raise the ratio, and the failure modes that quietly lower it.

Under HTTP caching rules defined in RFC 9111 (published 2022), a cache hit requires two things: the stored response must match the request's cache key, and it must still be fresh or be allowed to be served stale. A response that is cacheable but not yet stored is still a miss, so every new object costs at least one origin fetch per cache tier.

Cache hit vs. cache miss: what happens during a lookup

On every request, the cache builds a lookup key from attributes such as host, path, query string, method and any headers named in Vary. It checks for a stored object under that key and then checks freshness against Cache-Control max-age or s-maxage, Expires, and the object's current Age.

• Fresh hit: the object exists and is within its TTL. The body is served from memory or disk with no upstream traffic.
• Revalidated hit: the object is stale, so the cache sends a conditional request with If-None-Match (using the stored ETag) or If-Modified-Since (using Last-Modified). A 304 Not Modified reply lets it reuse the stored body. This costs an origin round trip but almost no bytes.
• Stale hit: served under stale-while-revalidate or stale-if-error while a background refresh runs or while the origin is failing.
• Miss: no usable object exists, so the full response is fetched, stored if cacheable, and returned.
• Bypass: the request is never eligible, because of no-store, an Authorization header, a non-GET method or a rule.

Cache hit vs. miss is the core trade: a hit serves usable stored data locally, while a miss pays for an upstream fetch, origin CPU and egress, and adds latency to the first byte. A miss also consumes cache resources, because the new object may evict something that would have been a hit later.

Where cache hits occur in the stack

The same hit and miss logic applies in browser caches, forward and reverse proxies, CDN edges and shields, API gateways, DNS resolvers, Redis and Memcached, database buffer pools and CPU caches. The difference is what a miss costs: a few nanoseconds for an L1 miss, a disk read for a buffer pool, and potentially hundreds of milliseconds plus egress fees for a CDN miss that crosses an ocean to the origin. In enterprise delivery, the ratio matters most for video segments, software and game downloads, images, versioned JavaScript and CSS, anonymous HTML and cacheable API responses.

How to calculate cache hit ratio, with a worked example

Cache hit ratio equals cache hits divided by eligible requests, multiplied by 100. Eligible requests are hits plus misses, excluding bypassed and uncacheable traffic. Before comparing numbers, decide whether revalidated hits, stale hits and shield hits count as hits, because vendors classify them differently.

Worked example for one day of edge traffic:

• Total requests: 12,000,000, of which 2,000,000 are bypasses (authenticated API calls).
• Eligible requests: 10,000,000. Fresh hits: 9,300,000. Revalidated hits: 200,000. Misses: 500,000.
• Hit ratio counting revalidations as hits: 9,500,000 divided by 10,000,000 equals 95%.
• Hit ratio over all requests: 9,500,000 divided by 12,000,000 equals 79.2%.

Both numbers are arithmetically correct, which is why a dashboard figure means nothing until the denominator is stated.

Request hit ratio vs. byte hit ratio

Request hit ratio counts responses; byte hit ratio counts bytes served from cache divided by total bytes served. They diverge when object sizes vary. Suppose 1,000,000 requests for 50 KB thumbnails hit 99% of the time, while 10,000 requests for a 2 GB installer hit only 80%. Request hit ratio is about 98.8%, yet origin egress is 2,000 installer misses times 2 GB, roughly 4 TB, against about 0.5 GB from thumbnail misses. Byte hit ratio is the number that predicts the egress bill; request hit ratio predicts origin request load.

Why miss ratio is the number to manage

Origin load scales with the miss ratio, not the hit ratio. At 95% hits the origin sees 5% of eligible requests; at 99% it sees 1%, a fivefold reduction from a four-point change. Our recommendation is to report offload as misses per million requests and origin bytes per day, because "95% vs. 97%" sounds marginal while "50,000 vs. 30,000 origin fetches per million" reads correctly in a capacity review.

Cache hit ratio targets by content type

The ranges below are this blog's working targets for 2026, built from cacheability and object reuse patterns rather than any single measurement. Treat them as estimates and calibrate against your own catalog size and traffic skew.

Static, versioned objects should sit at 98% or above, so anything lower points to a key or TTL problem rather than a traffic problem.

How to improve cache hit ratio: ten CDN settings

To improve cache hit ratio, reduce the number of distinct cache keys per real object, keep objects fresh longer, and stop multiple caches from filling independently. The ten settings below are ordered roughly by impact per hour of work for a typical static or video workload.

1. Normalize the cache key. Lowercase hosts, collapse duplicate hostnames to one canonical key, and exclude headers that do not change the body.
2. Allowlist query string parameters. Keep only parameters that change the response, sort them, and drop tracking parameters such as utm_source or click IDs. One campaign link can otherwise multiply keys by thousands.
3. Remove cookies from the key for static paths. Ignore request cookies and strip Set-Cookie on asset responses, which many caches otherwise treat as uncacheable.
4. Use long TTLs with versioned URLs. Fingerprinted filenames can carry Cache-Control: public, max-age=31536000, immutable, so freshness never expires while the file name changes on every deploy.
5. Split edge and browser TTLs. Use s-maxage for the CDN and a shorter max-age for browsers when content must be purgeable at the edge but not pinned in clients.
6. Serve stale on purpose. stale-while-revalidate=60 turns expiry-time misses into hits with a background refresh; stale-if-error=86400 keeps serving during origin incidents.
7. Constrain Vary. Normalize Accept-Encoding to a few buckets (Brotli, gzip, identity) and never vary on User-Agent; one Vary on User-Agent can split a single object into hundreds of variants.
8. Enable an origin shield. A shield tier means each object is fetched from origin once, rather than once per edge location, which matters most for long-tail catalogs.
9. Turn on request collapsing. When a popular object expires or a live segment first appears, collapsing merges concurrent misses into one upstream fetch instead of a thundering herd.
10. Cache range requests in aligned slices, and purge precisely. Fetch large files in fixed slices so partial requests share cache entries, purge by URL or tag instead of purging everything, and warm the cache before large releases.

Several of these are platform features rather than headers. BlazingCDN includes origin shield, request coalescing, purge and cache warm-up through the API on every plan, alongside a 96%+ average cache hit ratio, as listed on its CDN features page covering origin shield and cache controls.

Failure modes: what lowers cache hit ratio and how to confirm it

Most hit ratio regressions come from a deploy or a marketing change rather than from traffic itself. Each failure below has a distinct signature in logs or headers.

A miss on an object whose TTL has not expired is almost always eviction or a key mismatch, so separating expiry misses from other misses is the fastest diagnostic step.

Verify this on your own stack

Request the same asset twice and read the vendor's cache status header, the Age header and Cache-Control together: a second response with Age above zero and a hit status confirms caching. Then pull the top 100 missed objects by bytes, not by request count, and check their Vary and ETag values. Finally, report fresh hits, revalidated hits, stale hits, bypasses and evictions as separate series before changing any policy.

FAQ: cache hit ratio and cache hits

What is a cache hit in a CDN?

A cache hit in a CDN is a request the edge or shield answers from a stored response without fetching from the origin. The object must match the request's cache key and be fresh, or be servable stale. Vendors differ on whether revalidated 304 responses and stale-while-revalidate responses count as hits, so check definitions before comparing dashboards.

What is a good cache hit ratio for a CDN?

A good CDN cache hit ratio is 95% or higher for static, versioned assets, video segments and software downloads. Anonymous HTML typically lands between 60% and 90%, and APIs can be far lower. Judge the figure by origin requests and origin bytes per day, because a few points of hit ratio can change origin load fivefold.

What is the difference between cache hit vs miss in latency?

A cache hit returns from the nearby cache, while a miss adds a full round trip to the origin plus origin processing time. The gap depends on distance: a miss to a same-region origin may add tens of milliseconds, while an intercontinental miss can add well over 100 ms to time to first byte, before any origin queuing.

Why is byte hit ratio lower than request hit ratio?

Byte hit ratio is usually lower when large objects miss more often than small ones. Thousands of small cached thumbnails inflate request hit ratio, while a few large installer or video misses dominate bytes. Byte hit ratio predicts origin egress cost; request hit ratio predicts origin request load, so track both separately.

How fast can you improve cache hit ratio after changing settings?

Cache hit ratio usually improves within one TTL cycle after a cache key or query string change, because new requests start sharing entries immediately. Settings that depend on warm caches, such as an origin shield or longer TTLs, show their full effect after popular objects are refetched once, which can take hours for long-tail catalogs.

Measure your miss ratio, then test it on a second CDN

This week, export one day of edge logs and compute four numbers: request hit ratio over eligible requests, byte hit ratio, misses per million requests, and origin bytes per day. Then rank missed objects by bytes and check each against the ten settings above; query strings, Vary and missing shield coverage typically account for the largest share. Re-run the same four numbers seven days after each change so the gain is measured, not assumed.

If your traffic is high-volume video, downloads or images, BlazingCDN's Anycast CDN runs pull caching on NVMe SSD servers with origin shield and request coalescing included, and its Anycast CDN for high cache hit ratio delivery can run beside your current provider as a second CDN with a weighted DNS split for a direct comparison.