What this calculates
Cache hit ratio is the single most direct measurement of whether a cache is actually doing its job: of every request that checked the cache, what fraction found what it was looking for (a hit) versus had to fall through to the slower source of truth behind it — a database, an origin server, a disk read (a miss).
hit rate = (hits / requests) × 100
miss rate = (misses / requests) × 100 = 100 − hit rateHit rate and miss rate always sum to exactly 100% — every request is either a hit or a miss, with nothing in between, so improving one number is mathematically identical to reducing the other by the same amount.
Why this number matters more than it looks
The gap between a hit and a miss is usually enormous — an in-memory cache lookup takes microseconds, while whatever sits behind it (a database query, a disk read, an origin fetch across the network) can easily take 10-1000x longer. That gap means small changes in hit rate translate into outsized changes in real load: moving from a 90% to a 95% hit rate doesn't just look like a 5-point improvement, it halves the number of expensive misses your backend has to absorb.
What counts as a "good" hit rate
There's no single universal target — it depends entirely on what's being cached and how cacheable that content actually is:
| Cache type | Commonly cited range |
|---|---|
| CDN — mostly static content (images, JS, CSS) | 95–99% |
| CDN — dynamic or personalized content | Significantly lower, and normal |
| Application cache (Redis, Memcached) in production | 80–90%+ considered healthy |
| Application cache, acceptable but worth investigating | 60–80% |
A CDN serving highly dynamic, per-user content isn't "bad" at 60% the way an application cache would be — a low ratio there just reflects the actual cacheability of the content, not a misconfiguration. Chasing a universal "good" number without that context is how CDN tuning guides end up telling you to cache things that shouldn't be cached at all.
FAQ
Why can't cache hits exceed total requests?
Every hit is also a request — there's no way to have more successful lookups than lookups attempted in the first place, which is exactly why this tool rejects a hit count larger than the request count instead of silently producing a hit rate over 100%.
Does a higher hit rate always mean better performance?
Usually, but not automatically — a hit rate can look great while serving stale data (if invalidation is broken) or by caching things nobody actually benefits from evicting faster, more useful entries to make room. Hit rate measures whether the cache is being used, not whether it's caching the right things.
Is anything I enter here sent anywhere?
No — this calculation runs entirely in your browser. Nothing here is ever sent to a server.