Cloudflare's write-up shows its thinking most clearly in the policy it dropped. Cloudflare first considered transcoding only popular assets, since hot objects are reused most, and abandoned that because decode runs on every serve: limiting the feature to the hottest content gave up storage savings without cutting CPU by the same proportion [14][15]. The cold tail is where compression is nearly free, because those bytes occupy disk and are rarely decoded, while the objects you would have hand-picked are the ones that pay decode over and over. Blanket eligibility won on the simpler mechanism [15].
Now the ceiling. A third off eligible assets [5] applies only to that narrow, deliberately limited slice of the cache, not to the cache as a whole. Images, video and fonts were 63.3% of sampled bytes and get skipped as already compressed [8]. Text was 22.3% of bytes, and roughly 71% of it arrived with Content-Encoding unset, which is what Cloudflare stores on disk when the origin sends it that way [9][10][18]. So the eligible slice is 0.223 x 0.71, about 15.8% of bytes; at the corpus ratio of 2.8x it lands at 5.6%, and the sampled footprint falls by roughly 10% [6][13]. Petabytes at Cloudflare's scale [7], and one fewer disk in your rack.
For that figure to transfer, the request-weighted mix in the sample has to resemble what is actually resident on disk, and there is no reason those two distributions match: a cache holding mostly media presents less eligible surface than a request count suggests [8]. The post also carries two ratios, a third on average in initial testing and about 2.8 times on the controlled corpus, a spread of about 7% [5][6][19]. Plan against the smaller one.
The CPU figure wants the same scrutiny. A few percent is a model output under Cloudflare's own traffic and reuse assumptions [12], and hits per fill is the term that decides it. Encoding is paid once and the savings recur on every reuse [16], so high reuse amortises the fill and leaves decode as the steady cost, while a cache that fills and evicts pays level 3 encode repeatedly for bytes nobody reads twice [11].
Level 3 is a defensible pick rather than a tuned one. It is where most of the compression benefit arrives before fills become a CPU bottleneck [11], and Cloudflare's earlier browser testing put zstd 42% faster than Brotli at nearly the same file size and 11.3% smaller than gzip at comparable speed [17]. Losslessness is what actually matters here, more than ratio: every byte has to come back identical for the cache to serve the asset it promised to store [4]. This is still a prototype built by an intern on the 1.1.1.1 program [2], so read the ratios as a design note rather than a capacity plan.
