Cache hit ratio calculator

Q: What is a good cache hit ratio?

It depends entirely on the content. Hashed static assets should reach 99%, video segments and images around 95%, HTML around 85%, and API responses vary widely because anything keyed to a user cannot be cached by a shared cache at all. A single site-wide number is not meaningful — a 90% average can be a healthy asset cache dragging up a broken HTML cache, or the reverse.

Q: How does cache hit ratio affect cost?

A miss is billed twice: once as origin egress to pull the object into the edge, and again as edge egress to deliver it to the user. Only the second charge is unavoidable. Because object-storage egress to the internet lists around $0.09/GB against CDN egress an order of magnitude lower, the small percentage that misses frequently costs more than the entire volume that is delivered.

Q: Is there a point where improving hit ratio stops being worth it?

Not in billing terms — the cost curve against hit ratio is a straight line, so a point gained from 94% to 95% saves exactly what a point gained from 60% to 61% saves. What changes is the engineering effort required to get each point. The diminishing return is in the work, not the payoff, which is the opposite of how most teams reason about it.

Q: Why is my cache hit ratio low?

In rough order of frequency: query strings in the cache key so that tracking parameters fragment identical objects, an over-broad Vary header such as Vary: User-Agent, Set-Cookie on responses that would otherwise be cacheable, freshness lifetimes shorter than the interval between requests, a working set larger than the edge will hold, and deploys that purge by wildcard rather than by surrogate key. All of these are visible in response headers.

Q: Does a free-egress origin make hit ratio irrelevant?

It makes it financially irrelevant, not operationally. Cloudflare R2 charges nothing to egress anywhere, and Backblaze B2 charges nothing to Bandwidth Alliance partners, so on those pairs a miss costs no money. It still costs a round trip to the origin before the first byte reaches the user, and a cold cache under load still puts the full request rate on your origin infrastructure.

Q: Does S3 to CloudFront cost the same as S3 to another CDN?

No, and this is one of the larger hidden differences between CDN quotes. S3 to CloudFront is not billed as data transfer out, while pulling the same object from S3 to any third-party CDN is billed at the full internet rate. Comparing two CDNs on their edge per-GB rate alone will therefore understate the cost of the non-AWS option unless you model origin egress separately — which is what this calculator does.

A cache miss is billed twice — once to pull the object from your origin, once to deliver it to the user. This turns a hit ratio into the number on the invoice, at your volume and your origin’s rates, and shows what a point of ratio is worth per year.

Delivered to users each month10 TB

Cache hit ratio today80%

Target hit ratio95%

Origin

First-tier internet egress. Falls with volume, but the first 10 TB is where most workloads sit.

Free to CloudFront. S3 to CloudFront is not billed as data transfer out. Pulling the same object to any other CDN is billed at the full internet rate, which is why a CloudFront bill and a third-party CDN bill are not comparable on the edge rate alone.

Origin egress $/GB

List price for AWS S3

Edge egress $/GB

ZeroBuffer first tier

Bill at 80%

$229.00

$49.00 edge + $180.00 origin

Bill at 95%

$94.00

$49.00 edge + $45.00 origin

Saved per year

$1,620

1.5 TB of origin fetches avoided each month

Origin egress is 79% of your bill

effective $0.02/GB delivered

More than half of what you pay is refilling the cache, not serving users. At $0.09/GB against <$0.01/GB at the edge, the 20% that misses costs more than the 100% that is delivered.

Monthly cost against hit ratio

0% — every request goes to origin100% — origin never touched

The line is straight, which is the useful part: there are no diminishing returns in billing. A point of hit ratio is worth the same whether you are moving from 60% to 61% or from 94% to 95%. What gets harder near the top is the engineering, not the payoff.

What the ratio should be

Content	Achievable	Notes
Hashed static assets	99%	Content-addressed filenames with a year-long immutable lifetime. Anything below about 98% here means the cache is being evicted or the URLs are not actually stable.
Video segments (VOD)	95%	Segments never change once written. The residual misses are cold long-tail catalogue, which is expected and is a capacity question rather than a configuration one.
Images	95%	Usually limited by how many variants exist. A resize or format query string that is not normalised multiplies cache keys and quietly caps the ratio.
HTML pages	85%	Lower by nature — short lifetimes and personalisation. stale-while-revalidate raises the effective ratio without raising staleness risk much.
API responses	60%	Highly variable. Anything keyed to a user is uncacheable at a shared cache by definition; the ratio here reflects how much of the surface is genuinely public.

Why a ratio is low

Every one of these is visible in response headers. The cache header checker will name the ones affecting a given URL.

