Cloudflare: cache de 30% a 90% com 3 regras

A taxa de acerto do cache da Cloudflare no meu blog ficava em torno de 30%. Imagens, CSS e outros recursos estáticos eram armazenados, mas cada página HTML voltava ao servidor de origem, que continuava recebendo todas as solicitações. Por padrão, a Cloudflare não armazena HTML em cache, e a configuração por Page Rules já havia sido descontinuada.

Depois de estudar Cache Rules e Edge TTL, a taxa de acerto subiu de 30% para 90%, o TTFB caiu de 500 ms para pouco mais de 100 ms e a carga do servidor foi reduzida em 90%. A seguir, explico por que o HTML não entra no cache padrão, como configurar Cache Rules e como validar o resultado.

Por que a Cloudflare não armazena HTML em cache por padrão?

Comportamento padrão de cache da Cloudflare

Primeiro, vale entender a estratégia padrão da Cloudflare. Em condições normais, ela armazena somente recursos estáticos: imagens (JPG, PNG e GIF), folhas de estilo (CSS) e scripts (JS). Páginas HTML não entram no cache por padrão.

A Cloudflare considera principalmente três condições para decidir se um recurso pode ser armazenado:

1. Cabeçalho Cache-Control: se estiver definido como private, no-store, no-cache ou max-age=0, o recurso não é armazenado.
2. Código de resposta: somente determinados códigos HTTP podem ser armazenados, como 200, 301 e 404.
3. Método da solicitação: apenas solicitações GET entram no cache; POST e PUT, por exemplo, ficam de fora.

Páginas HTML normalmente são tratadas como “conteúdo dinâmico” e podem incluir informações específicas do usuário. Essa decisão faz sentido: se o site permite login, o HTML pode conter nome de usuário e dados pessoais, que não devem ser armazenados pela CDN e exibidos a outras pessoas.

O verdadeiro motivo para não armazenar HTML

Em resumo, a Cloudflare adota esse padrão por segurança. Em um fórum da comunidade, vi o relato de alguém que ativou o cache do site inteiro. Até a página de login wp-login.php foi armazenada, junto com informações da sessão. O resultado era perigoso: qualquer visitante poderia acessar o painel do WordPress por meio da página em cache.

Por outro lado, o cache de HTML pode melhorar muito o desempenho quando o site é principalmente estático, por exemplo:

• blogs estáticos gerados com Next.js, Gatsby ou ferramentas semelhantes;
• sites institucionais e de documentação atualizados com pouca frequência;
• páginas de apresentação de produtos sem conteúdo personalizado.

O ponto principal é configurar corretamente as exclusões para páginas administrativas, login e outras áreas sensíveis.

Qual é o ganho ao armazenar HTML em cache?

Vi no Medium um relato em que o TTFB caiu de 500 ms para uma faixa de 100 a 160 ms depois da configuração do cache de HTML. A carga do servidor foi reduzida em 90%. É uma diferença enorme.

O motivo é simples. Antes, cada visitante precisava buscar o HTML no servidor de origem, que processava a solicitação, consultava o banco de dados e renderizava a página. Com o cache, a CDN entrega o HTML diretamente, sem envolver a origem. Quanto maior o tráfego, maior a diferença.

Page Rules foi descontinuado: como substituir por Cache Rules?

O fim do Page Rules

Quem já usava a Cloudflare provavelmente conhece Page Rules. Esse recurso permitia armazenar HTML por meio da opção “Cache Everything”, mas foi marcado como descontinuado.

A cronologia era esta:

• julho de 2024: novas contas gratuitas deixaram de ter acesso a Page Rules;
• 2025: a Cloudflare migraria automaticamente as Page Rules existentes para o sistema novo;
• novas configurações deveriam usar Cache Rules.

A mudança é compreensível. Page Rules era um recurso antigo, pouco flexível e limitado a três regras no plano gratuito. Isso não era suficiente para estratégias de cache mais complexas.

O novo sistema Cache Rules

Cache Rules é o sistema mais recente da Cloudflare para configurar cache e oferece bem mais flexibilidade. A principal diferença é:

Na época do Page Rules: era preciso selecionar manualmente “Cache Everything” para armazenar todo o conteúdo.

Com Cache Rules: quando você seleciona “Eligible for cache”, o comportamento equivalente a Cache Everything é ativado automaticamente.

