Cloudflare Introduces Origin Range Requests to Cache Parts of Large Files
Cloudflare has introduced Origin Range Requests to cache parts of large files. Available on all plans, the feature roughly halved R2’s p99 time to first byte after the migration, according to the company.
On October 23, 2026, Cloudflare introduced Origin Range Requests, a new way to cache partial downloads of large files. According to The Cloudflare Blog, the feature is available on all plans. Teams can enable it for the relevant traffic with a Cache Rule, without choosing a range size. After R2 switched to the new implementation, its p99 time to first byte fell by roughly half, according to the company.
Why the old cache fetched more than it needed
When you seek through a video, the player may request only a small part of the file. To do that, the client sends an HTTP request with a Range header; if the server can provide the requested bytes, it responds with 206 Partial Content. Range requests are also used to resume large downloads. We wrote separately about a similar browser-side scenario.
Cloudflare’s previous system mapped a client request to fixed-size ranges configured for the zone. A large range forced the CDN to fetch far more bytes from the origin than the client needed. A small one generated many origin requests and increased memory use when coalescing requests. Changing the setting also made old cache entries unusable: the range size was part of the cache key.
There were limits on concurrent access to a file, too. Requests for different parts of the same range could block one another. The nginx-based cache could not combine this approach with serving a file while it was still being written to the cache. And the extra bytes did not travel only from the origin: they could also move between tiers of the distributed cache.
R2’s old range size was 64 MiB. As a result, a small read across a range boundary could transfer 128 MiB between data centers. That is quite a journey for a request for a few bytes.
How Pingora assembles a partial response
The move to a Pingora-based caching server made it possible to build on the existing storage model: files on disk are split into fixed-size chunks. Cloudflare checks which requested bytes are already available, then fetches the missing ones from the origin in ranges aligned to chunk boundaries. The client receives only the bytes it asked for.
A single response can draw on data from disk, a download already in progress, and a new origin request. If a download already underway covers the bytes a second client needs, that client can join it. This avoids fetching the same part again when a popular file receives concurrent requests.
Before assembling the parts, the system checks the origin response, object size, and ETag: the bytes must belong to the same representation. If an If-Range condition is not met, Cloudflare serves the full object rather than a mix of versions. It also returns a full response when decompression makes it impossible to fulfill a range request correctly. A satisfiable request receives a 206; an unsatisfiable range receives a 416.
Fetching more than requested is still sometimes necessary: a small request may require a whole chunk. But the excess is now bounded by the cache chunk size, not by a range size set by the Cloudflare customer in the zone settings. After R2 migrated, p99 time to first byte fell by roughly half for both cache hits and misses. Further improvements to assembling responses from cached data and data from an upstream node reduced traffic between cache tiers by about 6% over a week for R2 and similar workloads.
What sites with large files should do
The feature is intended for cacheable objects whose parts clients request separately: videos with seeking, resumable downloads, software packages, archives, disk images, and model files. Site teams select that traffic in Cache Rules and enable Origin Range Requests through the Caching > Cache Rules dashboard or the API. There is no need to contact support or configure a range size.
The rule does not, however, make an uncacheable response cacheable. The origin must support byte-range requests for partial requests to be useful. Cloudflare plans to make the new approach the default for certain file types, with the option to change the behavior through cache rules, but has not given a timeline.
My take: the setting is now where it belongs
I like that the dashboard no longer asks you to choose between “too many requests” and “too many bytes.” Cloudflare customers no longer have to guess at a range size that works for both a quick seek and a long download. When a small request sends 128 MiB wandering between data centers, that flexibility looks a little overrated.
For a site with video or large downloads, I would still start by checking whether the origin supports ranges, whether the responses are cached, and how much data actually moves in real use. The R2 results show the effect on Cloudflare’s workload; they do not promise the same speedup for every site. Speed is best discussed with measurements—“it feels faster to me” is not a metric yet.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
- Origin Range Requests: Serving large files without range-request tuning blog.cloudflare.com
lead front-end developer
I optimize the front end of large web apps and help teams avoid sending users unnecessary kilobytes. I like debating speed using the profiler, not the feeling of “it’s fast on my machine.”
All posts by the authorRelated articles
A Firefox Setting Helped the Author Resume Large Downloads
The author found that changing network.http.response.timeout helped him resume interrupted large downloads in Firefox. It’s an experimental tip, and resuming also depends on server support.
Rampart Open-Sourced for Local Removal of Personal Data from Messages
Rampart checks messages in the browser and replaces detected personal data with labels before sending them to a chat service. The project has been released as open source in alpha.
Cloudflare Adds CPU and Memory Profiling for Workers and Durable Objects
Cloudflare has introduced CPU and memory profiling for Workers and Durable Objects in production. Developers can explore interactive flamegraphs to find functions consuming resources.
Discussion 4
Mariam Nersisyan
On a video project I worked on, seeking often meant the CDN fetched much more than the player needed, so users saw a pause even though only a small byte range was requested. With this kind of caching, I’d test a few real seek patterns and watch whether the first byte arrives sooner without making repeat requests harder to serve.
Salla Lehtinen
That’s a useful test case: the key is whether the CDN can fetch and cache the requested byte range without pulling in a much larger fixed-size chunk. I’d compare first-byte time on seeks with repeat-seek cache hits, since the article says Cloudflare’s new approach avoids choosing a range size in the Cache Rule.
Martin T.
Exactly—the repeat-seek cache hit is where the “no range size to tune” claim needs to earn its keep. I’d include seeks that overlap only partly too; caches love turning neat test cases into paperwork.
Bruno Mateo
one thing worth checking during rollout is that validators like ETag stay consistent across partial responses, especially if the origin can replace a large file in place