Web performance
A partial download needs a compatible origin, not just a cache rule
When someone seeks within a video or resumes a download, the client needs part of a file. To evaluate a CDN change, follow the bytes between client, cache and origin rather than judging it by one page-load test.
Cloudflare's 23 October announcement makes Origin Range Requests self-service through Cache Rules on all plans. It changes origin fetching to cache-aligned ranges; the client still receives its requested bytes. Reported performance results describe Cloudflare's workloads, not a saving demonstrated for your site. (Cloudflare)
The settings documentation says the option does not itself make content cacheable, complete-object size limits still apply and an origin returning 200 to a range request may require a full download. Cache Reserve is not supported. Check eligibility and origin behaviour before enabling it. (Cloudflare)
Follow one seek through the system
Suppose a training-video viewer jumps to the middle. The downstream request asks for a byte interval. The edge may already hold some bytes and need to fetch others; a partially cached object is therefore different from a completely warm file. Testing only the second full download can hide the origin work that matters.
Illustrative HTTP exchange, not a captured measurement:
Range: bytes=1000-1999
HTTP/1.1 206 Partial Content
Content-Range: bytes 1000-1999/10000
Content-Length: 1000A plausible status code is not enough. Check the actual bytes, range boundaries and complete-object identity. An incorrect segment can make a download unusable even when latency looks good. Content that changes under a stable URL needs a deliberate versioning or invalidation strategy.
A compatibility checklist before a performance test
- Check how the origin responds to supported ranges and to a request it cannot satisfy.
- Verify length and content-range information against the real object.
- Check validators such as ETags and how updates invalidate cached data.
- Confirm the handling of authentication, signed access and content that must remain private.
- Restrict the rule to a small, appropriate set of objects and retain a way to remove the override.
Do not interpret a range-fetching optimisation as permission to cache a personalised export. Access rules, cache eligibility and storage duration are separate decisions. Test an authorised and an unauthorised request when validating private delivery, using synthetic data rather than real customer exports.
Compare workloads, not headlines
| Case | What to observe |
|---|---|
| Cold initial request | Client latency, origin bytes and origin request count |
| Seek into an uncached section | Returned byte correctness and additional origin work |
| Repeated seek | Cache reuse and any repeated origin transfer |
| Interrupted/resumed download | Correct reconstruction of the complete file |
| Updated object | Correct invalidation and absence of mixed old/new bytes |
Keep object versions, client location, network conditions and the requested ranges comparable. Record whether the cache was cold, partially populated or warm. Report distributions and sample counts from your own test instead of borrowing the provider's headline improvement.
Make the decision on total work
Origin traffic, request count, storage operations and failed playback all matter. A faster first byte can coexist with more origin requests, and the financial effect depends on the provider's actual billing and workload. This article supplies a test design, not measurements, a cost estimate or a promise of lower bandwidth charges.
A web or e-commerce project can include that delivery check when large public assets form part of the user journey. Keep it a scoped optimisation after correctness and access control are established.
Sources
- Origin Range Requests: Serving large files without range-request tuning — Cloudflare · 2026-10-23
- Cache Rules settings — Cloudflare