Cloudflare's Origin Range Requests end the 128 MiB pull behind a few-megabyte video seek
Cloudflare rebuilt range caching on Pingora's disk chunks, dropping customer-set range sizes and halving R2's p99 time to first byte.
OddBrief EditorialAI-assisted, human-reviewed
TechKey facts
- Who
- Cloudflare, in an October 23 blog post
- Before
- a few-megabyte seek could trigger a 128 MiB origin pull
- Result
- R2 p99 time to first byte roughly halved
- Availability
- self-service on all plans via Cache Rules
Cloudflare has rebuilt how its cache handles partial file requests, and the old behavior it is replacing was strikingly wasteful. Under the previous design, jumping a few megabytes ahead in a video could trigger a 128 MiB fetch from the customer's server, the company said in an October 23 post introducing Origin Range Requests, now self-service on all plans.
For R2, Cloudflare's object storage, the change roughly halved p99 time to first byte on both cache hits and misses, according to the post.
Why a small seek got so expensive
Range requests let a client fetch part of a file, for a video seek or a resumed download. Cloudflare's older nginx-based system split files into fixed-size ranges that each customer had to configure, from tens of kilobytes up to tens of gigabytes.
Both ends hurt. Small ranges meant many tiny origin requests holding memory while they waited. Large ranges meant downloading far more than anyone asked for, sometimes after the viewer had already left. R2 used 64 MiB ranges, so a small read that crossed a boundary could cost 128 MiB of transfer between data centers, and the waste repeated at every hop.
The range size was also part of the cache key, so changing it threw away cached content. Range caching could not be combined with concurrent streaming either: each range had to finish downloading before anyone could read from it.
Reusing chunks that already existed
The fix leans on something Cloudflare's newer Pingora-based cache already did. To support resuming interrupted downloads, it stores files on disk in fixed-size chunks. The team made those chunks the unit for ranges, which removed the customer setting entirely.
Now the edge serves whatever bytes it already holds, fetches only missing chunk-aligned pieces from the origin, and returns just the requested bytes. If another download is already pulling the needed bytes, a new request attaches to it instead of starting a second origin fetch. Checks on content length, ETag and If-Range keep a response from mixing two versions of a file.
After a follow-up change that let responses combine bytes from disk and from upstream, traffic between Cloudflare's cache tiers for R2 and comparable jobs dropped about 6% from one week to the next, which Cloudflare says works out to petabytes less data moving each day.
The limits
A request smaller than a chunk can still fetch the whole chunk. The origin has to support byte ranges for any of this to help, uncacheable responses stay uncacheable, and compressed or transformed content is served in full. Cloudflare does not mention pricing.
It is switched on through a Cache Rule today. Cloudflare says it intends to make the feature the default for certain file types, without saying which or when.
Sources
- Origin Range Requests: Serving large files without range-request tuningCloudflareprimary source
- Range requestsCloudflare Docs