O que é CDN: por que ela acelera sites no mundo inteiro

Seu site carrega em 200ms aqui em São Paulo. Você mostra pro chefe, todo mundo aplaude, deploy na sexta. Na segunda chega um e-mail de um cliente em Lisboa reclamando que a página demora "uns cinco segundos pra abrir". Você roda um teste de novo, 200ms, e fica com cara de quem não entende nada. O problema não está no seu código: está na distância física entre o servidor e o usuário, e nenhuma micro-otimização de JavaScript vai resolver isso. Quem resolve é uma CDN.

Este artigo explica o que é uma CDN, por que ela acelera sites no mundo inteiro e onde ela ajuda de verdade (e onde não ajuda nada).

O que é uma CDN

CDN é a sigla de Content Delivery Network, ou rede de entrega de conteúdo. Na prática é um conjunto de servidores espalhados geograficamente pelo mundo, chamados de edge servers ou pontos de presença (PoPs), que guardam cópias do conteúdo do seu site perto de onde os usuários estão.

Sem CDN, todo visitante busca o conteúdo diretamente do seu servidor de origem (o origin) — aquela máquina única num data center em algum lugar específico. Se o origin está na Virgínia e o visitante está em Tóquio, cada arquivo viaja meio planeta e volta. Com CDN, o visitante de Tóquio pega o arquivo de um edge em Tóquio, e o de Lisboa pega de um edge em Lisboa. O origin só é consultado quando o edge ainda não tem aquela cópia.

A ideia toda gira em torno de uma palavra: cache. O edge faz cache do conteúdo e serve cópias. Quanto mais ele consegue servir do próprio cache, menos trabalho o origin tem e mais rápido o usuário recebe a resposta.

Por que isso acelera: latência é física

A razão número um pela qual uma CDN acelera tudo não é mística — é física. A informação viaja por cabos de fibra óptica a uma fração da velocidade da luz, e mesmo assim a velocidade da luz tem um limite. Um round trip (ida e volta de um pacote) entre o Brasil e a Europa custa, sozinho, dezenas de milissegundos. Some isso ao TLS handshake, que exige mais round trips antes de qualquer byte útil ser transmitido, e você tem centenas de milissegundos perdidos só em negociação.

Uma CDN ataca esse problema de três formas:

• Encurta a distância: o edge está perto do usuário, então cada round trip custa poucos milissegundos em vez de dezenas.
• Termina o TLS no edge: o handshake criptografado acontece no servidor próximo, não no origin do outro lado do mundo. Menos latência por conexão.
• Reduz round trips ao origin: conteúdo em cache nem chega a tocar o origin, eliminando completamente a viagem mais cara.

Distância importa. Nenhuma quantidade de código enxuto compensa 12 mil quilômetros de fibra. É por isso que mover o conteúdo para perto do usuário costuma ser a otimização de performance com melhor custo-benefício que existe.

Cache hit, cache miss e origin pull

Quando um usuário pede um arquivo, o edge tem duas respostas possíveis. Se ele já tem aquela cópia válida no cache, é um cache hit: responde na hora, sem incomodar o origin. Se não tem, é um cache miss: o edge faz um origin pull, ou seja, busca o arquivo no seu servidor de origem, guarda uma cópia e só então entrega ao usuário.

A maioria das CDNs te conta exatamente o que aconteceu via header de resposta. Na Cloudflare, por exemplo:

cf-cache-status: HIT

HIT significa que veio do cache do edge. MISS significa que o edge precisou ir ao origin. EXPIRED significa que tinha uma cópia, mas o TTL (time to live, o tempo de vida do cache) já tinha expirado. Acompanhar essa taxa de hit/miss é a forma mais direta de saber se sua CDN está realmente trabalhando ou só passando recados.

O objetivo é simples: maximizar hits, minimizar misses. Um site bem configurado serve a esmagadora maioria das requisições de assets direto do edge, e o origin só respira quando algo realmente muda.

O que cachear (e o que tratar com cuidado)

Nem tudo deve ir pro cache da mesma forma.

Assets estáticos são o caso fácil e obrigatório: imagens, CSS, JavaScript, fontes, vídeos. Não mudam entre um usuário e outro, então o edge pode guardá-los por muito tempo sem risco. Para esses, a recomendação é ser agressivo:

Cache-Control: public, max-age=31536000, immutable

Isso diz ao edge (e ao browser) para guardar o arquivo por um ano e tratar como imutável. "Mas e quando eu atualizar o arquivo?" — aí entra a versão no nome: app.4f2a9c.js. Quando o conteúdo muda, o hash muda, a URL muda, e o cache antigo simplesmente deixa de ser pedido. Você nunca invalida nada; só publica uma URL nova.

HTML e conteúdo dinâmico exigem cuidado. A página inicial de uma loja pode ser cacheada por alguns segundos ou minutos com um TTL curto. Já o carrinho de compras do usuário, o painel logado, qualquer coisa personalizada — isso não pode ir pro cache compartilhado, ou o usuário A acaba vendo os dados do usuário B. Para esses casos use Cache-Control: private ou no-store.

Cache-Control, ETag e a tal da invalidação