Query strings in the cache key
If the edge keys on the full URL, ?utm_source=twitter and ?utm_source=email are two objects with identical bytes, and every campaign fragments the cache further. Strip or allowlist query parameters at the edge — this is usually the single biggest win available.
An over-broad Vary header
Vary: User-Agent creates a separate cache entry per browser string, which is effectively per-device and destroys the ratio. Vary: Accept-Encoding is fine and necessary; almost nothing else is.
Set-Cookie on cacheable responses
Most CDNs refuse to cache a response carrying Set-Cookie, to avoid serving one visitor’s session to everyone. A framework that sets a session cookie on every response makes the entire site uncacheable without anyone changing a cache setting.
Lifetimes shorter than the request interval
An object with max-age=60 requested once every five minutes misses every single time. The lifetime has to exceed the gap between requests for a cache to be doing anything at all — for cold long-tail content that means hours or days, not minutes.
Cache size against catalogue size
A large catalogue evicts itself. If the working set exceeds what the edge will hold, objects are gone before they are requested again, and no header change fixes it — that is a tiered-caching or origin-shield problem.
Purging too broadly
A deploy that purges everything discards warm objects that did not change. Purge by surrogate key or by path, not by wildcard, or every release resets the ratio to zero and pays a full origin refill.

Why the miss rate matters more than it looks

Every byte a user receives leaves the edge and is billed, whatever the hit ratio does. What the ratio controls is the second charge: the origin egress needed to fill the cache. Object storage lists that egress an order of magnitude above CDN egress — around $0.09/GB from S3 against a flat rate near $0.005/GB at the edge — so a 20% miss rate can cost more than the whole of the delivered volume.

That asymmetry is the reason “our hit ratio is about 80%, which seems fine” is an expensive sentence. 80% sounds like a pass mark. On an S3 origin it means origin egress is roughly four fifths of the bill.

The pairing nobody prices in

Origin egress is not a fixed property of your origin — it depends on who is pulling. S3 to CloudFront is free; S3 to any other CDN is billed at the full internet rate. Backblaze B2 and Cloudflare R2 charge nothing to Bandwidth Alliance partners, and ZeroBuffer delivers on Bunny capacity, which is one of them. On those pairings hit ratio stops being a billing question and becomes purely a latency one.

Which means comparing two CDNs on their edge per-GB rate alone is not a comparison. The origin side can be the larger half, and it moves depending on which CDN you choose.

Fixing a low ratio

Almost every cause is a cache-key problem rather than a capacity problem, and almost every one is visible in the response headers. Run a URL through the cache header checker to see which apply, then use the Cache-Control generator to build the header that fixes it. For what the resulting egress costs across providers, the CDN cost calculator compares list rates at your volume.

Frequently asked questions

What is a good cache hit ratio?: It depends entirely on the content. Hashed static assets should reach 99%, video segments and images around 95%, HTML around 85%, and API responses vary widely because anything keyed to a user cannot be cached by a shared cache at all. A single site-wide number is not meaningful — a 90% average can be a healthy asset cache dragging up a broken HTML cache, or the reverse.
How does cache hit ratio affect cost?: A miss is billed twice: once as origin egress to pull the object into the edge, and again as edge egress to deliver it to the user. Only the second charge is unavoidable. Because object-storage egress to the internet lists around $0.09/GB against CDN egress an order of magnitude lower, the small percentage that misses frequently costs more than the entire volume that is delivered.
Is there a point where improving hit ratio stops being worth it?: Not in billing terms — the cost curve against hit ratio is a straight line, so a point gained from 94% to 95% saves exactly what a point gained from 60% to 61% saves. What changes is the engineering effort required to get each point. The diminishing return is in the work, not the payoff, which is the opposite of how most teams reason about it.
Why is my cache hit ratio low?: In rough order of frequency: query strings in the cache key so that tracking parameters fragment identical objects, an over-broad Vary header such as Vary: User-Agent, Set-Cookie on responses that would otherwise be cacheable, freshness lifetimes shorter than the interval between requests, a working set larger than the edge will hold, and deploys that purge by wildcard rather than by surrogate key. All of these are visible in response headers.
Does a free-egress origin make hit ratio irrelevant?: It makes it financially irrelevant, not operationally. Cloudflare R2 charges nothing to egress anywhere, and Backblaze B2 charges nothing to Bandwidth Alliance partners, so on those pairs a miss costs no money. It still costs a round trip to the origin before the first byte reaches the user, and a cold cache under load still puts the full request rate on your origin infrastructure.
Does S3 to CloudFront cost the same as S3 to another CDN?: No, and this is one of the larger hidden differences between CDN quotes. S3 to CloudFront is not billed as data transfer out, while pulling the same object from S3 to any third-party CDN is billed at the full internet rate. Comparing two CDNs on their edge per-GB rate alone will therefore understate the cost of the non-AWS option unless you model origin egress separately — which is what this calculator does.

