No More Range Tuning! Origin Range Requests Halve R2 p99 Latency

Hi, it's Shiichan!

Cloudflare Blog blog.cloudflare.com

Ever fetched just a slice of a big file while hundreds of megabytes moved behind the scenes? I read a Cloudflare post about cutting that waste.

What was announced?

Cloudflare's blog introduced Origin Range Requests. It reworks how range requests for large files are cached, using a redesigned Pingora cache architecture, so you no longer need to tune a range size.

The story so far

The previous range caching mapped client requests to fixed-size ranges, with the size set per zone. That caused several problems:

• Wasted origin bandwidth: R2's range size was 64 MiB, so a small read crossing a boundary could cost up to 128 MiB of transfer between data centers
• A poor trade-off: small ranges meant many tiny origin requests holding memory, while large ranges meant downloading much more than needed
• Fragile configuration: the range size was part of the cache key, so changing it invalidated cache entries
• Blocking: concurrent requests in the same range could block each other, even when their byte ranges were far apart
• Feature conflicts: combining range caching with concurrent streaming cut responses short

The extra bytes added up at every hop: origin to data center, between cache tiers, and on to the client.

What changes

You no longer configure a range size. R2's p99 time to first byte dropped by roughly half on both cache hits and misses across storage regions.

Tiered cache traffic for R2 and similar workloads also fell about 6% week over week. Cloudflare says that equals petabytes less data moving between data centers each day.

Dive Deep

How it works

Pingora already stored cached files on disk in fixed-size chunks, which makes resuming interrupted downloads easy. Cloudflare reused that chunk as the range unit.

For each range request, the edge coordinates several sources:

• Lookup: read asset headers and range-coverage metadata
• Serve cached bytes: read from disk or in-memory streams
• Fill gaps: fetch missing data from the origin using chunk-aligned ranges
• Store: write new chunks and record completed ranges in metadata
• Respond: combine the pieces and set Content-Range and Content-Length for only the requested bytes

If an in-flight download already covers part of a request, the new request attaches to it instead of starting another origin fetch, which helps with bursts for popular files.

Validation

The coordinator checks that composed responses are correct:

• Each origin response matches its requested range
• Total asset size stays stable
• The ETag stays consistent across subrequests
• If-Range is honored, so bytes from different versions are never mixed
• Ranges are not composed for content that will be decompressed, because byte offsets differ; the full transformed response is served instead

Responses follow standard HTTP: 206 for satisfiable ranges, 416 for unsatisfiable ones, and the full representation when ranging isn't safe.

Trade-offs and usage

• Requests smaller than a chunk may still fetch the whole chunk
• Non-aligned ranges require more work
• Cloudflare considers the extra work bounded and predictable

It's a self-service feature on all plans. Enable it with a Cache Rule in the dashboard, or in the API with:

origin_range_requests: { "mode": "on" }

It doesn't make uncacheable responses cacheable, and the origin must support byte ranges for partial fetches to help. Cloudflare plans to make it the default for certain file types, configurable through cache rules.

Wrap-up

• Using Pingora's chunk as the range unit removes the need to configure a range size
• R2 p99 TTFB roughly halved, and tiered cache traffic fell about 6%
• Checks like ETag and If-Range prevent responses that mix versions
• Enable it on any plan with a Cache Rule (the origin must support Range)

If you serve video, large files, or R2 objects with seeking, this one is worth trying!