Uma CDN costuma entrar na conversa quando alguém quer acelerar um site. O problema é que ela também pode esconder a origem da lentidão. Às vezes o visitante recebe uma cópia antiga. Às vezes o arquivo nem passa pela rede de distribuição.
O guia da Cloudflare sobre problemas comuns de CDN ajuda a separar esses casos. Limpar o cache não conserta um servidor fora do ar, assim como trocar o DNS não resolve um CSS pesado.
Onde a CDN entra no caminho
Uma rede de distribuição mantém cópias de arquivos em servidores de diferentes regiões. Se a cópia não existe ou expirou, o servidor de borda busca o arquivo na origem e pode guardá-lo para a próxima visita.
Esse caminho cria mais um componente para investigar. O navegador pode falar com a CDN, enquanto a CDN conversa com a hospedagem e a página busca scripts em domínios externos.
Comece pelo navegador. Abra as ferramentas de desenvolvedor, use a aba Network e recarregue a página. Procure arquivos lentos, respostas 4xx ou 5xx e recursos que bloqueiam a renderização.
Também confira os cabeçalhos da resposta. Eles ajudam a descobrir se o conteúdo veio do cache ou precisou voltar à origem. A pergunta é simples: a rede entregou uma cópia ou fez uma nova busca?
Quando o site continua lento
Uma causa comum é a origem responder devagar ou ficar indisponível. A CDN não consegue servir uma página que nunca conseguiu buscar, a menos que exista uma cópia válida armazenada.
Conteúdo dinâmico, como carrinho, painel, busca e chamadas de API, precisa consultar a origem. Tentar colocar tudo no cache pode criar erro ou entregar dados errados.
Arquivos grandes e recursos que bloqueiam a renderização também pesam. CSS e JavaScript podem impedir que o navegador mostre o conteúdo principal. Comprima arquivos e adie scripts desnecessários.
Scripts de terceiros merecem uma verificação própria. Um widget, análise ou player pode apontar para outro servidor, fora da sua CDN. Trocar um recurso externo lento pode render mais.
O cache hit ratio mostra a relação entre respostas atendidas pela cópia da CDN e respostas que consultaram a origem. Um índice baixo pode vir de regras incompletas, query strings variadas ou conflito nos cabeçalhos Cache-Control.
Cache baixo e conteúdo antigo
Uma URL como imagem.jpg?v=2 pode ser tratada como o mesmo arquivo ou como outro, dependendo da regra. Se o sistema gera parâmetros variados, a CDN acumula misses desnecessários.
O sintoma oposto é conteúdo velho. Se a página abre rápido, mas a alteração não aparece, o TTL pode estar alto demais. TTL é o tempo que uma cópia permanece válida.
Limpar o cache resolve um caso pontual, mas não substitui uma regra adequada. Depois do purge, teste a URL pública e confirme se a nova versão chegou.
O DNS define para onde o domínio e seus subdomínios apontam. É possível proteger o domínio principal e esquecer api, imagens ou outro subdomínio usado na página.
Liste os domínios usados pela página e confira cada registro. Não troque tudo de uma vez. Registre o valor atual, altere um componente e repita o teste.
DNS, HTTPS e uma ordem segura de correção
Erros de SSL ou conteúdo misto aparecem quando a página mistura HTTPS e HTTP, usa um subdomínio fora do certificado ou recebe uma configuração incompatível entre CDN e origem.
Uma sequência prática é testar a página, separar cache, origem, DNS e scripts externos, conferir cabeçalhos e TTL, corrigir uma regra por vez e testar de novo em uma janela anônima.
Quando a alteração funciona, anote o sintoma original, a configuração e o resultado. Se não funcionar, reverta antes de tentar outra hipótese. Uma mudança por vez facilita a investigação.
Se o site está lento, descubra qual arquivo demora e se veio do cache. Se mostra uma versão antiga, confira TTL. Se um subdomínio falha, revise o DNS e o caminho até a origem.
A Cloudflare recomenda olhar além do cache hit ratio e combinar esse sinal com métricas como os Core Web Vitals. Um bom índice não garante uma página rápida.
Checklist para o próximo erro
CDN é uma camada útil, mas não é um botão mágico de velocidade. Comece pelo sintoma, confirme o caminho da requisição e só então mexa na configuração.
O teste fica mais confiável quando você compara a mesma URL em horários diferentes e em mais de uma rede. Um atraso isolado pode ser uma falha momentânea, não uma regra permanente da CDN.
Observe o status, o tamanho e o tempo de cada recurso. Um arquivo que chega com status 200 ainda pode ser pesado demais para o navegador. Velocidade de entrega e tempo de processamento são problemas diferentes.
Para WordPress, imagens originais muito grandes, plugins que geram consultas e fontes externas podem aparecer juntos no relatório. Avalie cada um sem concluir que a CDN é culpada só porque ela está no caminho.
Cabeçalhos enviados pelo servidor de origem podem limitar o cache. Compare Cache-Control, idade da resposta e o comportamento após uma atualização. A configuração do painel e a resposta real precisam contar a mesma história.
Se a mudança envolver DNS, lembre que a propagação pode levar tempo. Mantenha o registro anterior e planeje uma forma de voltar. Uma alteração urgente sem plano de retorno transforma um teste em indisponibilidade.
A CDN deve reduzir trabalho repetido, não esconder um problema de aplicação. Quando o diagnóstico aponta para código, banco de dados ou hospedagem, corrija essa camada e deixe o cache cumprir o papel dele.
Quando encontrar uma correção, faça um segundo teste com o cache aquecido e outro depois de limpar apenas o recurso afetado. Assim você confirma tanto a primeira entrega quanto as visitas seguintes.
Não desligue a CDN como primeira reação. Isso pode aumentar a carga na origem e retirar uma pista importante. Preserve os dados do teste, inclusive a URL, o horário e os cabeçalhos observados.
O objetivo não é decorar todas as opções do provedor. É localizar o trecho que falha, fazer uma alteração pequena e confirmar o resultado antes de seguir para a próxima hipótese.
