Cache efficiency is the single most important indicator of CDN value. If your CDN is not serving the majority of traffic from edge memory or SSD, you are paying for transit, adding origin load, and delivering slower experiences. Yet many teams track only a single number — request hit ratio — and miss the full story. A complete analysis requires three complementary metrics: request hit ratio, byte hit ratio, and origin offload.
This guide breaks down how each metric is calculated, what good looks like in production, and how to diagnose and fix efficiency gaps. Whether you are auditing a new provider or tuning an existing CDN implementation, these fundamentals will help you reduce origin egress by 80% or more.
Why Cache Efficiency Defines CDN Performance
Every cache miss has a cost. The edge must establish a connection to origin or shield, wait for the first byte, stream the response, and then store it — adding 80-300ms of latency versus a 5-15ms cache hit. At scale, that latency compounds into slower Largest Contentful Paint, higher Time to First Byte, and degraded Core Web Vitals.
Efficiency also directly drives cost. Most origins pay for egress bandwidth, compute autoscaling, and database reads. A CDN with 95% byte offload turns a 100 TB/month origin bill into 5 TB. For video, software downloads, or image-heavy e-commerce, the savings alone justify the CDN investment.
Finally, efficiency is resilience. During traffic spikes or origin failures, a high hit ratio allows stale-while-revalidate and stale-if-error to serve users without contacting origin. Understanding how DNS resolution routes to the optimal edge is important, but without effective caching at that edge, routing is wasted.
The Three Core Efficiency Metrics
Teams often use these terms interchangeably, but they measure different things. You need all three for an accurate picture.
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
1. Cache Hit Ratio (Request Hit Ratio)
The classic metric. It answers: What percentage of requests were served from cache without contacting origin?
Hit Ratio = ( cache_hits / (cache_hits + cache_misses) ) * 100
# Example: 92,500 hits / 100,000 requests = 92.5%
It is useful for understanding request volume and edge CPU utilization, but it treats a 2KB API hit and a 40MB video miss equally. That is why it can be misleading.
2. Byte Hit Ratio (Bandwidth Hit Ratio)
Byte hit ratio weights by size. It answers: What percentage of bytes delivered to users came from cache?
Byte Hit Ratio = ( bytes_from_cache / total_bytes_delivered ) * 100
# Example: 850 GB from cache / 1000 GB total = 85%
This is the financially relevant metric. If your byte hit ratio is 85% while request hit ratio is 95%, your largest objects are not caching effectively. For media workloads, byte hit ratio is the primary KPI.
3. Origin Offload (Origin Shield Efficiency)
Offload measures protection at the origin, including tiered or shield caches. While hit ratio is measured at the edge, offload is measured at the origin.
Request Offload = (1 - origin_requests / edge_requests) * 100
Byte Offload = (1 - origin_bytes / edge_bytes) * 100
# With shield: Edge 90% hit + Shield 70% of misses = ~97% total offload
Offload will always be equal to or higher than edge hit ratio when you use an origin shield or tiered caching strategies. If your provider reports 92% hit ratio but 96% offload, that 4% delta is the shield absorbing misses.
Benchmarks: What Good Looks Like
Benchmarks depend heavily on content type. Use this table to set realistic targets and identify underperformance.
| Metric | Formula | Healthy Target | Diagnosis If Low |
|---|---|---|---|
| Request Hit Ratio | hits / (hits+misses) | 90–98% static 75–85% dynamic |
Short TTLs, cache-key fragmentation, cookies, no-cache headers |
| Byte Hit Ratio | cache bytes / total bytes | 85–95% media 80–90% mixed |
Large objects bypassing cache, range requests, uncached video |
| Origin Request Offload | 1 - (origin req / edge req) | 95–99% with shield | Shield disabled, cache stampede, purge frequency too high |
| Origin Byte Offload | 1 - (origin bytes / edge bytes) | 92–98% | Origin serves large uncacheable payloads, missing compression at edge |
If you are tracking core CDN performance metrics, correlate hit ratio with TTFB. A healthy deployment shows TTFB < 50ms at p50 for hits and 150-300ms for misses. A wide gap validates that caching is working.
Calculating Metrics From Logs and APIs
Most CDNs expose hit/miss via response headers (X-Cache: HIT, CF-Cache-Status, Age) and via log fields. Do not rely on sampled dashboards alone — calculate from raw logs for accuracy.
# Example: Calculate hit ratio from CDN access logs (JSON lines) import json from collections import Counter hits = misses = bytes_hit = bytes_total = 0 with open("cdn_logs.jsonl") as f: for line in f: r = json.loads(line) status = r.get("cache_status") # HIT, MISS, REVALIDATED, BYPASS b = r.get("bytes_sent", 0) bytes_total += b if status == "HIT": hits += 1 bytes_hit += b elif status in ("MISS", "BYPASS"): misses += 1 hit_ratio = hits / (hits + misses) * 100 if (hits+misses) else 0 byte_ratio = bytes_hit / bytes_total * 100 if bytes_total else 0 print(f"Hit Ratio: {hit_ratio:.2f}% | Byte Hit Ratio: {byte_ratio:.2f}%")
For real-time analysis, query your CDN analytics API grouped by cache status and content type. Segment by content-type, uri_path, and cache_status to find which asset classes drag efficiency down.
# Cloudflare GraphQL / Fastly / Akamai examples - pseudo-SQL SELECT cacheStatus, COUNT(*) AS reqs, SUM(bytes) AS bytes, SUM(bytes) * 100.0 / SUM(SUM(bytes)) OVER () AS pct_bytes FROM cdn_requests WHERE timestamp > now() - 7d GROUP BY cacheStatus ORDER BY bytes DESC;
Optimizing Cache Efficiency: 5 High-Impact Fixes
After auditing hundreds of domains, these interventions consistently deliver the largest gains:
1. Normalize Cache Keys
Query string disorder and marketing parameters fragment the cache. /product?id=123&utm_source=google and /product?utm_source=google&id=123 should be one key. Strip utm_*, fbclid, gclid at the edge and sort remaining params. This alone can recover 8-12% hit ratio on e-commerce sites.
2. Use Versioned URLs with Immutable TTLs
Set Cache-Control: public, max-age=31536000, immutable for fingerprinted assets like app.a3f7c9.js. Pair with short TTLs (60-300s) for HTML. This pattern maximizes byte hit ratio because large JS/CSS bundles never revalidate.
3. Enable Origin Shield and Tiered Caching
Without a shield, each of your 300+ edge POPs fetches misses independently. A shield collapses those 300 origin fetches into one. Providers typically offer a single shield region or smart tiering — enable it closest to origin. Expect a 2-5% lift in offload immediately.
4. Cache More Than You Think
Cache 404s for 10-30 seconds to absorb scanners, cache 301 redirects for hours, and consider caching API responses with stale-while-revalidate=60 for anonymous users. Even a 30-second TTL on an API that receives 500 RPS prevents 15,000 origin hits per minute.
5. Fix Origin Headers
A single Set-Cookie or Vary: Cookie or Cache-Control: private, no-store from origin will force a bypass. Audit origin responses and strip unnecessary cookies at the edge for static assets. Ensure Vary only includes Accept-Encoding where needed.
For a deeper implementation checklist, see our guide to CDN architecture and tiered cache design.
Monitoring and Alerting
Track hit ratio and byte hit ratio as time series, not daily averages. Alert on:
- Sudden drop >5% for 10 minutes — likely a bad deploy, purge, or origin header change.
- Byte hit ratio diverging from request hit ratio — indicates large object bypass.
- Origin request rate spike — cache stampede after TTL expiry; implement request collapsing.
- Shield miss ratio increase — shield eviction or region failure.
Export metrics to your observability stack and overlay deployments and purges. The best teams annotate every cache purge with a reason and measure its efficiency impact in the following hour.
Cache efficiency is not a set-and-forget metric. Content changes, traffic patterns shift, and new query parameters appear. A monthly audit of the top 20 cache misses by bytes will almost always surface easy wins. Start with byte hit ratio, fix the largest misses first, and the request hit ratio will follow.