Cache Hit Ratio
Cache hit ratio is the share of requests served from cache rather than the origin: a higher ratio means less origin load, lower latency, and lower egress and compute bills.
also: cache hit ratio · cache hit rate
If 90 of every 100 requests are answered from cache, your hit ratio is 90% and only 10% reach the origin. Each point of hit ratio you gain sheds origin work and serves that request from somewhere closer and cheaper, so the relationship to cost is direct: at high traffic, moving from 90% to 95% halves origin requests (10% to 5%), it does not shave a tenth off them.
The ratio is set by what you cache, for how long, and how you key it. Long TTLs and cache-friendly URLs lift it; per-user query strings, cookies, and short TTLs sink it by fragmenting the cache. Watch the miss cost too: a 95% hit ratio still means the origin must survive every cache expiry and purge, so a stampede on a popular key can take it down even when the average looks healthy.
faq
Questions & answers
- What is a good cache hit ratio?
- For static assets, well above 95% is achievable and expected. For dynamic or personalised content it is lower and depends on how cacheable the responses are. The useful question is not the absolute number but what each extra point removes from your origin load and bill at your traffic.
- How do I improve cache hit ratio?
- Cache more responses, set longer TTLs where the data allows, and stop fragmenting the cache with per-user query strings, cookies, and headers that vary the cache key. Normalise URLs, strip tracking parameters before the cache, and cache at the edge close to users.
Want this applied to your stack, not just defined?
The free tools run the numbers; an audit tells you where the real cost and risk are. Book a call, or leave your email and I'll reach out.
Prefer proof first? See how this plays out in real case studies →