Essa mudança é importante. No começo, procurei a opção “Cache Everything” sem perceber que o comportamento havia sido incorporado a outro nome.

Além disso, as condições do Cache Rules são mais flexíveis:

• permitem correspondência por caminho do URI, extensão de arquivo, hostname e outros critérios;
• aceitam expressões regulares, embora eu raramente precise delas;
• permitem combinar várias condições.

Cuidados na migração

Se você ainda usa Page Rules, observe estes pontos:

1. A Cloudflare faz a migração: em 2025, a empresa converteria automaticamente suas Page Rules em Cache Rules, sem necessidade de ação manual, embora também fosse possível migrar antes.
2. Algumas configurações não são migradas: “Disable Security” e “Disable Performance” foram descontinuadas e não seriam transferidas.
3. Há pequenas diferenças de comportamento: “Eligible for cache” no Cache Rules equivale a “Cache Everything” no Page Rules, mas a lógica de implementação não é exatamente a mesma.

Minha recomendação é adotar Cache Rules. A migração seria inevitável, e o sistema novo é mais claro e flexível.

Configuração prática do Cache Rules: 3 regras para o site inteiro

Agora vamos à configuração. As três Cache Rules abaixo cobrem desde a exclusão do painel até o cache do site inteiro.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Preparação: abra a página de configuração

Entre no painel da Cloudflare, selecione o domínio que deseja configurar e siga estas etapas:

1. Clique em “Caching” no menu lateral.
2. Abra a aba “Cache Rules”.
3. Clique no botão “Create rule”.

Em seguida, configure cada regra na ordem indicada.

Regra 1: ignorar o cache no painel e nas páginas administrativas (maior prioridade)

Por que ela vem primeiro? Segurança. Essa regra garante que o painel e as páginas de login nunca sejam armazenados em cache.

Etapas de configuração:

1. Rule name: digite Bypass Admin Pages.
2. When incoming requests match:
   • selecione “Custom filter expression”;
   • em Field, selecione “URI Path”;
   • em Operator, selecione “contains”;
   • em Value, informe /wp-admin. Se houver vários caminhos administrativos, adicione-os depois.
3. Adicione outros caminhos excluídos: clique em “Or” e inclua:
   • /wp-login.php, para o login do WordPress;
   • /admin/, um caminho administrativo comum;
   • /api/auth/, caso exista uma API de autenticação.
4. Then:
   • em Cache eligibility, selecione “Bypass cache”.
5. Prioridade: defina como 1, a maior prioridade.

Clique em “Deploy”. Todas as solicitações que contiverem esses caminhos ignorarão o cache e seguirão diretamente para a origem.

Lista completa de exclusões para um site WordPress:

/wp-admin
/wp-login.php
/wp-json
/cart
/checkout
/my-account

Ajuste a lista ao seu próprio site.

Regra 2: armazenar recursos estáticos (prioridade intermediária)

Essa regra é opcional, pois a Cloudflare já armazena recursos estáticos por padrão. Ainda assim, uma configuração explícita permite controlar o TTL com mais precisão.

Etapas de configuração:

1. Rule name: Cache Static Assets.
2. When incoming requests match:
   • em Field, selecione “File extension”;
   • em Operator, selecione “is in”;
   • em Value, informe jpg png gif css js woff woff2 ttf svg ico, separado por espaços.
3. Then:
   • em Cache eligibility, selecione “Eligible for cache”;
   • em Edge cache TTL, selecione “Use cache-control header if present, use default Cloudflare caching behavior if not”.
4. Prioridade: defina como 2.

Com essa regra, os recursos estáticos usam primeiro o cabeçalho Cache-Control da origem. Se ele não existir, a Cloudflare aplica o TTL padrão, que normalmente varia de 4 horas a 1 mês conforme o tipo de arquivo.

Regra 3: armazenar todo o restante (menor prioridade)

Esta é a regra principal. Ela armazena todo o conteúdo restante, inclusive HTML.

Etapas de configuração:

1. Rule name: Cache Everything Else.
2. When incoming requests match:
   • selecione “All incoming requests”;
   • se preferir mais precisão, selecione “Custom filter expression” e exclua caminhos específicos.
3. Then:
   • em Cache eligibility, selecione “Eligible for cache”;
   • em Edge cache TTL, selecione “Ignore cache-control header and use this TTL”;
   • escolha 7 days, ou 1 semana.
4. Prioridade: defina como 3, a menor prioridade.

