CDN: o que é, como funciona e quando vale usar

Um blog hospedado num servidor em São Paulo abre rápido para quem está em Campinas. O mesmo post, aberto em Lisboa, demora mais, e o motivo é físico: cada pedido atravessa o oceano, chega ao servidor e volta.

Agora some o pico de uma campanha. Mil pessoas pedem o mesmo logotipo, a mesma folha de estilo e o mesmo script no mesmo minuto, e o servidor monta e entrega mil cópias idênticas de cada arquivo.

Uma CDN (rede de entrega de conteúdo) existe para esses dois problemas. Ela guarda cópias dos arquivos em servidores espalhados pelo mundo e responde no lugar do seu servidor.

A CDN acelera o que se repete. Página que muda por usuário, como carrinho, checkout e área logada, continua sendo montada pelo servidor de origem a cada pedido.

O que é uma CDN

A Cloudflare define a CDN como um grupo de servidores distribuídos geograficamente que faz cache do conteúdo perto dos usuários. Cada um desses servidores se chama servidor de borda (edge). O seu servidor, onde o site mora de verdade, se chama origem.

A rede entrega os mesmos arquivos que a origem entregaria: HTML, JavaScript, folhas de estilo, imagens e vídeo. O pedido feito em Lisboa para num servidor da rede na Europa, sem viajar até São Paulo.

A mesma página da Cloudflare diz que a rede não hospeda o site nem substitui a hospedagem. A origem continua no ar e atende tudo que a borda não sabe responder.

Os provedores mais conhecidos são Cloudflare, Fastly, Akamai, Amazon CloudFront e Bunny.

Como o pedido chega à borda

Tudo começa no DNS. Quando você ativa o serviço, o domínio passa a resolver para endereços da rede, e não mais para o IP do seu servidor. O visitante digita o endereço, recebe um IP da rede e o navegador se conecta a ela.

Cada provedor escolhe a borda do seu jeito. A Cloudflare usa anycast: o mesmo endereço é anunciado em vários data centers, e o roteamento costuma levar o pedido ao mais próximo de quem pediu.

Para quem administra o site, o tráfego web passa a atravessar a rede antes de chegar à origem. O post sobre o que é a Cloudflare mostra essa troca de DNS e a diferença entre o modo proxy e o modo só DNS.

Cache hit e cache miss: quando a origem trabalha

Na borda, cada pedido tem um de dois desfechos. A documentação da Cloudflare chama de cache hit o pedido que o cache consegue atender com a cópia que já guarda. Cache miss é o oposto: a cópia não está lá.

No miss, a borda pede o arquivo à origem, entrega ao visitante e guarda a cópia. O próximo visitante daquela região recebe um hit. Por isso o primeiro acesso a um arquivo pouco pedido sai tão lento quanto sem a rede, e os seguintes ficam rápidos.

A métrica que resume isso é a taxa de acerto (cache hit ratio): o número de hits dividido pelo total de hits e misses. Taxa alta quer dizer que a origem quase não é chamada. Com taxa baixa, você paga pela rede e o servidor continua fazendo quase todo o trabalho.

O que a CDN consegue cachear e o que fica com a origem

Arquivo estático é o caso ideal. A mesma imagem serve para todo mundo, então uma cópia na borda atende milhares de pedidos. O padrão da Cloudflare segue essa lógica: a documentação de cache lista imagens, vídeo, áudio, CSS, JavaScript, PDF e arquivos compactados entre as extensões guardadas por padrão. HTML e JSON ficam fora.

O HTML fica fora porque é nele que mora a personalização. A página do carrinho mostra os itens de um visitante. A área do cliente mostra o nome e os pedidos dele. Se a borda guardasse essa página, o visitante seguinte veria o carrinho de outra pessoa.

Os cabeçalhos que o servidor manda decidem boa parte disso. Na mesma documentação, a Cloudflare lista casos em que a resposta não vai para o cache: quando ela traz o cabeçalho Set-Cookie, ou quando o Cache-Control vem como private, no-store, no-cache ou max-age=0.

Dá para cachear o HTML de páginas públicas, como posts de blog, com uma regra própria no painel, desde que tudo que depende de sessão fique de fora.

TTL e purge: quanto tempo a cópia vale

Toda cópia na borda tem prazo. O TTL (time to live) é o tempo durante o qual a borda entrega a cópia sem consultar a origem. O servidor costuma informar esse prazo no cabeçalho Cache-Control, com a diretiva max-age, e o painel do provedor permite sobrescrever.

TTL longo gera mais hits e alivia a origem. O custo aparece quando você troca o logo ou atualiza o CSS: parte dos visitantes vê a versão velha até o prazo vencer.

O purge resolve esse atraso, porque remove a cópia da borda na hora. A documentação de purge da Cloudflare lista purge por URL, por hostname, por tag, por prefixo e de tudo, em todos os planos, do Free ao Enterprise. Ela recomenda o purge por arquivo único. Apagar tudo de uma vez faz cada arquivo voltar a dar miss, e a origem recebe esses pedidos de novo.

