Drag a video player's timeline halfway through a movie and you are asking for a small piece of a large file. Somewhere behind that gesture, a cache has to decide how much data to fetch. Get that decision wrong and a modest seek becomes a surprisingly expensive network operation.

In its October 23 engineering post, "Origin Range Requests: Serving large files without range-request tuning," Cloudflare describes an old R2 configuration that fetched 64 MiB ranges. A small read across a boundary could require 128 MiB of transfer. Its replacement uses the cache's own fixed-size chunks and coordinates cached, in-flight, and missing bytes.

Cloudflare reports roughly halving R2's p99 time to first byte after the change. A later improvement reduced tiered-cache traffic for R2 and similar workloads by about 6%. Those are observations from its deployment, not a forecast for every origin.

The useful question is how much work the system performed to deliver the bytes somebody actually wanted.

A Small Request Can Have A Large Footprint

HTTP range requests let a client ask for part of a representation. A successful single-range response uses 206 Partial Content and describes the returned interval in Content-Range. Byte positions are zero-based and the final position is inclusive.

GET /archive.bin HTTP/1.1
Host: files.example
Range: bytes=8388608-9437183

HTTP/1.1 206 Partial Content
Content-Range: bytes 8388608-9437183/1073741824
Content-Length: 1048576
An illustrative request for one MiB beginning eight MiB into a one-GiB object. The client does not need the preceding bytes.

That is the client-facing contract. Internally, a cache might read more than it returns. Fetching adjacent bytes can be sensible if the next request will need them, or if each upstream operation carries a substantial fixed cost.

The risk is assuming that every access pattern benefits from the same amount of read-ahead. A viewer watching continuously, a viewer scrubbing through ten positions, and a downloader resuming one interrupted transfer are making different bets on what comes next.

Consider a separate, simplified example. A cache fetches four-MiB blocks. A client asks for one MiB split evenly across a boundary between two blocks, with neither block cached. The cache might fetch eight MiB to return one MiB. That is eight times as much upstream data as useful response data for this request. Future reuse could justify the extra bytes, but a viewer who immediately leaves provides no such reuse.

Measure Bytes Alongside Requests

A dashboard showing a high request hit rate can conceal expensive misses. A hundred tiny requests served from cache do not necessarily compensate for one miss that pulls a large object nobody finishes reading.

For range-heavy traffic, I would add a byte-amplification measure to the usual latency and hit-rate charts:

origin byte amplification =
    bytes fetched from origin
    / useful bytes delivered to clients
Evaluate a defined workload over a defined interval. Cache warming and later reuse can change the ratio substantially.

This is an editorial diagnostic, not a Cloudflare billing metric. It helps ask whether an apparently efficient request path is moving unnecessary data. Track it separately for cold reads, warm reads, sequential downloads, and random seeks.

The interval matters. One request may pay to warm data that serves thousands of later readers. A short test can call that waste when it is useful prefetching. Conversely, a long aggregate can hide a bad path behind a very popular file. Keep both the workload breakdown and the aggregate.

Concurrency Can Change The Answer

Imagine a tutorial becoming popular just as a class begins. Many students open the same video, then seek to different chapters. Some requested bytes may already be on disk. Some may be arriving. Others may need a fresh origin fetch.

A good evaluation should test whether the system shares useful work without making unrelated readers wait behind it. A single sequential download on an empty test cache cannot reveal that behavior.

Run a small burst against the same interval, then another burst against widely separated intervals. Compare origin requests, transferred bytes, tail latency, and errors. Repeat with a partially warm cache. The goal is to understand how the service behaves as readers overlap, rather than assume one fast download represents the workload.

Cloudflare's implementation still fetches whole chunks for smaller reads; it does not claim zero overfetch. The product removes customer-selected range sizing and makes the coordination the cache's responsibility. It is available through Cache Rules on all plans, while ordinary cache eligibility still applies and the origin needs byte-range support for useful partial fetches.

Correct Bytes Beat A Fast Response

A partial response needs to belong to one coherent version of the file. RFC 9110 defines If-Range so a client can condition a range request on a validator. If the condition does not hold, the server can send the full representation instead. An unsatisfiable range can receive 416 Range Not Satisfiable.

For an application owner, the practical test is to replace a file while clients are reading it. Use clearly distinguishable test content, preserve validators, and check that clients receive a coherent result. A fast response assembled from incompatible versions is still a failure.

Immutable object names can simplify this experiment and production behavior. Publish a new version under a new identifier, then update the manifest or page pointing to it. The application can retain a precise relationship between the requested object and its expected contents.

Try It On A Workload You Can Explain

Start with a narrow set of large, cacheable assets. Keep a baseline and compare the same read sequence before and after changing cache behavior.

  • Request a short interval near the beginning, middle, and end of a file.
  • Read across likely storage boundaries and compare origin traffic.
  • Repeat intervals to distinguish cold misses from useful reuse.
  • Send concurrent overlapping and non-overlapping requests.
  • Cancel reads and observe whether upstream work continues.
  • Replace the test object and check validators and returned content.
  • Compare p50 and p99 latency, errors, origin bytes, and completed client bytes.

These tests are proposed operating checks, not claims of defects in the new feature. They make the result specific enough to evaluate. A media archive, a package repository, and a model-artifact service can all use partial reads while producing very different request distributions.

A Better Default Has A Measurable Job

The interesting part of this change is how it reduces the amount of internal cache behavior an application owner has to tune. That is a useful direction for infrastructure: a service can expose the traffic-selection decision while taking responsibility for the mechanics beneath it.

Operators still need evidence. Does the viewer get the requested segment quickly? Does the origin do proportionate work? Do bursts share data effectively? Do updates preserve correctness?

A small seek should be a small job often enough that the measurements show it. That is a more useful performance target than a cache-hit percentage on its own.

Sources