Por que 1 semana? É um ponto de equilíbrio. Um período curto, como 1 dia, reduz o benefício do cache; um período longo, como 1 mês, pode atrasar atualizações. Para blogs e sites de documentação que mudam com pouca frequência, 1 semana costuma funcionar bem.

Observação sobre o plano gratuito: o TTL mínimo é de 2 horas em contas gratuitas e de 1 hora em contas Pro. Se o conteúdo muda com frequência, use um valor menor dentro do limite do plano.

A ordem de execução das regras é importante

A Cloudflare executa as regras da menor numeração para a maior:

1. Primeiro, a regra 1, com prioridade 1, verifica se é uma página administrativa e ignora o cache.
2. Depois, a regra 2, com prioridade 2, verifica se é um recurso estático e aplica o TTL adequado.
3. Por fim, a regra 3, com prioridade 3, armazena todas as solicitações restantes por uma semana.

Essa ordem impede o cache das páginas administrativas, aplica um TTL adequado aos recursos estáticos e força o cache das páginas HTML por uma semana.

Checklist da configuração completa

Depois de configurar as três regras, verifique:

• A regra 1 tem a maior prioridade, ou seja, o menor número.
• Todos os caminhos administrativos foram adicionados à lista de exclusões.
• O TTL da regra 3 foi ajustado à frequência de atualização do site.
• Todas as regras foram implantadas com “Deploy”.

Com isso, a configuração principal está pronta. O próximo passo é entender os detalhes do Edge TTL.

Edge TTL em detalhes: evite estas armadilhas

Edge TTL, o tempo de expiração do cache na borda, é o núcleo da estratégia. Também é uma das partes mais fáceis de configurar incorretamente.

Os três modos de Edge TTL

A Cloudflare oferece três modos de Edge TTL:

Modo 1: Use cache-control header if present, bypass cache if not

• significado: se houver Cache-Control, respeite-o; caso contrário, não armazene em cache;
• uso: quando a origem já tem cabeçalhos Cache-Control bem configurados;
• minha avaliação: é rígido demais para muitos sites pequenos. Se a origem não define Cache-Control, na prática nada é armazenado.

Modo 2: Use cache-control header if present, use default Cloudflare caching behavior if not (recomendado)

• significado: se houver Cache-Control, respeite-o; caso contrário, use o comportamento padrão da Cloudflare;
• uso: quando parte da origem define Cache-Control e você quer que a Cloudflare trate o restante;
• minha avaliação: é a opção mais equilibrada para a maioria dos sites.

Modo 3: Ignore cache-control header and use this TTL

• significado: ignore a orientação da origem e force o período de cache definido;
• uso: sites estáticos ou situações em que você conhece bem a estratégia de cache;
• minha avaliação: é uma opção agressiva, porém eficaz, para armazenar o HTML do site inteiro.

Para HTML, recomendo o modo 3. Muitas páginas não definem Cache-Control ou usam no-cache por segurança. Nesses casos, os modos 1 e 2 podem não armazenar o conteúdo. O modo 3 força o cache de forma direta.

Qual TTL escolher?

O valor depende do tipo de site. Esta tabela serve como referência:

Lembre-se do limite do plano gratuito: o mínimo é 2 horas. Se não for possível escolher um valor menor, trata-se de uma limitação do plano.

No meu blog, uso TTL de 1 semana. Na prática, funciona bem: depois de publicar um artigo, limpo o cache manualmente, como veremos adiante, e no restante do tempo mantenho uma taxa de acerto alta.

Erros comuns de configuração que eu já cometi

Erro 1: esquecer de excluir as páginas administrativas

No começo, criei apenas uma regra “Cache Everything” para economizar tempo. O painel do WordPress também entrou no cache. Durante o login, apareciam páginas antigas, e eu precisava limpar o cache manualmente para ver o resultado das ações.

Solução: sempre crie primeiro a regra Bypass e dê a ela a maior prioridade.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Erro 2: TTL longo demais e conteúdo desatualizado

Certa vez, defini o TTL como 1 mês. Depois alterei o título de um artigo, mas os visitantes continuaram vendo o anterior. Só alguns dias depois lembrei que o cache era a causa.

Solução: ajuste o TTL à frequência de atualização. Use períodos menores para conteúdo que muda com frequência e maiores para conteúdo estável. Em caso de dúvida, comece com 1 semana.

