Cloudflare libera regras de cache pós-origem sem mexer na aplicação

A Cloudflare anunciou o Cache Response Rules, um motor de regras que roda depois que o servidor de origem responde, mas antes de o conteúdo ser gravado no cache da CDN. A novidade, reportada pela InfoQ, preenche uma lacuna: até agora, as Cache Rules operavam apenas sobre atributos da requisição. Agora existe uma fase de resposta que avalia o que a origem devolveu antes de decidir como (e se) armazenar aquilo.

O problema que isso resolve

Quem opera CDN conhece o cenário: um asset estático que deveria ser servido do edge acaba sendo puxado de volta para a origem por causa de um header errado. Um Set-Cookie acidental ou um Cache-Control mal configurado torna o recurso não-cacheável, e isso se multiplica por cada visitante.

Os autores do anúncio, Alex Krivit (senior product manager da Cloudflare) e Anthony Turcios (ex-systems engineer da empresa), descrevem exatamente essa dor: um arquivo que deveria estar cacheado em todos os data centers vira não-cacheável, e o resultado é um cache hit ratio ruim, que "vaza banda da origem, arruína a performance e empurra os custos de infraestrutura para cima".

O detalhe crítico é onde esses headers costumam nascer. Muitas vezes eles são difíceis ou impossíveis de remover na própria origem, seja porque vêm de um framework, de um middleware, ou de uma aplicação legada que ninguém quer tocar. O Cache Response Rules aplica a correção "no momento exato", nas palavras dos autores, sem exigir mudança no código da aplicação.

Como funciona: duas fases de cache

A decisão de cache passa a acontecer em dois momentos distintos:

• Request-time rules (Cache Rules): decidem, antes de contatar a origem, se e como procurar o conteúdo no cache.
• Response-time rules (Cache Response Rules): rodam depois que a origem responde e permitem que os headers da resposta modifiquem o comportamento de cache antes de o conteúdo ser gravado.

O fluxo prático, no exemplo dado pela Cloudflare: um visitante pede /static/app.js. A Cloudflare checa o cache; se não encontrar, encaminha para a origem, que devolve a resposta. Entre os headers dessa resposta vem um Set-Cookie. É nesse ponto que o Cache Response Rules pode interceptar e limpar o header problemático antes de o asset ser armazenado, garantindo que ele seja cacheado corretamente da próxima vez.

Os autores fazem questão de dizer que as duas coisas são complementares, não concorrentes: "Cache Response Rules não substituem Cache Rules. Cache Rules decidem se, o quê e como cacheamos na requisição. Cache Response Rules dão a palavra final sobre o como e o se, uma vez que a resposta da origem é vista pela Cloudflare, numa fase que antes não existia."

As três ações disponíveis

No lançamento, o Cache Response Rules suporta três tipos de ação sobre a resposta da origem:

1. Remover headers que atrapalham o cache, como Set-Cookie, ETag e Last-Modified.
2. Gerenciar cache tags, úteis para invalidação segmentada de conteúdo.
3. Modificar diretivas Cache-Control, ajustando TTLs e políticas de cacheabilidade sem depender da origem.

São exatamente as manipulações que, feitas na aplicação, exigiriam alterar código, testar e fazer deploy. Aqui, a mudança fica na camada de configuração da CDN.

O que muda para quem constrói software no Brasil

Para times brasileiros que servem público local e sofrem com latência até origens em outras regiões, cada ponto percentual de cache hit ratio conta duas vezes: melhora a experiência do usuário↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → e reduz a banda de saída (egress) da origem, que costuma ser cara. Corrigir um header que estava sabotando o cache pode significar tirar tráfego repetitivo de um servidor no exterior e servi-lo direto do edge.

Há também um ganho operacional relevante em cenários comuns por aqui: migração de CDN e aplicações legadas. Quem está trocando de provedor ou lidando com um backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → que não pode ser alterado rapidamente ganha uma alavanca para arrumar o comportamento de cache sem abrir um ticket com o time de aplicação, sem janela de deploy e sem esperar o próximo sprint.

Marcella dePunzio comentou no LinkedIn que "melhorar a performance de cache muitas vezes é otimizar o comportamento da resposta em vez de adicionar mais infraestrutura", e que dar aos times mais controle sobre políticas de cache no edge ajuda a aumentar eficiência e reduzir carga na origem sem mudanças de código. Já Yuvdeep Singh, fundador da Mission FinOps, resumiu o apelo pelo lado de custos: "Corrigir erros da origem no edge, sem esperar por mudanças na aplicação, é uma grande vitória." A menção ao FinOps não é à toa: cache hit ratio ruim é um dos itens que mais infla conta de infraestrutura silenciosamente.

O que fica em aberto

Parte dos praticantes citados na cobertura levantou uma ressalva importante: a mesma flexibilidade que corrige erros pode criar novos se um engenheiro classificar incorretamente conteúdo dinâmico como cacheável. Forçar o cache de algo que deveria variar por usuário, por exemplo, pode servir a resposta errada para a pessoa errada. Ou seja, a ferramenta transfere responsabilidade: o que antes era barrado por um header "defensivo" na origem agora depende de a regra estar configurada com cuidado.

O recurso está disponível em todos os planos da Cloudflare, o que baixa a barreira de entrada inclusive para projetos menores no plano gratuito. Vale testar em ambiente controlado, medindo o cache hit ratio antes e depois, antes de sair aplicando regras de remoção de header em produção.

Fonte: InfoQ