Cache Transcoding da Cloudflare é um protótipo que comprime textos no cache com Zstandard para reduzir armazenamento e tráfego entre data centers.
Protótipo comprime dados antes de gravá-los no cache
A Cloudflare apresentou em 1º de setembro de 2026 o Cache Transcoding da Cloudflare, um protótipo que usa a compressão Zstandard, ou zstd, dentro de sua infraestrutura de cache baseada em Pingora. A iniciativa busca guardar determinados conteúdos em menos espaço e transferir menos dados entre data centers, algo relevante para a escala e o custo operacional de uma CDN.
Segundo Aashi Patel, no artigo “How we could save petabytes of cache storage with Zstandard and Pingora”, publicado pelo Cloudflare Blog em 1º de setembro de 2026, o sistema codifica respostas elegíveis antes de gravá-las em disco, mantém essa versão comprimida enquanto ela circula pelas camadas de cache e a decodifica antes da entrega ao cliente.
Cache Transcoding da Cloudflare é um protótipo que armazena textos elegíveis comprimidos com Zstandard para elevar a capacidade efetiva de cache e reduzir transferências internas, em troca de processamento adicional.
A formulação importa: trata-se de um experimento descrito pela empresa, não de um recurso anunciado como disponível para todos os clientes. Para quem administra sites no Brasil, a notícia ajuda a entender uma mudança de infraestrutura que pode melhorar a eficiência do provedor sem exigir alteração no código do site ou no navegador.
Como o Cache Transcoding da Cloudflare funciona?
Em um cache miss, quando o objeto ainda não está guardado, o proxy codifica o conteúdo com zstd e grava a versão comprimida. Em acessos seguintes, a infraestrutura lê essa representação e a decodifica para entregar os bytes originais. Nas transferências por Tiered Cache, a versão comprimida pode trafegar entre as camadas, evitando expandir o objeto a cada salto.
Zstandard é um algoritmo de compressão sem perda: depois da descompressão, o conteúdo deve ser idêntico ao original. Isso é diferente de alterar ou otimizar um arquivo para consumo final. O foco aqui não é mudar HTML, JSON, CSS ou JavaScript para o visitante, mas diminuir a ocupação interna do cache.
A Cloudflare informa que, no corpus controlado usado no protótipo, os ativos elegíveis ficaram em torno de 2,8 vezes menores. Esse número não deve ser lido como uma promessa para qualquer site: o próprio texto ressalva que o conjunto de teste era deliberadamente composto por objetos compressíveis e não representa todos os conteúdos da internet.
Quais conteúdos entram — e quais ficam de fora
A proposta não tenta recomprimir tudo. Imagens, vídeos e fontes já costumam chegar comprimidos; aplicar outra rodada tende a gastar CPU com pouco ou nenhum ganho. O protótipo prioriza conteúdo textual comprimível, como HTML, JSON, CSS e JavaScript, quando ele chega sem Content-Encoding.
Pelos critérios descritos, a resposta precisa ser 200 OK, ter tipo de conteúdo textual compatível, tamanho conhecido de ao menos 4 KiB e não estar previamente comprimida. Respostas parciais por intervalo, corpos sem tamanho conhecido, conteúdo binário e subrequisições ficam fora. É uma regra prática: economia precisa superar tanto o custo de processamento quanto a complexidade adicional.
Para equipes que operam aplicações, a lição é evitar métricas isoladas de taxa de compressão. Uma política útil precisa observar tamanho dos objetos, taxa de reutilização, CPU na codificação e na decodificação, além de tráfego entre regiões. O conteúdo sobre observabilidade para APIs pequenas é um complemento útil para transformar esses sinais em monitoramento operacional.
O ganho de armazenamento vem com custo de CPU
A compressão não é gratuita. Conforme o Cloudflare Blog, o protótipo usou zstd no nível 3 para equilibrar velocidade e tamanho, pagando a codificação quando o objeto entra no cache e a decodificação a cada entrega. No modelo da empresa, o custo extra de CPU ficou em poucos pontos percentuais sob as hipóteses testadas.
A vantagem econômica vem da reutilização: um objeto comprimido ocupa menos disco e consome menos banda interna muitas vezes, enquanto sua codificação acontece uma vez por preenchimento de cache. Ainda assim, isso só funciona se o tipo de arquivo e o padrão de acessos justificarem a troca. Para objetos pouco reutilizados ou já compactados, o benefício pode ser limitado.
O próximo passo citado pela Cloudflare é testar outros níveis de zstd, mais tipos e tamanhos de conteúdo e critérios de elegibilidade diferentes. Até esses resultados existirem, a conclusão responsável é que o Cache Transcoding da Cloudflare demonstra uma arquitetura promissora, mas seus percentuais de teste não equivalem a ganhos garantidos em produção.
Referências
- How we could save petabytes of cache storage with Zstandard and Pingora | Cloudflare Blog — cloudflare-blog — 01/09/2026