Erro 3: confundir Edge TTL com Browser TTL

Edge TTL é o tempo de cache nos nós da CDN. Browser TTL é o tempo de cache no navegador do visitante. Eles são independentes.

• Edge TTL: controla quanto tempo os nós da CDN da Cloudflare esperam antes de voltar à origem para buscar conteúdo atualizado.
• Browser TTL: controla quanto tempo o navegador espera antes de solicitar o conteúdo novamente à CDN.

Se você definir apenas o Edge TTL, o navegador continuará fazendo solicitações frequentes à CDN. A CDN não voltará à origem, mas o ganho percebido pelo visitante será menor.

Solução: em Browser TTL, escolha “Respect origin” ou defina um valor adequado, como 1 dia.

Limpeza manual: Purge Cache

Não é preciso esperar o TTL expirar quando o conteúdo muda. Você pode limpar o cache manualmente.

No painel da Cloudflare:

1. Entre no menu “Caching”.
2. Localize a área “Purge Cache”.
3. Escolha entre:
   • Purge Everything: limpa o cache do site inteiro;
   • Custom Purge: remove somente o cache de URLs específicas.

Normalmente uso Custom Purge e limpo apenas as páginas atualizadas. Limpar tudo faz com que, por um período, todas as solicitações voltem à origem e a carga do servidor aumente de repente.

Dica: no WordPress, você pode instalar um plugin da Cloudflare para limpar automaticamente o cache das páginas relacionadas quando um artigo é publicado.

Validação e otimização: confirme que o cache funciona

Depois da configuração, use dados para confirmar o resultado.

Método 1: ferramentas do desenvolvedor do navegador

É a forma mais simples e direta:

1. Abra o Chrome ou outro navegador.
2. Pressione F12 para abrir as ferramentas do desenvolvedor.
3. Acesse a aba “Network”.
4. Abra a página inicial do site.
5. Localize o documento HTML na lista, normalmente a primeira solicitação.
6. Clique nele e abra “Headers”.

Observe estes cabeçalhos:

cf-cache-status: este é o principal. Os valores possíveis incluem:

• HIT: o cache foi encontrado; o conteúdo veio da CDN sem voltar à origem;
• MISS: o cache não foi encontrado; esta solicitação voltou à origem, mas o conteúdo será armazenado;
• DYNAMIC: conteúdo dinâmico não armazenado, possivelmente porque uma regra Bypass foi aplicada;
• BYPASS: o cache foi ignorado explicitamente, como deve ocorrer em páginas administrativas;
• EXPIRED: o cache expirou e a CDN voltou à origem para atualizá-lo.

A primeira visita costuma retornar MISS, e a segunda deve retornar HIT. Se o resultado for sempre DYNAMIC ou BYPASS, há algo errado na configuração.

age: mostra, em segundos, há quanto tempo o conteúdo está armazenado na CDN. Por exemplo, age: 3600 indica que o conteúdo está no cache há 1 hora.

cache-control: mostra a estratégia definida pela origem. Mesmo no modo “Ignore cache-control”, o cabeçalho continua visível, mas a Cloudflare não o segue.

Método 2: verificar com curl

Para quem prefere o terminal, curl é uma opção rápida:

curl -I https://your-website.com

A saída mostra todos os cabeçalhos de resposta. Procure cf-cache-status e confira se o valor é HIT ou MISS.

Para ver somente os cabeçalhos relacionados à Cloudflare:

curl -svo /dev/null https://your-website.com 2>&1 | grep -i "cf-cache"

Método 3: consultar as métricas de cache no Cloudflare Analytics

Para ver o resultado geral, abra o painel da Cloudflare:

1. Selecione o domínio.
2. Clique em “Analytics” no menu lateral.
3. Abra a aba “Caching”.
4. Consulte “Cache Hit Ratio”.

Antes da configuração, minha taxa de acerto era de 30%. No dia seguinte, ela chegou a 85% e hoje permanece em torno de 90%. Um aumento semelhante indica que a configuração está funcionando.

Referências de uma situação normal:

• Taxa de acerto do cache: meta acima de 80%.
• Economia de largura de banda: deve haver uma queda perceptível, pois menos conteúdo volta à origem.
• Número de solicitações: a CDN passa a atender muito mais solicitações, enquanto a origem recebe muito menos.

Técnicas avançadas para melhorar a taxa de acerto

