Origin offload is a reduction in upstream work. Request count, transferred bytes, and application CPU describe different parts of it.

Bytes and requests

Compare origin bandwidth, request rate, and worker utilization under equivalent traffic. Reusable content can move off the application path, while private and unique work remains at origin.

The delivery model

How it works

Origin offload

  1. 01Edge hitsServe eligible stored responses without a body fetch.
  2. 02Shield reuseReduce repeated upstream fills where supported.
  3. 03Origin workMeasure the requests and bytes that remain.
Conceptual model for this configuration. The actual path depends on provider policy and application behavior.

Hide the origin

If clients can still hit the origin IP, offload is optional. Restrict origin to Cloud CDN pull and validate TLS.

Workers versus disks

WordPress and Laravel offload CPU. VOD and installers offload disks and egress. Both are origin offload; the cache policy differs.

Serve-stale is offload during failure

When origin is down, eligible stale objects keep the site up. That is offload you only notice on a bad day.

Validate before production

Compare origin access logs, egress, worker utilization, and error rates across equivalent traffic periods. Include revalidations and retries. Do not infer a hosting cost reduction from edge hit ratio alone; use the actual billing and capacity model.

  • Record the configuration and expected result before changing traffic.
  • Keep evidence of the test and a working rollback for the previous behavior.

Sources & further reading