Transloadit

What is Cache Hit Ratio?

Cache hit ratio is the proportion of requests that a cache answers from a stored response instead of forwarding them to the origin. It is usually counted per request and sometimes per byte delivered, and tools differ on whether uncacheable requests and revalidated responses count, so two reported ratios are comparable only when their definitions match.

How Cache Hit Ratio works

A hit means the cache satisfied the request from a stored response without forwarding it. RFC 9211 standardizes how a cache reports this on each response in the Cache-Status header: hit when the request was not forwarded, or fwd with a reason such as uri-miss, vary-miss, stale, or bypass when it was. A ratio is a count of those outcomes over a chosen time window and set of requests. Three things mostly determine it: how long responses stay fresh, how many distinct cache keys the same content is spread across, and whether an object is requested often enough at a cache location to still be stored when the next request arrives. Edge locations fill their caches separately, so the first request for an object at each location misses that location’s cache; a shared upper tier can answer it without contacting the origin.

Key facts

  1. Are uncacheable requests in the denominator? It depends on the tool. Amazon CloudFront’s Cache hit rate metric counts only cacheable requests and excludes POST, PUT, and errors, while its cache statistics report shows hits, misses, and errors as percentages of all viewer requests. A Fastly engineering article about Varnish uses the narrower definition, hits divided by hits plus misses, and calls the share of requests that are cacheable at all cache coverage. Check the denominator before comparing two dashboards or setting a target.
  2. Is a revalidated response a hit? Not under RFC 9211: a stale stored response that had to go forward for validation is reported as fwd=stale, even when the origin answers 304 and the stored body is reused. Vendors vary. Cloudflare’s Cache Analytics counts revalidated requests as served by origin in its Requests view but as served by Cloudflare in its Data Transfer view, and CloudFront’s cache statistics chart does not include refresh hits, its term for requests for expired objects that are still in the edge cache.
  3. Requests or bytes? They answer different questions. A request-based ratio weights every request equally, whether it carries a few bytes or many megabytes, and tracks how often a viewer waits on the origin. A byte-based ratio is the share of bytes delivered to clients that were cache hits. A site whose small files hit while its large media files miss can show a high request ratio and a low byte ratio. Either ratio is a share, not an amount: most hosting providers bill egress by the data their servers send, and that amount can grow with traffic while a ratio holds steady. For cost decisions, read a byte-based figure together with origin bytes. Cloudflare’s Data Transfer view counts data transferred instead of requests; CloudFront’s cache statistics report gives BytesFromMisses, which AWS calls a good approximation of bytes fetched from the origin but which excludes expired objects that were still in the edge cache.
  4. Why is the ratio low when the caching rules look right? Once cache lifetimes are ruled out, check cache key fragmentation first. When CloudFront caches on query string parameters, it stores ?a=1&b=2 and ?b=2&a=1 as separate objects, and the same applies to differences in parameter case and to each distinct value of a cookie or header, such as User-Agent, that it is configured to cache on. Beyond that, a response can be reused only while it is still stored, and only if it is fresh, successfully revalidated with the origin, or allowed to be served stale, for example under stale-while-revalidate or stale-if-error. Caches evict infrequently requested objects, and each edge location fills its own cache. Longer lifetimes and a shared upper cache tier, such as CloudFront Origin Shield or Cloudflare Tiered Cache, reduce requests to the origin.

When Cache Hit Ratio matters

Track hit ratio when each miss costs origin latency, origin load, or on-demand processing. A falling ratio can point to short cache lifetimes or a cache key split by query strings, cookies, or request headers. If the tool counts every request, a low value is expected for traffic that is mostly uncacheable; if it counts only cacheable requests, the same traffic can still show a high value.

How Transloadit helps with Cache Hit Ratio

On Transloadit’s Smart CDN a miss does more work than on a CDN that only stores existing files: it imports the original and runs your Template, while a hit repeats only the delivery step from the edge. The /tlcdn/deliver Robot documentation describes cached delivery as saving latency and encoding volume, so the hit ratio of your Smart CDN URLs affects both latency and usage. For signed URLs, the effective cache lifetime is bounded by the remaining signature lifetime, so a shorter exp lowers reuse.

The pages linked here do not define a hit-ratio report or state which requests it would count. The Smart CDN overview suggests checking cache response headers when debugging; if you compute a ratio from them, record your own definition of a hit.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free