Cloudflare rebuilds range-request caching, halves R2 latency
Origin Range Requests replaces a manually tuned range size with fixed cache chunks, cutting p99 time to first byte roughly in half for R2 on cache hits and misses.
Cloudflare published a rebuild of how its cache handles HTTP range requests on 23 October, called Origin Range Requests. The old nginx-based setup mapped every range request to a single configurable size that also doubled as the cache key, so a 64 MiB range setting could turn a small read into 128 MiB of cross-datacentre transfer. Get the size wrong and you paid for it on every request.
The new version, built on Cloudflare’s Pingora proxy, uses fixed-size cache chunks instead, with no size to tune and no support ticket needed to turn it on. It is self-service on all plans: a Cache Rule with origin_range_requests set to on. For R2, Cloudflare’s own object storage, p99 time to first byte dropped by about half on both cache hits and misses. A follow-up change that merges cached and freshly fetched bytes into one response cut tiered cache traffic for R2-like workloads by roughly 6% week over week.
Cache Rule: origin_range_requests = onWhy it matters: anyone serving large files, video, or object storage through Cloudflare’s cache has likely spent time hand-tuning a range size or just accepted the wasted bandwidth. This removes that tuning step and the main failure mode behind it, with a concrete latency win on R2 specifically.