Um hábito evita boa parte dos purges: colocar versão no nome do arquivo, como estilo.v2.css. Arquivo novo tem URL nova, e a borda nunca entrega o antigo no lugar dele.

Efeito em Core Web Vitals e na conta de banda

O ganho de velocidade aparece primeiro no TTFB, o tempo até o primeiro byte. O web.dev, guia de performance do Google, explica que usuários longe da origem podem ter TTFB alto e que a CDN resolve a distância com servidores de borda mais perto do visitante. A referência do mesmo guia é TTFB de 0,8 segundo ou menos.

O TTFB fica fora das Core Web Vitals, mas vem antes do LCP: a imagem principal só aparece depois que o primeiro byte chega. Com imagem, fonte e CSS servidos da borda, o LCP tende a cair. INP e CLS dependem mais do código da página do que da distância, e a rede mexe pouco neles. O guia de Core Web Vitals cobre o que fazer em cada métrica.

O web.dev também alerta que o cache pode esconder um back-end lento. No miss, o visitante espera o servidor do mesmo jeito.

Na conta de banda, a Cloudflare lembra que cada resposta da origem consome tráfego, então cada hit é um arquivo que a sua hospedagem deixou de entregar. Em hospedagem que cobra por tráfego, isso reduz a fatura. Em plano de banda fixa, sobra CPU e conexão para o dia de pico.

A borda como camada de proteção

Como todo o tráfego web passa pela borda, ela é o primeiro ponto onde dá para barrar ataque. A Cloudflare escreve que uma rede bem configurada ajuda a proteger o site de ataques comuns, como DDoS. Segundo a mesma empresa, o anycast espalha o tráfego de ataque por vários data centers, e assim nenhum deles fica sobrecarregado. O post sobre ataque DDoS explica os tipos e a volumetria.

Alguns provedores somam WAF, limite de requisições e bloqueio de bot no mesmo painel. Isso varia por provedor e por plano, então confira a página de cada um antes de contar com o recurso.

Essa proteção só vale para o tráfego que passa pela rede. Se o IP real do servidor vazar, o atacante manda o tráfego direto para a origem. Um firewall que aceita conexão web só dos endereços do provedor fecha essa porta.

Quando um site pequeno não precisa de CDN

Sem público distante e sem arquivo pedido muitas vezes, a rede tem pouco a acelerar.

Pense no site de uma clínica em Joinville, com público na cidade, hospedagem no Brasil e poucas visitas por dia. Ligar uma rede ali mexe pouco no tempo de carregamento e acrescenta uma camada a mais para depurar quando algo quebrar.

Os sinais que justificam ligar são estes:

• público espalhado por regiões longe do servidor;
• muita imagem, vídeo ou arquivo para download;
• pico de acesso previsível, como campanha ou lançamento;
• histórico de ataque ou de tentativa de derrubar o site.

Em WordPress, o cache no próprio servidor costuma vir antes da rede. O guia do LiteSpeed Cache mostra essa configuração. As duas coisas se somam: o plugin evita montar a página de novo, e a borda evita a viagem até o servidor.

Como ativar CDN num site WordPress ou estático

1. Meça antes. Anote TTFB e LCP de algumas páginas, de preferência com teste feito de outra região.
2. Escolha o provedor. Algumas hospedagens já trazem a rede embutida no painel, e esse é um dos critérios do comparativo de hospedagem WordPress.
3. Aponte o domínio. Num serviço de proxy como a Cloudflare, você troca os nameservers do domínio e ativa o proxy nos registros do site. Em outros provedores, o caminho comum é criar um subdomínio só para os arquivos estáticos e reescrever as URLs de imagem e CSS para ele.
4. Crie as exceções. No WordPress, deixe fora do cache /wp-admin/, /wp-login.php, carrinho, checkout e minha conta. Página com cookie de sessão vai direto para a origem.
5. Defina TTL e versão. TTL longo para imagem e fonte, mais curto para HTML se você decidir cacheá-lo, e versão no nome do CSS e do JavaScript.
6. Confira o cabeçalho. Abra a página nas ferramentas do navegador, aba Rede, e veja o status de cache da resposta. Na Cloudflare, o cabeçalho é CF-Cache-Status.
7. Meça de novo. Compare com o número do passo 1, nas mesmas páginas e da mesma região.

Site estático, gerado com Astro, Hugo ou Jekyll, é o caso mais simples. O HTML é igual para todos os leitores, então a página inteira pode ficar na borda, com um purge a cada publicação.

Na imagem principal da página, HIT no CF-Cache-Status quer dizer que a borda respondeu no lugar do seu servidor. MISS em toda visita quer dizer que a origem continua fazendo o trabalho sozinha.