Monthly cost against hit ratio

0% — every request goes to origin100% — origin never touched

What the ratio should be

Content	Achievable	Notes
Hashed static assets	99%	Content-addressed filenames with a year-long immutable lifetime. Anything below about 98% here means the cache is being evicted or the URLs are not actually stable.
Video segments (VOD)	95%	Segments never change once written. The residual misses are cold long-tail catalogue, which is expected and is a capacity question rather than a configuration one.
Images	95%	Usually limited by how many variants exist. A resize or format query string that is not normalised multiplies cache keys and quietly caps the ratio.
HTML pages	85%	Lower by nature — short lifetimes and personalisation. stale-while-revalidate raises the effective ratio without raising staleness risk much.
API responses	60%	Highly variable. Anything keyed to a user is uncacheable at a shared cache by definition; the ratio here reflects how much of the surface is genuinely public.

Why a ratio is low

Every one of these is visible in response headers. The cache header checker will name the ones affecting a given URL.

Query strings in the cache key

If the edge keys on the full URL, ?utm_source=twitter and ?utm_source=email are two objects with identical bytes, and every campaign fragments the cache further. Strip or allowlist query parameters at the edge — this is usually the single biggest win available.

An over-broad Vary header

Vary: User-Agent creates a separate cache entry per browser string, which is effectively per-device and destroys the ratio. Vary: Accept-Encoding is fine and necessary; almost nothing else is.

Set-Cookie on cacheable responses

Most CDNs refuse to cache a response carrying Set-Cookie, to avoid serving one visitor’s session to everyone. A framework that sets a session cookie on every response makes the entire site uncacheable without anyone changing a cache setting.

Lifetimes shorter than the request interval

An object with max-age=60 requested once every five minutes misses every single time. The lifetime has to exceed the gap between requests for a cache to be doing anything at all — for cold long-tail content that means hours or days, not minutes.

Cache size against catalogue size

A large catalogue evicts itself. If the working set exceeds what the edge will hold, objects are gone before they are requested again, and no header change fixes it — that is a tiered-caching or origin-shield problem.

Purging too broadly

A deploy that purges everything discards warm objects that did not change. Purge by surrogate key or by path, not by wildcard, or every release resets the ratio to zero and pays a full origin refill.

Why the miss rate matters more than it looks

The pairing nobody prices in

Which means comparing two CDNs on their edge per-GB rate alone is not a comparison. The origin side can be the larger half, and it moves depending on which CDN you choose.

Fixing a low ratio

Frequently asked questions

What is a good cache hit ratio?

It depends entirely on the content. Hashed static assets should reach 99%, video segments and images around 95%, HTML around 85%, and API responses vary widely because anything keyed to a user cannot be cached by a shared cache at all. A single site-wide number is not meaningful — a 90% average can be a healthy asset cache dragging up a broken HTML cache, or the reverse.

How does cache hit ratio affect cost?

A miss is billed twice: once as origin egress to pull the object into the edge, and again as edge egress to deliver it to the user. Only the second charge is unavoidable. Because object-storage egress to the internet lists around $0.09/GB against CDN egress an order of magnitude lower, the small percentage that misses frequently costs more than the entire volume that is delivered.

Is there a point where improving hit ratio stops being worth it?

Not in billing terms — the cost curve against hit ratio is a straight line, so a point gained from 94% to 95% saves exactly what a point gained from 60% to 61% saves. What changes is the engineering effort required to get each point. The diminishing return is in the work, not the payoff, which is the opposite of how most teams reason about it.

Why is my cache hit ratio low?

In rough order of frequency: query strings in the cache key so that tracking parameters fragment identical objects, an over-broad Vary header such as Vary: User-Agent, Set-Cookie on responses that would otherwise be cacheable, freshness lifetimes shorter than the interval between requests, a working set larger than the edge will hold, and deploys that purge by wildcard rather than by surrogate key. All of these are visible in response headers.

Does a free-egress origin make hit ratio irrelevant?

It makes it financially irrelevant, not operationally. Cloudflare R2 charges nothing to egress anywhere, and Backblaze B2 charges nothing to Bandwidth Alliance partners, so on those pairs a miss costs no money. It still costs a round trip to the origin before the first byte reaches the user, and a cold cache under load still puts the full request rate on your origin infrastructure.

Does S3 to CloudFront cost the same as S3 to another CDN?

No, and this is one of the larger hidden differences between CDN quotes. S3 to CloudFront is not billed as data transfer out, while pulling the same object from S3 to any third-party CDN is billed at the full internet rate. Comparing two CDNs on their edge per-GB rate alone will therefore understate the cost of the non-AWS option unless you model origin egress separately — which is what this calculator does.