Se a taxa ainda estiver baixa, experimente estas otimizações:

Técnica 1: aquecer o cache

A primeira visita a um conteúdo novo sempre retorna MISS. Para que o primeiro visitante real receba HIT, você pode aquecer o cache: depois de publicar, acesse todas as páginas para que a CDN armazene o conteúdo. Outra opção é criar um script para rastrear o site automaticamente.

Técnica 2: padronizar o formato das URLs

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

URLs diferentes para a mesma página são tratadas como objetos de cache distintos:

• https://example.com/page e https://example.com/page? são diferentes;
• https://example.com/page e https://example.com/page/ são diferentes.

Padronize os links do site para evitar ocorrências desnecessárias de MISS.

Técnica 3: remover query strings desnecessárias

Se a URL inclui parâmetros de rastreamento, como ?utm_source=twitter, cada combinação pode ser tratada como uma página diferente, reduzindo bastante a taxa de acerto.

A Cloudflare oferece o recurso “Query String Sort” nas configurações de Caching. Ele ordena os parâmetros antes de armazenar a URL e pode melhorar a taxa de acerto.

Uma solução ainda melhor é usar Transform Rules da Cloudflare para remover parâmetros que não alteram o conteúdo.

Solução de problemas comuns

Problema 1: cf-cache-status sempre mostra DYNAMIC

Possíveis causas:

• o Cache-Control da origem está definido como no-cache ou private;
• a Cache Rule não corresponde à solicitação, que não chega a uma regra “Eligible for cache”.

Solução: confira as condições do Cache Rules e garanta que as solicitações HTML estejam incluídas. Com o modo 3, “Ignore cache-control”, deve ser possível forçar o cache.

Problema 2: a taxa de acerto fica em 50% ou 60%

Possíveis causas:

• algumas páginas têm parâmetros dinâmicos na URL;
• determinados cabeçalhos da origem impedem o cache;
• os nós da CDN ainda estão armazenando o conteúdo gradualmente, pois a configuração é recente.

Solução: aguarde um ou dois dias para que os nós da CDN armazenem o conteúdo. Ao mesmo tempo, consulte o Analytics para identificar os tipos de solicitação com taxa baixa e otimizá-los.

Problema 3: visitantes ainda veem conteúdo antigo depois de uma atualização

Possível causa: o TTL é longo demais ou o navegador também armazenou o conteúdo.

Solução: execute Purge Cache depois de publicar. No WordPress, também é possível instalar um plugin de automação.

Resumo

Os principais passos são:

1. Entender por que a Cloudflare não armazena HTML por padrão: o objetivo principal é proteger conteúdo dinâmico e páginas sensíveis.
2. Migrar de Page Rules para Cache Rules: Page Rules foi descontinuado; Cache Rules é mais flexível, e “Eligible for cache” equivale ao antigo “Cache Everything”.
3. Configurar três Cache Rules:
   • regra 1, prioridade 1: ignorar o cache no painel e nas páginas de login;
   • regra 2, prioridade 2: armazenar recursos estáticos;
   • regra 3, prioridade 3: forçar o cache de todo o restante, inclusive HTML, com TTL sugerido de 1 semana.
4. Escolher o modo correto de Edge TTL: para HTML, use “Ignore cache-control and use this TTL” e ajuste o período à frequência de atualização.
5. Validar o resultado: confira cf-cache-status nas ferramentas do desenvolvedor e a taxa de acerto no Analytics, com meta acima de 80%.

Depois da minha configuração, a taxa de acerto subiu de 30% para 90%, o TTFB caiu de 500 ms para pouco mais de 100 ms e a carga do servidor foi reduzida em 90%. O resultado é especialmente perceptível em sites com muito tráfego.

Agora, faça o teste:

1. Consulte a taxa de acerto atual no Cloudflare Analytics.
2. Configure as três Cache Rules seguindo as etapas acima e lembre-se de excluir primeiro as páginas administrativas.
3. Aguarde um ou dois dias e consulte o Analytics novamente.

Se houver algum problema, verifique:

• as páginas administrativas estão usando Bypass?
• as prioridades das Cache Rules estão corretas?
• o modo de Edge TTL foi selecionado corretamente?

Para sites WordPress, vale instalar o plugin oficial da Cloudflare para limpar o cache automaticamente ao publicar um artigo.

Se tiver dúvidas ou experiências de otimização, compartilhe nos comentários.