Cloudflare prototypes Zstandard cache transcoding to save petabytes of storage

Cloudflare has prototyped a system called Cache Transcoding that compresses eligible cached responses with Zstandard (zstd) before writing them to disk, aiming to claw back cache capacity as RAM and hard disk prices have risen sharply over the past year. The project was built by an intern through Cloudflare's 1.1.1.1 Intern Program and runs inside Cloudflare's Pingora-based proxy. When an eligible response enters the cache on a miss, the proxy encodes the body with zstd, stores the compressed form on disk, keeps it compressed as it moves between data centers via Tiered Cache, and decodes it only on the final client-facing hop.

Not everything gets compressed. Images, video and fonts are usually already compressed, and in Cloudflare's traffic sample this media slice made up 21.4% of requests but 63.3% of bytes, so re-compressing it would waste CPU. Compressible text, HTML, JSON, CSS and JavaScript, made up 67.3% of requests and 22.3% of bytes, and about 71% of that text slice arrived with no Content-Encoding set, meaning it was not already compressed and stood to benefit. The prototype only transcodes 200 OK responses where Content-Encoding is unset, the Content-Type is compressible text, and the Content-Length is known and at least 4 KiB; slice subrequests, range requests, precompressed responses, unknown-length bodies and binary content are left untouched. In initial testing, eligible assets shrank to about one third of their original on-disk size on average, and in a controlled test corpus the eligible assets compressed by roughly 2.8 times.

Cloudflare's engineers considered restricting transcoding to only popular, frequently reused content, since hot assets are served more often, but dropped the idea: decoding happens on every serve regardless of popularity, so limiting the feature to hot content cut CPU savings without cutting CPU cost by a matching amount. A flat policy, transcoding all eligible compressible text at or above 4 KiB, captured nearly all of the measured storage benefit while staying inside the CPU budget; lowering the 4 KiB threshold further would add per-object overhead while leaving out only about 1% of the otherwise-eligible bytes. The prototype uses zstd level 3, a conservative default balancing speed and ratio, and the team notes the threshold and compression level are tunable parameters, not fixed limits, with higher zstd levels planned for future evaluation.

A storage encoding marker prevents an object from being encoded twice as it moves between cache tiers, so a tier receiving an already-zstd object from another tier keeps it compressed rather than re-encoding it. The team validated the design with a correctness campaign covering cache misses, hits, single-hop fills and Tiered Cache fills, then ran a performance campaign sending more than a million requests across 10 cache servers, half with Tiered Cache disabled and half enabled, to separate local cache behavior from inter-tier transfer effects. Two test assets, approximately 195 KiB and 272 KiB, both compressed by roughly 2.8 times. The team is explicit that this was a deliberately compressible test corpus chosen to validate the architecture, not a representative sample of all Internet text, and that a broader corpus is needed before treating the 2.8x ratio as a fleet-wide constant. Separately, Cloudflare cites earlier browser-compression testing in which zstd compressed data 42% faster than Brotli at nearly the same file size, and produced files 11.3% smaller than gzip at comparable speed. Zstandard itself was developed by Yann Collet at Facebook and open sourced in 2016. Cache Transcoding remains a prototype: next steps include evaluating higher zstd levels, testing a broader range of content types and object sizes, tuning the eligibility criteria, and eventually passing compressed objects directly to downstream components without decoding them.

Key facts

Cloudflare's Cache Transcoding prototype, built by an intern via the 1.1.1.1 Intern Program, compresses eligible cache responses with Zstandard inside its Pingora proxy before writing them to disk.
Eligible assets shrank to about one third of their original on-disk size on average in initial testing, and compressed by roughly 2.8 times in a controlled test corpus.
Compressible text (HTML, JSON, CSS, JavaScript) is 67.3% of requests but only 22.3% of bytes, while already-compressed media is 21.4% of requests but 63.3% of bytes, which is why only text is targeted.
The prototype only transcodes 200 OK responses with unset Content-Encoding, compressible Content-Type, and known Content-Length of at least 4 KiB, using zstd level 3.
A performance test sent over a million requests across 10 cache servers; two test assets of about 195 KiB and 272 KiB both compressed roughly 2.8x, but Cloudflare cautions this was a deliberately compressible corpus, not a fleet-wide sample.

Why it matters

RAM and hard disk drive prices have both climbed sharply over the past year, and Cloudflare runs multiple massively distributed storage products, including its CDN, that depend on making efficient use of the memory and disk it has deployed. Cache Transcoding attacks that cost directly: by storing eligible cached text in compressed form instead of as-is, Cloudflare can fit more content on the same hardware and cut the data it moves between its own data centers via Tiered Cache, without asking customers or origins to change anything.

Who it affects

This is internal infrastructure work at Cloudflare rather than a customer-facing feature, so the direct audience is Cloudflare's own caching and edge infrastructure teams and, indirectly, every customer whose compressible text assets (HTML, JSON, CSS, JavaScript) pass through Cloudflare's CDN and could see faster cache reuse and less eviction pressure. It also doubles as a visible showcase of Cloudflare's 1.1.1.1 Intern Program, since the prototype was built by an intern working alongside the company's engineering teams.

How to use it

There is nothing to install or configure: Cache Transcoding is a prototype living inside Cloudflare's own Pingora-based proxy, not a product or API surface exposed to customers. On a cache miss, the proxy encodes an eligible response with zstd level 3 before writing it to disk, keeps the compressed form as it crosses tiers, and decodes it only on the last hop before the client. Eligibility is narrow by design: 200 OK responses, no existing Content-Encoding, a compressible Content-Type, and a known Content-Length of at least 4 KiB; smaller or already-compressed responses, range requests and unknown-length bodies pass through unchanged.

How solid is it

The work is grounded in real measurement rather than a paper design: a correctness campaign exercised cache misses, hits, single-hop fills and Tiered Cache fills, and a performance campaign pushed more than a million requests across 10 cache servers, split between Tiered Cache disabled and enabled, to isolate local caching from inter-tier transfer effects. Two concrete test assets, about 195 KiB and 272 KiB, both compressed by roughly 2.8 times, matching the wider test-corpus result. Cloudflare also draws on earlier, separate browser-compression testing showing zstd running 42% faster than Brotli at a similar file size and producing files 11.3% smaller than gzip at comparable speed, though that comparison is about browser compression generally, not this cache prototype specifically.

Risks and caveats

Cloudflare is explicit that Cache Transcoding is still a prototype, not a shipped feature, and that its own test corpus was deliberately chosen to be compressible: the team states plainly that a broader corpus is required before the roughly 2.8x compression ratio can be treated as a constant across all of Cloudflare's traffic. The extra CPU cost is described only as "a few percent" under the traffic and reuse assumptions tested, with no exact figure given, and the piece does not say when, or whether, the feature will reach production. Remaining open questions Cloudflare names for future work include higher zstd compression levels, a wider range of content types and object sizes, tuning the eligibility criteria, and handling range requests and precompressed origin responses, none of which the current prototype covers.

“We initially considered limiting transcoding to popular content, since hot assets are reused more, but it did not help. Decoding happens every time an asset is served, so limiting the feature to only the hottest content reduced the storage saving without cutting CPU by the same amount.”

— Cloudflare blog, Cache Transcoding