Did You Know Cloudflare Can Compress Its Cache 2.8x with Zstandard?

Hi, I'm Shii-chan! Today I found a quietly impressive story on the Cloudflare Blog, and I wanted to share it with you.

Cloudflare Blog blog.cloudflare.com

What was announced?

According to the Cloudflare Blog, they prototyped something called "Cache Transcoding," which compresses content inside the cache. It was built and tested during an internship, and the results suggest you could significantly grow your effective cache capacity without adding any new hardware.

Why it matters

When you run distributed storage at Cloudflare's scale, rising RAM and storage costs really add up. If you can cache more data on the same hardware, you slow down that cost growth, and that's exactly why this experiment is worth paying attention to.

Dive Deep

They picked Zstandard (zstd) as the compression algorithm. Per the post, zstd compresses 42% faster than Brotli while producing roughly comparable file sizes, and produces files 11.3% smaller than gzip at similar speed. The prototype used zstd level 3 to balance speed and size.

It's implemented inside the cache layer of Pingora, Cloudflare's own proxy. Here's how it works:

• On a cache miss: the origin response is zstd-encoded before being written to disk, then decoded back to its original form before being sent to the client
• On a cache hit: the compressed object is read from disk and decoded. With Tiered Cache, data stays compressed as it moves between data centers, and only gets decoded on the final hop to the client

In testing, two sample text assets (195 KiB and 272 KiB) both compressed by about 2.834x. Encoding cost was 4.31 nanoseconds per byte (about 232 MB/s), and decoding cost was 1.56 nanoseconds per byte (about 641 MB/s), with only a few percent of extra CPU overhead. The test covered over a million requests across ten servers.

The content eligible for compression is text: HTML, JSON, CSS, and JavaScript, which made up 67.3% of requests and 22.3% of bytes in their measurements. About 71% of that arrived uncompressed, which is why there was so much room to gain. On the other hand, these are excluded:

• Images, video, and fonts, which are already compressed (21.4% of requests, 63.3% of bytes)
• Responses that already have Content-Encoding set
• Text under 4 KiB in Content-Length, where compression overhead isn't worth it

Sliced sub-requests, range requests, pre-compressed responses, and bodies of unknown length were also out of scope for this round. The post is careful to note that they "deliberately" tested a specific content slice, and that the numbers shouldn't be treated as a constant across the whole fleet until tested more broadly. Next steps include evaluating higher compression levels, testing a wider range of content types and sizes, and adding support for range requests and pre-compressed responses.

Wrap-up

• Cloudflare prototyped "Cache Transcoding," compressing text content in the cache with Zstandard
• Built into Pingora's cache layer: compress on miss, decode on hit
• About 2.834x compression on text assets, with only a few percent of extra CPU cost
• Images, video, and text under 4 KiB are excluded
• Still a prototype, wider content testing is planned next

A fun read if you're into CDN and cache infrastructure design, or curious how large-scale storage costs get optimized under the hood!