Every request your origin serves costs compute, connections and headroom — and a well-configured edge can eliminate most of them without touching a single TTL. Cache tuning gets the attention, but between the edge and your origin sit three quieter families of relief: deduplicating the fetches that happen simultaneously, making each fetch cheaper, and reducing how many locations fetch at all. Together they routinely cut origin traffic by multiples, which is capacity you don't have to buy.
Measure the load before shrinking it
Origin load has a precise definition from the edge's side: the miss, pass and revalidation traffic in your logs, countable per path, per hour. Baseline three numbers before changing anything — origin requests per second at peak, origin bandwidth, and origin connection count (this one lives in your origin's own metrics) — because the three levers in this guide improve different ones, and "did it work?" should be arithmetic, not atmosphere. While baselining, run the ratio that motivates everything: origin requests divided by edge requests. That is the fraction of your traffic the CDN currently forwards; the rest of this guide is about shrinking it and softening what remains.
Request collapsing: dedupe the stampede
When a popular object expires and two hundred requests arrive in the same second, a naive cache forwards two hundred identical fetches — the thundering herd, and the mechanism behind most "origin fell over at cache expiry" incidents. Request collapsing (coalescing) fixes it: the first miss goes to origin, the other hundred and ninety-nine wait for that single response and share it. Most platforms collapse by default for standard cacheable content, but verify rather than assume, and know the boundaries: collapsing typically applies per-POP (two hundred requests across forty POPs still means up to forty fetches — the shield in section four fixes that), and it can't help content marked uncacheable. The log signature of missing collapse is unmistakable: bursts of simultaneous identical misses for one URL. Pair collapsing with serve-stale and expiry stops being an event at all: one background fetch refreshes while everyone is served the previous version.
Keep-alive: cheaper fetches
Each origin fetch that opens a fresh connection pays TCP setup and a TLS handshake before the request even starts — expensive for the origin (handshakes are CPU) and slow for the user waiting on the miss. Persistent connections between edge and origin amortize that cost across many fetches. Most CDNs maintain keep-alive pools by default, but the origin side is where it breaks: verify your origin (and any load balancer in front of it) allows generous connection lifetimes and per-client request counts, that idle timeouts on the origin side are longer than the edge's (the wrong order causes connection churn and intermittent 5xx noise), and that TLS session reuse works on the origin leg too. The measurable result is origin connection counts and handshake CPU dropping while request counts hold steady — and miss-path latency improving for free, since users stop paying setup time inside their TTFB.
Shields and hierarchy: fewer fetchers
Collapsing dedupes within a POP; a shield dedupes across them. Designate one location (ideally near your origin) as the intermediary, and edge misses worldwide converge there — the shield fetches from origin once and feeds every POP. Your origin's effective client population drops from the provider's whole map to a handful of shield machines with warm connections: fewer unique fetchers, higher combined hit ratio, and a stable IP set that simplifies origin firewalling. The shield guide covers configuration, billing quirks and the extra-hop trade-off in depth; in this guide's terms, the shield multiplies the other two levers — collapse happens again at the shield tier, and the shield-to-origin connections are the most keep-alive-friendly in the whole system because all fetches share them.
Conditional revalidation and the compound effect
The gentlest origin request is one answered without a body: when the edge revalidates an expired object and your origin supports validators (ETag or Last-Modified), an unchanged object earns a bodiless 304 instead of a full 200 — near-zero bandwidth and minimal compute, at full cache-freshness. Confirm your origin actually emits validators and handles conditional requests; frameworks frequently don't by default, and the fix is a middleware, not a project. Then stack everything and re-measure the baseline: revalidation makes expiries cheap, collapsing makes them singular, the shield makes them local, keep-alive makes them fast. Estates that apply all four typically watch origin request rates fall to a small fraction of edge traffic — at which point spike planning changes character, because the origin the spike must survive has become a much smaller target.