Cloudflare Reworks Large-File Caching to Cut CDN Waste and Speed Up Range Requests

Cloudflare has introduced Origin Range Requests, a self-service caching feature designed to deliver partial content from large files without forcing customers to configure cache-slice sizes. The change replaces a rigid, fixed-range approach with coordination built around the chunks Cloudflare already uses to store cached objects. For workloads such as video, software distribution and large model files, the redesign aims to reduce unnecessary origin transfers and improve response times.

The feature is available through Cloudflare Cache Rules on all plans. It does not change whether a response is eligible for caching, and it depends on an origin that supports HTTP byte ranges. Customers select the traffic to which it applies; Cloudflare handles the internal fetching, storage and assembly of requested data.

Why fixed-size ranges became a problem

With HTTP range requests, a client can ask for a specific section of a resource using the Range header. A video player seeking to a point in a movie, for example, can request the corresponding bytes rather than downloading the entire file. A successful response typically uses status code 206 Partial Content and includes a Content-Range header describing the returned segment.

CDNs must translate that relatively small client request into cache and origin operations. Cloudflare’s previous range-caching design divided files into configured, fixed-size segments. Small segments could produce many origin requests and increase memory pressure while the cache assembled responses. Large segments reduced request overhead but could cause the CDN to retrieve and move far more data than the client needed. Changing the configured segment size could also invalidate cached objects because the size was part of the cache key.

The trade-off became especially costly for large files and bursty workloads. A narrow request could trigger a much larger fetch, with excess bytes crossing the origin-to-edge path and potentially multiple tiers of Cloudflare’s distributed cache. At the other extreme, a small configured range could generate a queue of tiny requests. Concurrent clients could also wait on the same range operation, while earlier cache limitations prevented range caching from working effectively alongside streaming data to readers before a complete download finished.

Cache-native chunks replace customer tuning

The new implementation uses Pingora’s existing fixed-size disk-cache chunks as the basic unit of range retrieval. When a client asks for bytes, Cloudflare checks which portions are already available. It serves cached bytes directly and fetches missing data in ranges aligned to the cache’s chunk boundaries. The edge can retrieve more bytes internally than the client requested, but it returns only the requested segment downstream.

This approach does not eliminate all over-fetching: a request smaller than a chunk may still require retrieving the chunk that contains it. The difference is that the extra work is bounded by the cache’s chunking behavior rather than by a customer-selected range size that might be poorly suited to the workload. Cloudflare can also combine data already on disk with bytes fetched from upstream in one response, instead of requiring a request to be served wholly from cache or wholly from the origin.

Handling the request is more involved than a conventional cache lookup. The edge must coordinate stored bytes, data being downloaded and new origin responses, then assemble a correct response with the appropriate status and headers. When another request needs bytes covered by an in-progress fetch, it can share that work rather than initiate a duplicate origin request. That coordination can matter during traffic spikes around popular media or software artifacts.

Representation checks protect HTTP correctness

Combining different portions of an object is safe only if they belong to the same version of the representation. Cloudflare validates the ranges returned by the origin, checks that the object’s total size remains consistent and uses entity tags to guard against mixing bytes from different versions. The HTTP If-Range mechanism can require a client’s requested range to match a known validator; if it does not, the client should receive the complete representation rather than a potentially inconsistent assembly.

Content transformation adds another constraint. A byte range applies to a particular representation, so ranges over compressed data cannot simply be treated as ranges over a decompressed response. Cloudflare avoids composing partial responses when it is about to decompress the representation and instead serves the full transformed response. Correct behavior still follows HTTP semantics: satisfiable ranges receive 206 Partial Content, unsatisfiable ranges receive 416 Range Not Satisfiable, and responses that cannot safely be ranged are delivered in full.

Production results point to infrastructure savings

Cloudflare says it moved existing users of its earlier range-caching system to the new implementation, beginning with workloads that generated the most operational strain. Its object-storage service, R2, was the largest internal user and had used a 64 MiB range size. Under that configuration, a small request crossing a range boundary could result in as much as 128 MiB of data moving between cache locations.

After the migration, Cloudflare reported that R2’s p99 time to first byte fell by roughly half across storage regions, for both cache hits and misses. A subsequent improvement that allowed cached and upstream bytes to be combined in a response reduced tiered-cache traffic for R2 and similar workloads by about 6% week over week, according to the company. At CDN scale, even a single-digit percentage reduction can represent substantial capacity and network savings.

For hosting providers and businesses, the results illustrate why cache efficiency is not merely a performance concern. Unnecessary transfers consume origin bandwidth, inter-region capacity and cache infrastructure, while inefficient request patterns can increase latency precisely when demand is highest. A CDN that absorbs more of the coordination burden can also reduce the need for application teams to design around undocumented cache behavior.

Practical considerations for operators

Origin Range Requests is aimed at cacheable large objects that clients naturally access in portions: seekable video, resumable downloads, package repositories, disk images, archives and large model artifacts. It may also help clients that inspect metadata or retrieve selected regions of a larger file. Operators should first verify that the origin returns correct byte-range responses and stable validators, and confirm that the relevant files are eligible for caching under their existing rules.

Teams can enable the feature by creating a Cache Rule that matches the intended traffic and turning on Origin Range Requests, either in the dashboard or through the API. A targeted rollout is prudent: monitor origin request volume, cache-hit behavior, response latency and bandwidth across cache tiers, then expand the rule if results match expectations. The feature does not make an otherwise uncacheable response cacheable, so cache-control policy and rule precedence remain important.

Cloudflare says it intends to make the new behavior the default for certain file types, with Cache Rules available to modify its application. That direction reflects a broader infrastructure trend: CDN products are moving complexity out of customer-facing tuning controls and into the cache architecture itself. As video, software delivery and AI workloads push more multi-gigabyte objects through distributed networks, predictable range handling can improve both user experience and operational efficiency. The remaining question for operators is less about finding one ideal range size and more about measuring whether their origins, cache policies and clients are aligned for partial delivery.