Summary: Cloudflare prototyped Cache Transcoding to compress eligible cache assets with Zstandard inside Pingora before writing them to disk. Initial testing reduced eligible assets to about one-third of their on-disk size in exchange for a modest CPU increase. The design targets compressible text at least 4 KiB and leaves images, video, and fonts uncompressed.
Memory prices are climbing fast, and Cloudflare operates very large distributed storage systems — its CDN among them — whose economics rest on getting the most out of every byte of memory. To make the hardware it already owns go further, the team prototyped Cache Transcoding: eligible assets get encoded with Zstandard (zstd) inside Pingora before they land on disk. The bargain it strikes is a modest CPU increase in exchange for sizable savings in storage and in bandwidth between data centers.
The Core Idea: Encode Once, Benefit Repeatedly
An eligible response that enters the cache is encoded by the proxy with zstd, kept in that compressed form, and decoded only at the moment it is about to be served to the client. Encoding is therefore paid for once per asset, while the storage and bandwidth gains keep accruing each time the asset gets reused. In the first round of testing, eligible assets came out at roughly one-third of their original on-disk size on average. The extra CPU cost estimated for the origin-facing proxy was modest, and that is the trade made on purpose: a few percent more CPU buys petabytes of effective cache capacity and fewer transfers between data centers.
Zstd is a lossless compression algorithm that Facebook open-sourced in 2016, and it strikes a balance between ratio and speed. When Cloudflare previously tested browser compression, zstd compressed data 42% faster than Brotli at nearly the same file size, and at comparable speed its files came out 11.3% smaller than gzip. The prototype sits at zstd level 3, which captures most of the gain without letting cache fills turn into a CPU bottleneck.
Not Every Kind of Content Is Worth Compressing
Transcoding is not a matter of compressing everything. Images, video, and fonts have already been compressed, and in Cloudflare’s traffic sample that slice of media accounted for 21.4% of requests but 63.3% of bytes; running it through compression again would only burn CPU. Compressible text — HTML, JSON, CSS, JavaScript — made up 67.3% of requests and 22.3% of bytes. Of that text portion, roughly 71% arrived uncompressed and compressed well, reaching about 2.8x compression in the controlled test corpus.
The eligibility rules are tight: only 200 OK responses are transcoded, and only when Content-Encoding is unset, Content-Type is compressible text, and Content-Length is at least 4 KiB. That threshold screened out a large number of tiny requests while excluding just about 1% of eligible bytes. Limiting transcoding to popular content was considered early on, but it brought no help — decoding happens on every serve, so restricting to hot assets lowered storage savings without a proportional cut in CPU. The plainer policy — transcode all eligible compressible text at or above 4 KiB — collected nearly all of the storage benefit while staying inside the CPU budget.
How Cache Transcoding Works in Pingora
On a cache miss, the Pingora-based proxy encodes the body with zstd before the write to disk. Cache metadata notes that the stored representation is compressed and keeps the original content length. On a cache hit, the stored zstd object is read back from disk and decoded. When Tiered Cache is in play, the compressed representation travels between tiers, and decoding happens only on the hop that faces the client.
When the lower tier misses but the upper tier already holds the object, the compressed object moves straight between tiers — the origin is not involved and nothing gets re-encoded. A storage encoding marker stops an object from being encoded more than once; a cache layer that receives an object can see it is already zstd and preserves it as is.
Testing and What Comes Next
The prototype was exercised against a controlled test zone, with each request correlated across logs, metrics, and traces. One performance campaign pushed more than a million requests through 10 cache servers, half of them with Tiered Cache disabled and half with it enabled. The two test assets, roughly 195 KiB and 272 KiB, compressed by about 2.8x — deliberately compressible, chosen to validate the architecture rather than to stand in for the entire internet.
Under the tested conditions, the results show the trade paying off: content stayed intact, and CPU stayed within budget. Next steps include evaluating higher zstd levels, testing a wider range of content types and sizes, and exploring range requests, pre-compressed origins, and handing compressed objects straight to downstream components that can accept them. Neither the 4 KiB threshold nor the zstd level is a permanent limit — starting conservative gave the team room to measure how the architecture behaves before tuning it.
For product builders, the lesson is plain: the cheapest optimization is sometimes a change in how you store what you already have. Cache Transcoding needs no new hardware; it lets existing hardware hold more by representing each asset more efficiently. Any system where reads greatly outnumber writes is worth examining through that CPU-versus-storage tradeoff.