Cloudflare has built a prototype that compresses cached text content before writing it to disk, and the company estimates it could unlock petabytes of additional effective cache capacity across its network. The approach, which the team calls Cache Transcoding, uses Zstandard to compress eligible responses once when they enter the cache and decompress them on the way out, trading a modest amount of CPU for substantial storage and bandwidth savings.
What gets compressed and what doesn't
The system targets a specific slice of cached content: uncompressed text responses that are at least 4 KiB, returned with a successful status code, and contain compressible data. HTML, JSON, CSS, and JavaScript all qualify. Images, video, and fonts are excluded because they're almost always already compressed, and re-encoding them would burn CPU cycles for negligible benefit.
This filtering matters. In Cloudflare's traffic sample, media accounted for 21.4 percent of requests but 63.3 percent of total bytes. Compressible text made up 67.3 percent of requests and 22.3 percent of bytes. Of that text content, roughly 71 percent arrived uncompressed, meaning the vast majority of cacheable text responses could benefit from compression without any changes to origin servers.
The 4 KiB threshold is a deliberate tradeoff. Cloudflare estimates that applying it sacrifices only about 1 percent of eligible data while avoiding the overhead of processing large numbers of small objects. Both the threshold and the Zstandard compression level can be tuned based on the balance between CPU availability and storage pressure at any given data center.
One-time cost, recurring savings
The core insight behind Cache Transcoding is that the compression cost is paid once, when an asset enters the cache, while the storage and bandwidth savings compound every time that asset is served. Zstandard is well-suited to this use case because it was designed for real-time compression at Facebook scale, offering a strong ratio-to-speed tradeoff compared to alternatives like gzip.
Cloudflare measured a 2.8x reduction in the size of eligible content after compression. For a cache that stores petabytes of data, that ratio translates directly into additional capacity without adding disks. It also reduces the volume of data transferred between data centers during cache fills and tiered cache operations, which matters for inter-region latency and bandwidth costs.
The implementation runs on Pingora, Cloudflare's Rust-based proxy framework that replaced Nginx in the company's edge stack. Pingora handles the compression and decompression inline, keeping the logic close to the cache layer where it can operate on responses before they hit storage.
The range request question
One complication that came up in community discussion is how compressed cached content interacts with range requests. Before Cache Transcoding, serving a partial request from a cached file is straightforward: read the relevant byte range from the file on disk. Once the file is compressed, serving a range request requires decompressing at least part of the file to locate the requested bytes, which changes the access pattern significantly.
Cloudflare's prototype excludes range requests from compression, which sidesteps the problem but also means that large files with range request support don't benefit from the storage savings. This is a practical limitation for now, but it raises questions about whether the approach could be extended to handle partial reads efficiently, perhaps by compressing in smaller blocks or maintaining an index of uncompressed offsets.
Cold content vs. popular content
Another point of discussion was Cloudflare's initial consideration of limiting transcoding to popular content. The reasoning would be that popular assets are served more often, so the decompression cost is amortized over more requests. But as one Hacker News commenter pointed out, compressing cold content instead would minimize CPU usage during decode, since cold assets are rarely served and the decompression cost is paid infrequently.
The optimal strategy depends on the workload. If most requests hit a small set of popular assets, compressing those assets maximizes the ratio of storage savings to decode overhead. If the long tail of requests is spread across many cold assets, compressing the cold content saves disk space without significant decode cost, since those assets are accessed infrequently. Cloudflare's current approach of compressing all eligible content regardless of popularity is the simplest to implement, but the tiered cache tests suggest the company is thinking about where the savings are most valuable.
What this means for cache economics
Cache Transcoding is a prototype, not a production feature, and Cloudflare says further testing is planned across different compression levels, content types, object sizes, and cache scenarios. But the core economics are compelling. A 2.8x compression ratio on the text portion of cached content, with a one-time CPU cost and no changes required from origin servers, is the kind of tradeoff that infrastructure teams like to make.
The broader implication is that storage efficiency at the edge doesn't always require adding more disks. Sometimes the answer is compressing what you already have, particularly when the content in question is uncompressed text arriving from origin servers that haven't been configured to send pre-compressed responses. For organizations running their own caching infrastructure, the approach is worth studying: Zstandard is open source, the compression logic is straightforward, and the potential savings in storage and inter-datacenter bandwidth are substantial.
Cloudflare's naming choice, "transcoding," has drawn some scrutiny from practitioners who argue that encoding and decoding isn't technically transcoding in the conventional sense. The terminology aside, the underlying approach is sound and the measured results are real. Whether it ships as a production feature will depend on how the CPU-to-storage tradeoff plays out across the full diversity of Cloudflare's traffic.