The CDN Metric That Lies: Why Your 85% Cache Hit Ratio Still Bleeds Origin Bandwidth

What the Ratio Counts

Cloud CDN defines cache hit ratio as "the percentage of times that a requested object is served from the cache." A 60% hit ratio means 60% of requests hit cache; 40% must be retrieved from origin. This is the request hit ratio, and it is what most dashboards display by default.

Alibaba Cloud CDN distinguishes this from byte hit ratio. Request hit ratio measures the proportion of requests served from cache, regardless of file size. Byte hit ratio measures the percentage of response bytes served from cache. The formula, as Alibaba Cloud publishes it, is:

Byte Hit Ratio = (Total bytes served by CDN POPs to users - Total bytes served by origin server to CDN POPs) / (Total bytes served by CDN POPs to users)

A site can serve 90% of its requests from cache while delivering 60% of its bytes from origin. If your large video files, JavaScript bundles, and API responses miss cache, your origin still pays for every gigabyte. The byte ratio is what tracks origin traffic and cost.

The Arithmetic That Turns Hit Ratio Into Origin Traffic

Take a site serving 10 terabytes of content monthly through its CDN edge nodes. If the byte hit ratio is 70%, the origin supplies 30% of those bytes directly to the CDN nodes. That is 3 terabytes of origin egress per month.

The arithmetic is direct. The byte hit ratio denominator is total bytes delivered to end users. The numerator subtracts origin-served bytes. What remains is cache-served bytes. Invert the ratio and you have origin traffic.

The gap between request and byte hit ratio widens when object sizes vary. A thousand cached 1-kilobyte favicon requests can mask a hundred missed 50-megabyte video segments. Your dashboard shows 99.9% request hit ratio. Your origin sees 5 gigabytes per hour.

Why Hit Ratio Stays Low

Cloud CDN documentation identifies three response headers that prevent caching even on otherwise cacheable content: Cache-Control: private, Cache-Control: no-store, and Set-Cookie. The last is particularly insidious. A Set-Cookie header blocks caching entirely, regardless of MIME type or other cache directives. Many applications emit cookies for analytics, A/B testing, or session management on static assets they intend to cache.

Query strings fragment the cache key. Cloud CDN allows query strings to be omitted from the cache key, selectively included, or fully included. Each unique query string becomes a separate cache entry when included. Bunny.net documentation notes that enabling query strings in the cache key makes "each unique query string a separate file." A single JavaScript bundle accessed as /app.js?v=123, /app.js?v=124, and /app.js?v=125 becomes three cached objects instead of one.

HTTP headers in the cache key multiply copies. Cloud CDN warns that using headers in the cache key "creates multiple copies of a response based on header values." Origin servers may include configured cache-key request headers in their Vary response. Each unique header value combination occupies separate cache space.

Cookies and request headers increase "cache cardinality," in Bunny.net's phrasing, and reduce cache hit rate. The same asset requested with different Accept-Language headers, different device-type cookies, or different session identifiers fragments across the CDN's storage. Each variant expires independently. Each variant requires separate origin fetch when cold.

How to Reduce Fragmentation

The control point is the cache key. Cloud CDN's documentation emphasizes that "changing the number of unique cache keys can reduce hit rate, especially when there are many possible values." The remedy is normalization: stripping, sorting, or consolidating the inputs that define uniqueness.

Query strings are the most common source of unnecessary cache keys. Cloud CDN permits omission by default. URLs differing only by query string can share a single cache entry when the string is excluded from the key. This requires application awareness. Versioned assets must use path-based versioning (/v2/app.js) rather than query parameters (/app.js?v=2) to benefit from shared cache entries across versions.

Header-based variability demands stricter control. Each header included in the cache key expands the key space multiplicatively. Two headers with ten possible values each create one hundred possible cache variants. Bunny.net explicitly warns that variability by cookies or request headers "increases cache cardinality."

The Vary header response from origin servers compounds this. When origin includes configured cache-key headers in Vary, the CDN honors the multiplication. Audit your origin responses. Remove Set-Cookie from static assets. Consolidate cache-key headers to the minimum set genuinely required for content variation.

What the Monitoring Should Prove

Dashboards default to request hit ratio. You must configure byte hit ratio separately or calculate it from origin egress figures. A healthy change shows improvement in both metrics, but byte hit ratio is the validation that matters for cost.

Before any cache-key modification, establish baseline request and byte ratios from your provider's real-time monitoring. Alibaba Cloud's resource monitoring exposes both. After deployment, compare the same periods. Request hit ratio often recovers faster than byte hit ratio; large objects take longer to populate across the edge network.

Do not declare success from request metrics alone. A deployment that normalizes query strings should show byte hit ratio improvement within one full cache TTL cycle. If byte hit ratio stalls while request hit ratio climbs, your largest objects still miss. The origin egress bill will confirm it.

The arithmetic is unforgiving. Every point of byte hit ratio lost is origin traffic gained. Every unnecessary cache key is a cold cache slot. Your dashboard's 85% is a request ratio. Check the other number.