How to Calculate CDN Offload Rate
CDN offload rate expresses how much of your audience demand is satisfied directly from edge caches rather than triggering expensive origin fetches. Web performance leads, FinOps teams, and SREs use the metric to quantify infrastructure savings, negotiate CDN contracts, and diagnose user experience regressions. This walkthrough builds a defensible methodology that combines cache analytics, origin logs, and service governance so your offload figures hold up under boardroom and incident review scrutiny.
We will define offload precisely, specify the variables and units needed, derive the governing relationships, and outline a rigorous step-by-step workflow for assembling the datasets. Validation, troubleshooting, and boundary conditions come next. Finally, you can embed the dedicated calculator at the end of the article to operationalise the workflow alongside related guides such as the GenAI P95 latency budget walkthrough and complementary planning tools like the Cloud SIEM log ingestion budget calculator.
Definition and analytic scope
Offload rate compares the demand satisfied by your CDN caches to the total demand observed at the CDN edge. Two related ratios are useful: request offload (cache hits as a percentage of total requests) and byte offload (cached bytes as a percentage of total egress). Both ratios focus on the CDN’s ability to prevent origin work. For clarity we treat offload as 1 − origin share, so higher is better. Inverting the ratio yields the origin hit rate, which operations teams also track for incident response.
Establish a crisp reporting boundary. Choose a contiguous observation window—daily for troubleshooting, weekly for product analytics, monthly for executive reporting—where CDN logs and origin telemetry align. Explicitly state whether requests generated by purge operations, synthetic monitoring, or health checks are included. Consistency matters more than the exact inclusion policy; document it and reuse the same boundary when comparing cohorts, markets, or releases.
Variables, symbols, and units
Treat each dataset with the precision you would apply to a financial ledger. All request counts should be integers, while byte volumes are best expressed in gigabytes (GB) for clarity, noting whether you use decimal (10³) or binary (2¹⁰) conversions. When logging vendors export in megabytes, convert to gigabytes before combining figures.
- Ntotal – Total CDN edge requests observed over the window (count). Derived from CDN analytics, log streaming, or SIEM ingestion.
- Norigin – Requests forwarded to origin (count). Many CDNs expose this directly as cache misses; otherwise infer by subtracting cache hits from total requests.
- Btotal – Total CDN egress volume (GB). Measure what users downloaded from the CDN edge.
- Borigin – Bytes fetched from origin servers (GB). Pull from origin logs or CDN origin transfer metrics. Optional but critical when payload sizes vary.
- Oreq – Request offload rate (dimensionless, expressed as percentage).
- Obyte – Byte offload rate (dimensionless, expressed as percentage).
When multiple CDNs protect the same origin, build the numerator and denominator by summing all edges. Ensure compression stages line up: if origin logs record compressed payloads, use compressed CDN egress to match apples to apples. If your CDN reports gigabytes in decimal units while your origin uses gibibytes, convert with 1 GiB = 1.073741824 GB before dividing.
Formulas and relationships
Request offload is the complement of the origin share. Byte offload uses the same logic but replaces counts with transferred volume. The two ratios highlight different operational realities. High request offload with mediocre byte offload indicates large objects repeatedly missing cache, while the inverse suggests tiny metadata calls are falling back to origin.
Oreq = 1 − (Norigin ÷ Ntotal)
Obyte = 1 − (Borigin ÷ Btotal)
Origin hit ratio = 1 − Oreq
Always confirm that Norigin ≤ Ntotal and, when byte data are available, Borigin ≤ Btotal. Any breach signals telemetry misalignment or duplicated logging. Round intermediate computations to at least four decimal places and only format percentages when presenting the final numbers to stakeholders.
Step-by-step calculation workflow
1. Select the observation window
Start by choosing a contiguous time range that matches your objective. For release verification, a 24-hour window around deployment is appropriate. For quarterly forecasting, align with billing cycles. Make sure CDN, origin, and monitoring exports all use the same timezone and daylight-saving conventions.
2. Export total demand and misses
Pull Ntotal and Norigin directly from your CDN analytics API or log pipeline. Normalise request identifiers so WebSocket upgrade handshakes, HTTP/2 push transactions, or other protocol quirks do not inflate counts. If you instrument log streaming into a SIEM, reconcile counts with the retrieval analytics workflows you already maintain for data quality.
3. Gather origin-side evidence
Validate misses against origin infrastructure. Web server logs, load balancer statistics, or origin shield dashboards provide independent verification of Norigin. Investigate discrepancies over 2–3% by drilling into cache-key behaviour, header normalisation, or purge activity. When possible, tag origin requests with CDN metadata to simplify reconciliation.
4. Capture bandwidth metrics
Collect Btotal from CDN analytics and Borigin from origin exports or CDN origin-transfer reports. Convert everything to gigabytes using consistent multipliers. Segment traffic by content type—HTML, API JSON, video—to diagnose byte-level anomalies that the aggregate offload number may hide.
5. Compute offload and origin ratios
Apply the formulas. Present both request and byte offload even if byte telemetry is incomplete, noting when the byte figure is omitted. Include confidence intervals when sampling is used: a ±1% band communicates measurement noise to stakeholders.
6. Document cache policies
Offload depends heavily on cache keys, TTLs, and invalidation strategy. Record the policies active during the window—header normalisation, cookie stripping, stale-while-revalidate behaviour—so analysts comparing later periods understand underlying causes rather than assuming origin changes.
Validation and troubleshooting
Start with a conservation check: Norigin + Nhit should equal Ntotal, where Nhit is the CDN cache hits reported separately. When byte telemetry is present, verify that Borigin roughly matches origin network interface counters or billing statements. Differences over 5% often stem from layered compression or TLS termination differences and should be documented.
Next, correlate offload with latency, error rates, and revenue using observability dashboards. Sudden offload drops accompanied by increased median latency or reduced advertising yield signal widespread cache misses that require immediate intervention. Benchmark trends alongside business metrics accessible through guides like weighted eCPM analysis to quantify downstream impact.
Limits, interpretation, and extensions
Offload is not a universal proxy for user experience. Some dynamic workloads deliberately bypass cache to ensure personalisation, keeping offload modest even when performance is excellent. Conversely, high offload with elevated error rates suggests stale or corrupted objects. Complement offload with service-level indicators such as time-to-first-byte, origin saturation thresholds, and reliability budgets.
Treat edge functions, workers, or compute primitives carefully. If business logic executes at the edge but still reaches origin APIs, count those downstream calls within Norigin to avoid overstating offload. Finally, track the cost dimension: pair offload analytics with your CDN billing reports and infrastructure expense models to translate percentage changes into dollar impact, just as you would with the embedded calculator below.
Embed: CDN offload rate calculator
Use the calculator to turn the methodology into action. Input edge and origin volumes, optionally include byte telemetry, and receive request and byte offload figures formatted for executive readouts.