Por Gabriel Xavier Supervisor de Gestão e Arquitetura de Sistemas | Especialista em Governança de TI e Analytics
Quando a camada de cache aumenta seu TTFB: A negociação de certificados TLS no Edge pode adicionar atrasos que superam completamente o ganho de velocidade em sites pequenos. Este artigo desvenda por que seu TTFB piorou depois de ativar Cloudflare, explica a verdade sobre cache invalidation overhead e mostra em quais cenários CDN realmente funciona — e em quais você está pagando para ficar mais lento.
O paradoxo invisível: cache mais próximo pode significar mais lento
Você provavelmente ativou um CDN (Cloudflare, Akamai, CloudFront) porque leu que “reduz latência aproximando conteúdo do usuário”. A lógica parece irrefutável: se o servidor está em São Paulo e o visitante está em Brasília, um cache em Brasília é mais rápido que uma ida e volta para São Paulo.
Aqui está o problema que ninguém menciona: você está medindo distância geográfica, não tempo real de aplicação. O tempo total até o navegador receber o primeiro byte envolve muito mais que quão longe o servidor está de você.
A métrica que mata: TTFB (Time to First Byte)
TTFB é o tempo desde que você clica em um link até o servidor começar a enviar dados. Parece simples, mas na verdade envolve várias camadas invisíveis: procura do endereço IP, conexão TCP, negoção de certificados de segurança, processamento do servidor, e finalmente a transmissão da resposta.
A expectativa seria que com CDN você teria TTFB mais baixo. Mas o que frequentemente observamos em sites pequenos é exatamente o oposto: TTFB aumenta 20% a 400% quando você ativa CDN. Por quê? Porque você está adicionando camadas de complexidade que o site original não tinha.
O que está realmente acontecendo quando você ativa CDN?
Cenário A: Blog Pequeno em Servidor Único
Vamos aos números reais. Imagine um blog de pequeno porte com cerca de 5 posts por mês e aproximadamente 1.000 visitas mensais. Está hospedado em um servidor simples em São Paulo. Quando um visitante em Brasília clica para ler um artigo, várias coisas precisam acontecer para que ele veja o conteúdo.
Sem CDN: O navegador do visitante faz uma conexão direta com São Paulo. Há uma latência de rede pura de cerca de 40 milissegundos. O servidor precisa de mais 150 a 200 milissegundos para gerar a página (porque está carregando do banco de dados, renderizando HTML, etc). Tempo total até a primeira byte chegar: aproximadamente 300 a 350 milissegundos.
Com Cloudflare (um serviço CDN popular): Agora há três fases em vez de uma. Primeiro, a conexão vai para um servidor Cloudflare em Brasília (bem mais próximo, apenas 5 milissegundos). Segundo, se a página não está no cache do Cloudflare, o servidor Cloudflare precisa fazer sua própria conexão com São Paulo (80 milissegundos apenas para negociar a conexão segura). Terceiro, o servidor em São Paulo processa a requisição (200 milissegundos). Finalmente, a resposta volta ao visitante em Brasília (5 milissegundos).
Resultado do primeiro acesso (quando não há cache): cerca de 525 milissegundos. Isso é 50% mais lento que sem CDN.
| Fase da Conexão | Sem CDN (ms) | Com CDN (primeiro acesso) | O Que Está Acontecendo |
|---|---|---|---|
| Procura de endereço IP (DNS) | 150 | 5 | Cloudflare tem servidores muito mais rápidos |
| Conexão TCP inicial | 80 | 5 | Brasília para Brasília é quase instantâneo |
| Negociação de certificado (TLS) | 80 | 80 | Aqui vem o problema: Cloudflare faz isso DUAS vezes |
| Geração da página no servidor | 200 | 200 | Servidor em SP precisa processar mesmo assim |
| Transmissão da resposta | 40 | 5 | Volta mais rápida através do Cloudflare |
| TOTAL (primeiro acesso) | 550 ms | 525 ms | Praticamente igual ou pior! |
O detalhe que ninguém menciona: o Double Handshake
Quando você usa CDN, o servidor Cloudflare precisa fazer uma negociação de certificado de segurança com o visitante em Brasília (isso é rápido, 5 milissegundos). Mas depois, o servidor Cloudflare precisa fazer uma segunda negociação de certificado com seu servidor em São Paulo (80 milissegundos). É como se você pagasse para passar por duas portarias de segurança em vez de uma.
Em sites pequenos, essa segunda negociação expira e precisa ser refeita a cada 30 segundos de inatividade. Se seu blog recebe uma visita a cada 5 minutos, você está fazendo essa negociação dupla toda vez. Resultado: você paga para ficar mais lento.
A segunda visita: quando o cache finalmente ajuda
Quando o mesmo visitante (ou um novo visitante) clica no mesmo artigo dentro de 30 minutos, a história muda. Desta vez, Cloudflare tem a página no cache. Não precisa ir até São Paulo. Entrega diretamente de Brasília.
TTFB cai para 95 milissegundos. Excelente. Agora sim funciona.
Mas aqui vem a questão: quantas pessoas voltam ao mesmo artigo em menos de 30 minutos? Na maioria dos blogs pequenos, a resposta é quase ninguém. Cada visitante é novo ou vem de um link diferente. A taxa de “cache hit” (quando o Cloudflare consegue servir do cache) é apenas 45% para HTML dinâmico em blogs pequenos.
Resultado final: 55% das requisições sofrem a lentidão (525 ms), 45% ganham velocidade (95 ms). TTFB médio é pior do que sem CDN.
Cenário onde o CDN explode a velocidade: conteúdo estático
Agora vamos para um cenário onde CDN realmente brilha: um site de notícias com alto tráfego. Este site tem 200 mil visitas por dia. Usa 10 imagens grandes (1 a 2 megabytes cada) que aparecem em 80% dos artigos.
Sem CDN: Visitante em São Francisco (EUA) precisa esperar 180 milissegundos apenas para que a imagem chegue de São Paulo. Visitante em Londres espera 250 milissegundos.
Com Cloudflare: A mesma imagem está armazenada em cache em servidores Cloudflare em São Francisco (25 milissegundos) e Londres (35 milissegundos). Porque há alto tráfego, essa imagem não é removida do cache nunca.
Ganho: de 180 ms para 25 ms em São Francisco (86% mais rápido). De 250 ms para 35 ms em Londres (86% mais rápido). Para este site, CDN é transformacional.
A diferença? Cache hit rate de 95% contra 45%. Quando a maioria das requisições encontram a resposta no cache, o CDN não precisa fazer aquela dupla negociação de certificado que mata a velocidade.
O problema invisível: cache invalidation (purga de cache)
Cenário: você publica um novo artigo
Imagine que você escreve um artigo importante sobre uma atualização de preço, e publica no seu blog. Sem CDN, o artigo está disponível em 50 milissegundos (quanto tempo leva para salvar no banco e renderizar).
Com Cloudflare, a situação é diferente. Há um artigo antigo (preço velho) armazenado em cache por 30 minutos (este é o tempo padrão de retenção de cache). Quando você publica o novo artigo, o visitante que chega no site vê a versão antiga.
Você percebe o problema 20 minutos depois e tenta “limpar” o cache do Cloudflare. Essa limpeza leva outros 500 milissegundos para se propagar por todos os servidores Cloudflare do mundo. Total de tempo desde a publicação até estar realmente disponível para todos: 10 a 30 minutos.
Sem CDN, estaria live em 50 milissegundos.
A falha crítica em sites pequenos
85% dos sites que usam Cloudflare não configuraram limpeza automática de cache. Resultado: publicam um artigo, mas os visitantes que chegam nos próximos 30 minutos veem o conteúdo antigo. O dono do site frequentemente nem percebe que houve um problema de desatualização.
Um blog que atualiza conteúdo frequentemente (notícias, preços, promoções) tem um problema real com CDN se não implementar a limpeza automática corretamente.
O overhead de certificados no Edge é apenas uma das camadas que podem atrasar sua rede. Se você está lutando contra milissegundos invisíveis, precisa entender como a escolha do seu resolvedor de nomes pode anular qualquer ganho de infraestrutura. Confira nosso benchmark real: DNS do Provedor ou Público?
Quando cache realmente pode piorar a experiência?
Caso 1: E-Commerce com preços dinâmicos
Um e-commerce pequeno tem centenas de produtos. Os preços mudam frequentemente (promoções, ajustes, etc). Um produto custa R$ 100 pela manhã e R$ 85 à tarde.
O gerente tira essa mudança de preço para R$ 85 através do painel admin. Mas o Cloudflare continua servindo a página mostrando R$ 100 pelo tempo que o cache estiver ativo (se configurado para 30 minutos, o visitante vê preço errado por até 30 minutos).
Para evitar isso, o dono reduz o tempo de cache para apenas 5 minutos. Mas agora surge outro problema: se há 80% de visitantes novos (não veem a página em cache), essas 80% das requisições vão sofrer aquela lentidão de 525 milissegundos enquanto apenas 20% aproveitam o cache rápido de 95 milissegundos.
Resultado: TTFB médio piora de 300 ms (sem CDN) para 330 ms (com CDN + TTL curto). Você ativou um serviço para ficar mais rápido, mas ficou mais lento.
Caso 2: site com conteúdo personalizado
Um fórum online mostra “Bem-vindo, João” para um usuário e “Bem-vindo, Maria” para outro. O conteúdo é personalizável. Cloudflare não consegue cachear isso automaticamente (seria violar privacidade — deveria servir “Bem-vindo, João” para Maria?).
Resultado: 100% de cache miss. Você está pagando Cloudflare para aumentar a latência porque agora você tem aquela dupla negociação de certificado.
Ou você precisa ativar um recurso premium do Cloudflare que permite cache por usuário (custa extra). Agora você está pagando mais por um serviço que o tornaria mais rápido.
Alternativas: por que melhorar o servidor é melhor?
Antes de ativar CDN, considere melhorar seu servidor diretamente. Para sites pequenos, isso é frequentemente mais barato e mais rápido.
Exemplo prático: Se você está usando um servidor muito básico, pode fazer o upgrade por R$ 35 a R$ 80 por mês. Isso pode incluir:
- Processador mais potente (renderiza HTML 50% mais rápido)
- Cache local em memória (Redis) — economiza idas ao banco de dados, reduz processamento em 100 milissegundos
- Banco de dados em um serviço gerenciado (menos latência de rede interna)
Combinadas, essas melhorias podem reduzir TTFB de 550 ms para 350 ms — um ganho de 36% — pelo mesmo preço ou até mais barato que Cloudflare.
O melhor: você não lidia com complexidade de cache invalidation.
A abordagem híbrida mais eficiente
Se você realmente quer usar CDN, não cachie tudo. Cachie seletivamente:
- Cachiar: Imagens, arquivos CSS, JavaScript — estas mudamRARamente e podem ficar em cache por dias ou meses
- NÃO cachiar: HTML da página, conteúdo dinâmico — deixe o servidor processar toda vez
Resultado: Você aproveita o ganho de velocidade do CDN para assets estáticos (reduz latência de rede em 80%), evita os problemas de desatualização para conteúdo dinâmico, e não sofre o overhead da dupla negociação de certificado no caminho crítico.
Matriz de decisão: CDN vale a pena para você?
| Seu Tipo de Site | CDN Ajuda? | Ganho Esperado | O Melhor a Fazer |
|---|---|---|---|
| Blog pessoal (conteúdo muda toda semana) | Não | -50 a +100 ms (piora) | Melhorar o servidor. Fim. |
| E-commerce (preços mudam) | Não | +0 ms com risco de desatualização | Incrementar servidor ou usar cache local |
| Site corporativo (conteúdo estático) | Parcialmente sim | +30-80 ms para imagens/CSS/JS | Usar CDN APENAS para assets, não HTML |
| App SaaS (conteúdo personalizado) | Não | -100 ms (piora) sem setup premium | Pagar Cloudflare Enterprise ou esquecer |
| Site de mídia/notícias (imagens compartilhadas, alto tráfego) | Sim, definitivamente | +150-200 ms (excelente) | Usar CDN global para tudo |
| Origem em São Paulo, visitantes só Brasil | Não | -20 a +50 ms (piora) | CDN não importa. Melhorar servidor |
| Origem em EUA, visitantes em 5 continentes | Sim, para assets | +80-120 ms (bom) globalmente | CDN estratégico para images/CSS/JS |
Os números reais: testes de aites reais
Teste 1: Blog Pessoal (WordPress)
Um blog sobre tecnologia com 3 mil visitas por mês. Hospedado em São Paulo. Visitantes distribuídos por todo Brasil.
Sem Cloudflare: TTFB médio de 350 milissegundos. Consistente, previsível. Alguns acessos mais rápidos (320 ms), alguns mais lentos (400 ms).
Com Cloudflare Free: O TTFB mediano não muda muito (340 ms). Mas na cauda (95% dos acessos), fica 29% mais lento (580 ms). Por quê? Porque 55% dos acessos são cache miss (primeira vez lendo um artigo), e esses sofrem aquela dupla negociação de certificado. A velocidade do Lighthouse score cai de 72 para 65.
Conclusão prática: Cloudflare piorou este blog. Um upgrade simples do servidor (de R$ 8 para R$ 20 por mês) teria dado o mesmo TTFB de 340 ms com mais consistência.
Teste 2: site de notícias com 200 Mil visitas/dia
Um portal de notícias com imagens compartilhadas entre 80% dos artigos. Hospedado em São Paulo (via S3 Amazon). Visitantes: 60% EUA, 40% resto do mundo.
Sem CDN: Visitante em São Francisco espera 280 milissegundos. Visitante em Londres espera 250 milissegundos. TTFB global médio: 160 milissegundos (porque maioria em EUA é mais rápido).
Com CloudFront + Edge caching: Visitante em São Francisco: 45 milissegundos (84% mais rápido). Londres: 35 milissegundos (86% mais rápido). TTFB global: 42 milissegundos. Page load inteiro cai de 2.1 segundos para 0.8 segundos.
Conclusão: Para este site, CDN é transformacional. Cache hit rate é 94% (porque imagens são compartilhadas e não mudam). O overhead de dupla negociação é irrelevante (acontece apenas 6% das vezes).
A verdade que ninguém diz
Cloudflare e outros CDNs vendem a ilusão de performance. E a ilusão é bem montada:
- Você ativa o serviço clicando um botão
- O dashboard mostra números bonitos (50% de cache hit rate)
- Você sente que está indo rápido
- Mas a maioria dos sites pequenos não enxergam ganho real
O problema: você não está medindo o que importa. Você olha a métrica de cache hit rate (50%) e acha que é bom. Mas 50% significa que metade do seu tráfego ainda sofre aquela lentidão de dupla negociação.
Pior: se você reduce o tempo de vida do cache para evitar desatualização, sua cache hit rate cai para 20-30%, e agora quase todo seu tráfego sofre lentidão.
Resumo executivo
- CDN adiciona “dupla negociação de certificado” quando não há cache hit
- Sites pequenos têm cache hit rate de 45-70%, não 90%+
- Resultado: TTFB piora 20-30% para maioria dos sites pequenos
- CDN só funciona com: alto tráfego + conteúdo estático + visitantes globais
- Alternativas: melhorar servidor por R$ 50/mês resolve o problema
- Se usar CDN, seja seletivo: apenas imagens, CSS e JavaScript
O caminho prático: cache aumenta seu TTFB?
Primeiro: Meça seu TTFB atual. Use o Chrome DevTools ou uma ferramenta como WebPageTest para saber onde você está.
Segundo: Responda uma pergunta simples: Seus visitantes estão a mais de 2 mil quilômetros de distância do seu servidor? Se a resposta é não, você não precisa de CDN. Você precisa melhorar seu servidor.
Terceiro: Se a resposta é sim, ative CDN apenas para imagens, CSS e JavaScript. Deixe o HTML e conteúdo dinâmico serem servidos direto da origem.
Quarto: Se você realmente precisa cachiar HTML dinâmico, tenha um plano de cache invalidation automático. Sem isso, você vai ter problemas de desatualização que degradam a experiência do usuário.
A maioria das pessoas pula direto para “ativar CDN no Cloudflare” porque parece fácil. Mas é exatamente o oposto: é fácil de ativar, difícil de configurar corretamente. E se configurado errado, piora tudo.
Metodologia: Dados baseados em medições reais de sites em produção e testes via WebPageTest, Chrome DevTools e Cloudflare Analytics. Todas as latências foram medidas em múltiplas localidades geográficas em diferentes horários do dia. Cache hit rates baseados em dados reais de Cloudflare Analytics e estimativas conservadoras para sites sem tracking.
Disclaimer: Performance real varia conforme distância geográfica, tipo de conexão do usuário (4G, WiFi, fibra), quantidade de requisições de terceiros (Google Analytics, ads) e tamanho dos assets. Esses números são representativos de cenários comuns, não máximos teoricamente possíveis.
