- Cloudflare released Origin Range Requests on all plans. It removes the customer-set range size that could make a small file read pull far more data from the origin.
- Cloudflare reports that R2's p99 time to first byte fell by about half, and that tiered cache traffic fell about 6% after a later change.
- Teams that serve large files through Cloudflare should check their old range settings, confirm origin range support, and compare origin traffic before and after.
A tuning knob can be a design flaw
Some settings exist because the system underneath could not decide for itself. Cloudflare's old range caching was one. Customers had to pick a range size, and no single value suited every file. The lesson here is that a setting like this passes an internal limit to the customer and calls it flexibility.
What Cloudflare announced
Cloudflare announced Origin Range Requests on October 23. It is a self-service feature on all plans. Customers no longer choose a size, and nobody has to open a support ticket. A single Cache Rule switches it on.
A range request asks a server for part of a file instead of the whole file. The client sends a normal GET request with a Range header. The server answers with 206 Partial Content. Video players use this to seek, download managers use it to resume, and package managers use it to fetch part of an artifact.
Why the old setting was expensive
The earlier design mapped each client request onto fixed-size slices of a file. The slice size and the file extensions were set per customer zone. Cloudflare compares this to the slicing approach described in an nginx blog post. The size forced a bad choice. Small ranges meant many tiny origin requests and memory pressure on Cloudflare. Large ranges meant downloading far more than the client asked for.
Customers had set the value anywhere between tens of kilobytes and tens of gigabytes. Cloudflare's own comparison shows the damage at the high end. A request that "wouldn't fill a floppy disk" could trigger an origin pull of "a few DVDs' worth of data". That data could cross several data centers, sometimes after the viewer had left.
There were other costs. The size was built into each cache entry's key, so editing the setting made existing cached entries unusable. Requests that landed inside the same range could block each other.
One more limit mattered for popular files. Cloudflare built a feature that lets several clients read a file from cache while it is still being written. In the old nginx-based cache, turning that on alongside range caching cut responses short. So each range had to finish downloading before anyone could read it. A popular file then needed one origin fetch per range.
How the new version works
Cloudflare's newer cache server is built on Pingora. It already saved cached files to disk in fixed-size pieces, so that interrupted downloads are easy to resume. So the chunk became the range unit. For a range request, Cloudflare serves the bytes it already has. It fetches only the missing chunks from the origin, stores them, and returns just the bytes the client asked for.
Cloudflare gives an example. A request for bytes 150-250 may fetch the whole chunk that contains them, but the client still receives only 150-250. Small requests still cost a full chunk. What changes is predictability. The overhead now has a ceiling and no longer depends on a number a customer chose.
A coordinator combines the pieces. One request can use cached bytes, a download already in progress, and a newly fetched section. A second request can attach to an existing download instead of starting another origin fetch.
Correctness checks come with it. Cloudflare says it confirms the total file size and entity tag stay consistent across origin responses. If the version has changed, it returns the full file rather than mixing bytes from two versions. It also skips range composition for content it is about to decompress and serves the full response instead.
What Cloudflare reports, and its limits
R2, Cloudflare's object storage, was the largest internal user of the old feature. Its setting was 64 MiB. A small read that straddled a boundary between two ranges could move 128 MiB between data centers.
Once R2 ran on the new implementation, Cloudflare measured p99 time to first byte at roughly half its earlier level. That is the wait that 99% of requests beat. Cloudflare reports the drop across R2's storage regions, for both cache hits and misses.
A later change let the coordinator mix bytes on disk with bytes fetched upstream in one response. After enabling it for R2, Cloudflare saw traffic between cache tiers for R2 and similar workloads fall about 6% over the previous week. It describes that as petabytes less data moving between its data centers every day.
These are Cloudflare's own measurements on its own workloads. The post does not publish results from customer traffic. The feature also does not make an uncacheable response cacheable, and the origin must support byte ranges.
Questions to put to your team
Do we serve large files, such as video, installers, disk images or AI model files, through Cloudflare? If so, did anyone set a range size years ago and forget it?
Does our origin support byte ranges? Without that, partial fetches will not help.
Can we enable the feature on one Cache Rule and compare origin traffic and time to first byte before and after? Cloudflare also says it intends to make this the default for certain file types, so ask which ones.
The broader point is simple. When a vendor's setting exposes its internal limits, the best fix is often to remove the setting, not to document it better.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
