Cache Transcoding é um protótipo da Cloudflare que comprime com Zstandard (zstd) os arquivos de texto antes de gravá-los no disco do cache, dentro do Pingora, o proxy da empresa. Em testes iniciais, os arquivos elegíveis encolheram para cerca de um terço do tamanho original no disco. Quem construiu foi Aashi, no programa de estágio 1.1.1.1 da Cloudflare, e o resultado saiu em post da Cloudflare de 1º de setembro de 2026.
Não é um recurso que você liga no painel. O próprio post descreve só um protótipo, sem data de lançamento. Mesmo assim, ele mostra pra onde vai o custo de uma CDN (rede que guarda cópias do seu site em servidores perto do visitante) e dá uma boa desculpa pra revisar como o seu site entrega texto.
O que é o Cache Transcoding e por que a Cloudflare criou?
O Cache Transcoding existe porque memória e disco ficaram mais caros. A Cloudflare diz que os preços de RAM e disco subiram forte no último ano e que a pergunta de Aashi foi: dá pra tirar mais capacidade de cache dos servidores que já existem? A resposta foi comprimir o que vai pro disco, em vez de comprar mais disco.
O mecanismo, segundo o post, tem quatro passos:
- Num cache miss, o proxy codifica o corpo da resposta com zstd antes de gravar.
- Os metadados do cache registram que a forma guardada é a comprimida.
- Antes de a resposta sair pro visitante, o corpo é decodificado de volta ao original.
- No Tiered Cache, a forma comprimida circula entre as camadas. A decodificação só acontece no último salto, o que fala com o cliente.
Pro visitante nada muda. Pra Cloudflare, o mesmo servidor passa a guardar mais objetos e a movimentar menos dados entre data centers. O protótipo usa zstd no nível 3.
Quanto o zstd economiza no cache da Cloudflare?
O zstd reduziu os arquivos elegíveis a cerca de um terço do tamanho original em disco, na média dos testes iniciais. Num corpus de teste controlado, a razão de compressão foi de 2,834x. A Cloudflare mediu o custo de CPU dos dois lados:
| Medida | Resultado |
|---|---|
| Razão de compressão (corpus de teste) | 2,834x |
| Codificação | 4,31 ns por byte, cerca de 232 MB/s |
| Decodificação | 1,56 ns por byte, cerca de 641 MB/s |
| Escala do teste | mais de 1 milhão de requisições, 10 servidores de cache |
| Aumento de CPU | “menor”, na casa de “alguns por cento” |
A codificação roda uma vez por preenchimento do cache. A decodificação roda a cada resposta servida, e é por isso que, segundo o post, limitar a técnica a conteúdo popular não ajudou.
Um ponto de honestidade que a própria Cloudflare faz: o corpus de teste era propositalmente compressível e “não representa todo objeto de texto da Internet”. Um terço é o resultado de um teste inicial, não uma constante da frota inteira.
Quais arquivos entram no Cache Transcoding?
Entram respostas 200 OK de texto compressível, sem Content-Encoding definido e com Content-Length conhecido de pelo menos 4 KiB. HTML, CSS, JavaScript e JSON são o alvo típico. Imagem, vídeo e fonte ficam de fora porque já chegam comprimidos.
A lista de exclusões do post é longa e vale ler como checklist de “o que o seu site faz que impede esse ganho”:
- respostas que já vêm comprimidas da origem (quem entrega texto já em gzip ou Brotli não é recomprimido);
- respostas sem tamanho conhecido de antemão;
- requisições com
Rangee subrequisições de slice; - conteúdo binário.
O limite de 4 KiB deixa de fora só cerca de 1% dos bytes que seriam elegíveis, então arquivos minúsculos não são o problema.
Isso importa pro tráfego do meu site?
Importa menos do que a manchete sugere, e a amostra de tráfego da Cloudflare mostra por quê. Segundo o post, texto foi 67,3% das requisições e só 22,3% dos bytes. Mídia foi 21,4% das requisições e 63,3% dos bytes.
Em conta rápida, minha e não da Cloudflare: se todo esse texto encolhesse a um terço, a economia seria da ordem de 15% dos bytes armazenados. Já seria bastante em escala de CDN, mas é um teto otimista, porque depende do corpus compressível. E o peso grande continua em imagem e vídeo, que o Cache Transcoding não toca.
Pra quem tem um site de empresa, o recado é outro. Em 2014, quando entrei em SEO, ativar gzip no servidor era item fixo de checklist técnico. Em 2026 o item continua valendo, só que a conversa subiu de nível: o texto que você entrega, em que formato e com que tamanho, agora é custo de infraestrutura de quem está no meio do caminho.
O que dá pra fazer no site na segunda-feira?
O primeiro passo é ver o que o seu servidor entrega hoje. Com o terminal aberto, rode curl -sI -H "Accept-Encoding: br, gzip, zstd" https://seudominio.com.br/ e olhe o cabeçalho Content-Encoding da resposta. Repita com o CSS e o JavaScript principais.
Depois, uma checagem curta:
- Confirme que HTML, CSS, JS e JSON saem com algum
Content-Encoding(br ou gzip). Se saem sem, é o ganho mais barato que você tem hoje, independente de qualquer protótipo. - Meça o peso das imagens e vídeos da home no relatório de rede do navegador. Se a mídia domina, é ali que está a economia de verdade, como no dataset BEACON, onde o gargalo do LCP não era o download.
- Se você usa Cloudflare, acompanhe o blog deles pra saber se o Cache Transcoding vira recurso. Hoje não existe configuração pra ele.
- Relacione o resultado com Core Web Vitals: menos bytes na entrega ajudam o carregamento, mas o efeito no ranking depende de muita coisa além do tamanho do arquivo.
O que mais os estagiários da Cloudflare entregaram?
O Cache Transcoding é um de vários projetos de estagiários citados no balanço do programa 1.1.1.1, publicado em 5 de outubro de 2026. A Cloudflare tinha anunciado a meta de contratar até 1.111 estagiários em 2026, número que é uma piscadela pro resolvedor de DNS público 1.1.1.1. Até agora, são 750 estágios em 48 equipes e nove escritórios, incluindo Lisboa, segundo o balanço de um ano do programa.
Dois outros trabalhos citados ali têm relação com infraestrutura de rede:
- BGP ORIGIN. Iliana Xygkou e Bryton Herdes mediram quantas redes reescrevem o atributo ORIGIN do BGP pra puxar tráfego. Em cerca de 70% dos caminhos IPv4 e 67% dos IPv6 o valor tinha sido trocado por IGP, e os autores defendem tirar o ORIGIN da seleção de rotas. Está no estudo completo.
- Pós-quântico. Estagiários ajudaram a construir uma ferramenta interna de IA que encontra criptografia no código da Cloudflare, parte da meta da empresa de ter segurança pós-quântica até 2029.
Esses dois não mudam nada na sua operação de segunda-feira. Entram aqui como contexto do tipo de trabalho que sai desse programa.
O que o Cache Transcoding significa, em resumo, pra quem tem site?
O Cache Transcoding é um protótipo de compressão de cache com zstd que, em testes iniciais da Cloudflare, reduziu os arquivos de texto elegíveis a cerca de um terço no disco, com custo de CPU descrito como de alguns por cento. Ele não tem data de lançamento, não cobre imagem nem vídeo e foi medido num corpus propositalmente compressível.
A decisão do seu lado não depende dele: confira o Content-Encoding de HTML, CSS e JavaScript, descubra quanto da sua página é mídia e só então pense em CDN. Se você precisa decidir onde cortar peso primeiro, a mesma lógica vale pra quem bloqueia robôs: saber o que realmente passa pelo seu servidor vem antes de qualquer ajuste fino.
