Cloudflare is testing a way to increase the effective capacity of its caching network without adding new hardware by compressing certain text assets using the Zstandard algorithm within the Pingora-based architecture. The prototype, which the company calls Cache Transcoding, aims to reduce the space data occupies on disks and the volume of data transferred between cache layers and data centers.
When an eligible response enters the cache, its data is converted into a compressed representation using zstd before being written to disk. Assets remain in this form while in the cache and while moving through Tiered Cache, then are decompressed before being sent to the client. This does not change the file's content itself; Zstandard is a lossless compression algorithm that restores every byte to its original state after decompression.
Significant Results Against Limited Processing Cost
In initial tests, the size of eligible assets on disk fell to about one-third of their original size on average. The compression ratio in the controlled test set was 2.834 times. Encoding cost 4.31 nanoseconds per byte, or about 232 megabytes per second, and was paid once when the cache was filled. By contrast, decompression cost 1.56 nanoseconds per byte, or about 641 megabytes per second, and was paid on every delivery operation.
The experiment uses Zstandard's third level as a balance between execution speed and output size. According to Cloudflare's model, the increase in CPU consumption remained at a few percent under the traffic and reuse assumptions tested by the company. Reducing the data size also allows each server to retain a larger number of objects and lowers the likelihood of useful content being evicted from the cache because it consumes more space than necessary.
Why Doesn't Cloudflare Compress Everything?
The mechanism does not target all types of content. Images, videos, and fonts are usually compressed, and in the traffic sample they accounted for 21.4% of requests but represented 63.3% of total bytes. Recompressing this data could consume CPU without providing meaningful savings.
By contrast, HTML, JSON, CSS, and JavaScript accounted for about 67.3% of requests and 22.3% of bytes. About 71% of these text responses arrived from the origin without Content-Encoding, making them candidates for compression. The prototype is limited to 200 OK responses that do not specify Content-Encoding, have a compressible text content type, and have a known length of at least 4 KiB.
Partial-range requests, responses already compressed by the origin, range requests, bodies of unknown length, and binary content are left unchanged. Cloudflare found that the 4 KiB threshold excludes a large number of small requests, but removes only about 1% of the bytes that would otherwise have been eligible.
How Does the Mechanism Work Across Storage Layers?
When a full cache miss occurs, the upper tier retrieves uncompressed data from the origin, then compresses it once and stores it in zstd format. This compressed format is passed to the lower tier, which retains it and decompresses it only on the request path to the client. If the object exists only in the upper tier, it can be moved to the lower tier without returning to the origin.
When the object exists in the lower tier, no network transfer or new encoding is needed; zstd data is read from disk, decompressed, and passed to the response path. The system records in its metadata that the object is stored in compressed format to prevent it from being compressed again when moving between storage layers.
certi.news Analysis: What Does the Experiment Actually Prove?
The experiment shows that reducing data size within the storage layer itself may have a greater cumulative effect than improving only the cache-fill process. The compression cost is paid when the object enters, while storage and bandwidth savings recur every time it is reused. This is particularly important for large-scale content delivery network operators, where local capacity is tied to the amount of content that can be retained, and data transfer between layers is tied to internal network consumption.
However, the results do not mean that a 2.8-times ratio represents all internet content or Cloudflare's entire infrastructure. The performance test was based on more than one million requests across ten cache servers, but it used a test origin consisting of two objects approximately 195 and 272 KiB in size, and both were clearly compressible. The company acknowledges that a broader range of content types and sizes is needed before considering the ratio representative of the entire fleet.
Cloudflare plans to test higher zstd levels, expand the range of content and sizes, refine eligibility conditions, and study range requests and responses that were pre-compressed. Therefore, in the current article, Cache Transcoding remains a successful prototype under specific conditions, not an announcement of final deployment across all Cloudflare traffic.