O ganho mais óbvio está na entrega

Arquivos estáticos como imagens, CSS e JavaScript podem ser servidos perto do visitante e ficar em cache. Isso reduz latência e poupa banda e processamento na origem. Em páginas públicas, dependendo da estratégia, parte do HTML também pode ser entregue sem executar a aplicação em toda visita.

Esse é o cenário em que o ganho costuma ser mais perceptível: conteúdo público, repetido e com regras de cache bem definidas.

Cache HIT e MISS contam histórias diferentes

Se você mede apenas uma visita que veio do cache, pode achar que resolveu o site inteiro. Eu comparo HIT, MISS e rotas dinâmicas. Quando o cache é renovado ou uma página não pode ser cacheada, o backend precisa responder sozinho.

É nesse momento que aparecem problemas de PHP, banco, APIs externas e consultas pesadas que a CDN não corrige.

Cloudflare também reduz trabalho ruim

Além de cache, regras de segurança e rate limiting podem impedir bots, scanners e tráfego de baixo valor de chegar à aplicação. Isso melhora estabilidade porque o servidor passa menos tempo respondendo requisições que não ajudam o negócio.

Mas bloqueios precisam ser medidos. Uma regra agressiva demais pode afetar usuários legítimos ou ferramentas importantes. Segurança e performance compartilham infraestrutura, mas não devem ser configuradas no escuro.

O que Cloudflare não substitui

Ele não substitui backup, monitoramento, banco bem configurado, aplicação eficiente, cron saudável nem capacidade suficiente no servidor. Também não corrige um plugin que executa uma consulta ruim ou uma API que demora vários segundos.

Pensar em Cloudflare como uma camada, e não como “o servidor”, ajuda a evitar configurações que só escondem o problema por algum tempo.

Como validar se melhorou

Eu compararia TTFB público, TTFB da origem, cache status, taxa de erros e volume que realmente chega ao backend antes e depois da mudança. Em portais de conteúdo, também vale observar buscas, páginas sociais e tráfego de bots separadamente.

Se você ativou Cloudflare e ainda sente lentidão, o próximo passo não é necessariamente “mais cache”: é descobrir qual parte da requisição continua cara.