--- title: "Cache Transcoding da Cloudflare reduz o cache a um terço" description: "Cache Transcoding é o protótipo da Cloudflare que comprime com zstd o que vai pro disco do cache e, em testes iniciais, reduziu os arquivos a um terço. Veja o que muda pro seu site." date: 2026-10-13T00:00:00.000Z --- **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](https://blog.cloudflare.com/cache-transcoding/) 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: 1. Num cache miss, o proxy codifica o corpo da resposta com zstd antes de gravar. 2. Os metadados do cache registram que a forma guardada é a comprimida. 3. Antes de a resposta sair pro visitante, o corpo é decodificado de volta ao original. 4. 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 `Range` e 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: 1. 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. 2. 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](/blog/cloudflare-beacon-velocidade-real-web/), onde o gargalo do LCP não era o download. 3. Se você usa Cloudflare, acompanhe o blog deles pra saber se o Cache Transcoding vira recurso. Hoje não existe configuração pra ele. 4. Relacione o resultado com [Core Web Vitals](/blog/o-impacto-dos-core-web-vitals-no-seo-um-guia-completo/): 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](https://blog.cloudflare.com/tag/internship-experience/). 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](https://blog.cloudflare.com/bgp-origin-attribute/). - **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](/blog/o-experimento-que-provou-a-maior-parte-do-crawler-no-seu-log-e-fake/) vem antes de qualquer ajuste fino.