O navegador e o edge decidem o que fazer com uma cópia com base em dois mecanismos principais. O Cache-Control define por quanto tempo a cópia é considerada fresca. O ETag é uma impressão digital do conteúdo: quando o TTL expira, o cliente pode perguntar "ainda é essa versão?" enviando o ETag, e o servidor responde 304 Not Modified se nada mudou — economizando a transferência do arquivo inteiro.

Existe uma piada clássica de que só existem duas coisas difíceis em computação: cache invalidation e nomear coisas. A primeira metade é literal. Invalidar cache — fazer o edge esquecer uma cópia velha e buscar a nova — é genuinamente chato, porque você nunca sabe ao certo quais edges no mundo já propagaram a mudança. Por isso eu prefiro evitar invalidação sempre que possível: versionar URLs de assets e marcá-los como immutable transforma o problema de invalidação no não-problema de publicar URLs novas. Quando a invalidação for inevitável (um HTML que mudou, por exemplo), use o purge da CDN — o comando que força os edges a descartar a cópia em cache.

Ao depurar cache de CDN você vai esbarrar em 304 Not Modified, 200, 404 vindos do origin e companhia; consultar o significado exato de cada um ajuda a entender se a resposta veio do edge ou do origin — a referência de HTTP status codes resolve essa dúvida rápido.

CDN não é só velocidade

Vale desfazer a ideia de que CDN serve só pra deixar o site rápido. Como todo o tráfego passa pelo edge antes de chegar ao origin, a CDN vira uma camada de defesa e de serviços:

• Proteção contra DDoS: o edge absorve e filtra ataques volumétricos antes que cheguem perto do seu origin.
• WAF (Web Application Firewall): regras que bloqueiam injection, bots maliciosos e padrões suspeitos na borda.
• TLS gerenciado: certificados emitidos e renovados automaticamente, handshake terminado no edge.
• Otimização de imagens: conversão on-the-fly para WebP/AVIF, resize por dispositivo, compressão — sem você mexer no origin.

Para entender onde a CDN se encaixa na sua infraestrutura como um todo — origin em cloud pública, privada ou híbrida — vale ler cloud pública, privada e híbrida, porque a CDN fica sempre na frente desse origin, seja ele qual for.

Quando a CDN não ajuda

Honestidade antes de tudo: CDN não é bala de prata. Se o conteúdo é personalizado por usuário e não pode ser cacheado, o edge não tem o que servir — ele vira um proxy que só encaminha tudo pro origin, adicionando um hop em vez de economizar um. Uma API que retorna dados únicos por requisição, um dashboard pesado em queries de banco, um feed calculado em tempo real: nada disso ganha velocidade só por ter uma CDN na frente.

Nesses casos o gargalo está no origin (banco lento, query não otimizada, computação cara) e é lá que você precisa trabalhar. A CDN continua útil pelos outros motivos — TLS, WAF, proteção contra DDoS, e cache dos assets estáticos da página — mas não espere que ela acelere magicamente conteúdo que, por definição, não pode ser compartilhado entre usuários.

Perguntas frequentes

CDN serve pra que exatamente?

Serve para entregar conteúdo de um servidor próximo ao usuário, reduzindo latência e tempo de carregamento. Além da velocidade, uma CDN moderna agrega proteção contra DDoS, WAF, TLS gerenciado e otimização de imagens. Resumindo: ela faz seu site carregar rápido no mundo inteiro e absorve boa parte do tráfego e dos ataques antes que cheguem ao seu servidor.

Qual a diferença entre CDN e servidor de origem?

O servidor de origem (origin) é onde seu site realmente roda e onde os dados moram — normalmente uma máquina única num data center. A CDN é uma rede de edge servers espalhados pelo mundo que guardam cópias do conteúdo do origin e o entregam de pontos próximos ao usuário. A CDN serve cópias em cache; o origin é a fonte da verdade.

O que é cache hit e cache miss?

Cache hit acontece quando o edge já tem a cópia pedida e responde sem consultar o origin — rápido e barato. Cache miss acontece quando o edge não tem a cópia e precisa buscá-la no origin (origin pull), guardar e só então entregar. Quanto maior a taxa de hits, melhor o desempenho e menor a carga no origin.

Como funciona a invalidação de cache numa CDN?

Existem duas abordagens. A preferível é nunca invalidar: você versiona a URL dos assets (ex.: app.4f2a9c.js) e os marca como immutable, então uma mudança de conteúdo vira uma URL nova e o cache antigo deixa de ser pedido. Quando precisa mesmo expirar algo (HTML, por exemplo), use o purge da CDN, que força os edges a descartar a cópia armazenada.

O que levar daqui

CDN acelera sites porque resolve um problema de física: aproxima o conteúdo do usuário, encurta round trips e termina o TLS no edge. O coração de tudo é o cache — maximizar hits, minimizar misses, e tratar o origin como último recurso. Para assets estáticos, seja agressivo: versione as URLs, marque como immutable, cacheie por um ano e esqueça o pesadelo da invalidação. Para conteúdo dinâmico e personalizado, use a cabeça: cache curto onde dá, private/no-store onde não dá, e não espere milagre onde o gargalo é o origin. E lembre que uma CDN entrega muito mais que velocidade — DDoS, WAF, TLS e otimização de imagem vêm de brinde na borda.