Seu site precisa de CDN? Quando vale a pena

Em teoria, toda página fica mais rápida com uma CDN. Na prática, o ganho varia de enorme a imperceptível, e ele depende de três coisas: onde estão seus visitantes, quanto peso a página carrega e se o conteúdo muda a cada requisição.

Os critérios abaixo ajudam a decidir com números, não por moda. Se você ainda não sabe o que é uma CDN, comece por o que é CDN e como ela acelera seu site e volte aqui.

Quais critérios decidem se vale a pena?#

Faça quatro perguntas, nesta ordem:

1. Onde está o público? Se o servidor fica em uma região e os visitantes em outras, cada requisição atravessa uma distância grande. Se todos moram na mesma cidade do servidor, quase não há latência para economizar.
2. Quanto a página pesa? Uma página com 40 arquivos paga o custo da distância várias vezes. Uma página de texto com um CSS pequeno paga pouco.
3. O conteúdo é igual para todos? Imagens, CSS, JavaScript, fontes e sites estáticos são ótimos candidatos a cache. Painéis e respostas por usuário não são.
4. O tráfego tem picos? A CDN responde no lugar da origem, então um pico de acessos (um post viral, um lançamento) pressiona menos o servidor.

Para medir em vez de achar, use duas métricas do Google. O TTFB (tempo até o primeiro byte) é considerado bom até 0,8 s e ruim acima de 1,8 s. O LCP (tempo até o maior elemento da página aparecer) é bom até 2,5 s e ruim acima de 4 s, medido no percentil 75 dos acessos, separando celular e desktop. Se o TTFB de visitantes distantes passa de 0,8 s ou o LCP passa de 2,5 s por causa de imagens e scripts, uma CDN com cache tende a ajudar.

Em quais casos a CDN faz diferença?#

• Público espalhado: um site brasileiro com visitantes em Portugal e nos Estados Unidos.
• Muitas imagens ou vídeos: o arquivo sai do PoP (ponto de presença) mais próximo, não da origem.
• Site estático ou gerado (SSG): como o HTML também é igual para todos, a CDN pode servir quase tudo sem tocar na origem.
• Servidor pequeno: se a origem tem pouca RAM, deixar a CDN absorver as requisições repetidas evita que ela caia em picos.
• Proteção extra: CDNs costumam incluir mitigação de DDoS e WAF, e escondem o endereço da origem.

Em quais casos dá para dispensar?#

• Público local e página leve: blog de bairro, site de uma clínica, portfólio com poucos arquivos. O tempo já é baixo.
• Aplicação toda dinâmica e autenticada: um painel em que cada resposta depende do usuário quase não usa o cache.
• Ambiente interno: uma ferramenta usada por uma equipe na mesma rede.

Mesmo nesses casos, se a hospedagem já inclui CDN, deixe ligada: ela só atua onde há cache válido.

Quais são as opções?#

Não há vencedor universal. A pergunta certa é qual delas resolve o seu gargalo com a menor complexidade.

O que a CDN guarda por padrão?#

Depende do provedor. Como exemplo, a Cloudflare faz cache por extensão de arquivo, não pelo tipo de conteúdo, e a lista padrão cobre imagens (JPG, PNG, WEBP, SVG), CSS, JS, fontes (WOFF2, TTF), áudio, vídeo e arquivos compactados. Segundo a documentação, HTML e JSON não são cacheados por padrão: para guardá-los você cria uma regra de cache.

Isso explica um erro comum: o site "tem CDN", mas a página principal e a API nunca saem do cache. Para saber o que aconteceu, o cabeçalho cf-cache-status da Cloudflare mostra HIT (veio do cache), MISS (era elegível, mas buscou na origem), DYNAMIC (não elegível) ou BYPASS (era elegível, mas a resposta da origem não podia ser guardada). Outras CDNs usam outros nomes de cabeçalho.

Como configurar o cache de um site pequeno?#

Quem manda no tempo de cache é o Cache-Control da sua aplicação. Arquivos com hash no nome mudam de URL quando mudam de conteúdo, então podem ficar um ano guardados. Em Node.js com Express:

import express from "express";

const app = express();

// /assets/app.3f9a1c.js, /assets/logo.8d2e.png: o nome muda quando o arquivo muda
app.use(
  "/assets",
  express.static("public/assets", { maxAge: "1y", immutable: true }),
);

// HTML: o navegador guarda 1 minuto; a CDN pode guardar por 5 minutos
app.get("/", (req, res) => {
  res.set("Cache-Control", "public, max-age=60, s-maxage=300");
  res.sendFile("index.html", { root: "public" });
});

// Resposta por usuário: nunca em cache compartilhado
app.get("/painel", (req, res) => {
  res.set("Cache-Control", "private, no-store");
  res.send("Painel do usuário");
});

app.listen(process.env.PORT ?? 80);

s-maxage vale só para caches compartilhados, como a CDN, e tem prioridade sobre max-age neles. Lembre que, na Cloudflare, o HTML só entra no cache com uma regra de cache. private impede que a CDN guarde a resposta, e no-store proíbe qualquer cache, conforme a MDN. Detalhes de cada diretiva em o que é Cache-Control.

Como confirmar que o cache funciona?#

Rode duas vezes e compare:

curl -sI https://www.exemplo.com/assets/app.3f9a1c.js

Na segunda chamada, procure o cabeçalho Age com valor maior que zero e o indicador de HIT do seu provedor. Se a resposta nunca vem do cache, revise o Cache-Control e confirme que não há Set-Cookie na resposta, porque a Cloudflare não guarda respostas com Set-Cookie (o status pode aparecer como BYPASS).

Qual opção escolher em cada cenário?#

• Blog ou portfólio local, poucas páginas: CDN é opcional. Se a hospedagem já tem, aproveite; senão, otimize imagens primeiro (veja como deixar um site mais rápido).
• Landing page ou loja com público no país todo: use CDN com cache de assets e de HTML estático.
• Site com visitantes em vários continentes: CDN com cache é quase obrigatória.
• Aplicação autenticada (SaaS, painel): use CDN para os assets e deixe as rotas por usuário com private ou no-store.
• Muitos vídeos ou downloads: coloque os arquivos num armazenamento de objetos com CDN em vez de servir da aplicação.

Como fazer isso na Square Cloud#

Todo plano da Square Cloud inclui CDN global, tráfego ilimitado (sem cobrança por banda ou por requisição, sujeito à política de uso justo), TLS automático, WAF e proteção DDoS L3/L4/L7. Para um site pequeno, isso dispensa contratar e configurar uma CDN à parte.

A rede é CDN Anycast baseada na Cloudflare, com mais de 200 pontos de presença, HTTP/3 e WebSockets. Sua aplicação web ganha um subdomínio *.squareweb.app com HTTPS, e a partir do plano Standard você pode usar um domínio personalizado, criando no seu registrador os registros DNS que o painel mostra. O domínio continua registrado em seu nome.

A CDN faz cache respeitando o Cache-Control que a sua aplicação envia, então enviar os cabeçalhos corretos, como no exemplo acima, continua sendo trabalho da sua aplicação. Os detalhes estão em Rede e CDN da Square Cloud.