the cache hit ratio
Imagine a help desk that keeps printed answers to the most common questions. When someone asks a question already on the shelf, the clerk answers instantly (a hit); when the question is new, the clerk has to phone headquarters and wait (a miss). If 90 out of every 100 questions are already on the shelf, the desk runs fast and headquarters is barely bothered. The cache hit ratio is that fraction: the share of requests a cache answers from its stored copies rather than passing back to the origin.
It is computed simply as hits divided by total requests — for example 9,000 hits out of 10,000 requests is a 0.9 (90%) hit ratio, leaving a 10% miss ratio. Each hit is fast and free of origin load; each miss costs a full trip back to the origin to fetch (and usually store) the content — a cache fill. The hit ratio depends on what you cache and for how long: long freshness lifetimes, popular content with many repeat requests, and a large enough cache all push it up; highly personalized content, very long-tail content (many items each rarely requested), and aggressive no-store rules push it down.
Why it matters: the hit ratio is the headline metric for how well a cache or CDN is working. A high hit ratio means most users are served from nearby, the origin handles only a trickle of traffic, and bandwidth costs drop. But read it carefully: a hit ratio of items can differ from a hit ratio of bytes, since a few huge files behave differently from many tiny ones, and an extremely high ratio might just mean you are serving stale content. It is a guide, not a goal in itself — the real aim is fast, correct delivery, and the hit ratio is one (important) signal toward that.
A CDN reports 95% hits on images but only 40% on HTML. The images rarely change and are shared by everyone (easy to cache), while the HTML is partly personalized and short-lived — so most HTML requests still travel back to the origin.
Different content caches differently: shared, stable assets hit far more often.
A high hit ratio is not automatically good. It can hide staleness (serving outdated copies) or mask that the cached content was unpopular anyway. Always pair it with correctness checks and with latency the users actually feel.