Decida o que a CDN deve entregar
Comece por um inventário. Separe ativos versionados como imagens, folhas de estilo, scripts, fontes e downloads de HTML, APIs, páginas de conta, checkout e administração. CDNs frequentemente preenchem um cache sob demanda: a primeira requisição pode alcançar a origem, enquanto requisições subsequentes correspondentes podem ser servidas na borda. Uma borda próxima e um cache hit são benefícios diferentes.
Registre o host, aplicação, bucket de armazenamento ou balanceador de carga que fornece cada caminho; ele deve responder a um cache miss.
Comece por ativos idênticos para todo visitante que possam permanecer disponíveis com segurança até o fim do tempo de vida declarado.
Não compartilhe painéis personalizados, páginas vinculadas à sessão ou dados de clientes, a menos que um engenheiro qualificado tenha projetado e testado a separação.
Defina a política de cache a partir do comportamento do conteúdo
Cabeçalhos HTTP expressam o comportamento de cache. Cache-Control diz se uma resposta pode ser armazenada e por quanto tempo ela permanece fresca; um tempo de vida, ou TTL, é esse período de frescor. Um navegador é um cache privado, enquanto uma CDN costuma ser compartilhada. Use cabeçalhos explícitos. O padrão HTTP permite que s-maxage defina um tempo de vida para cache compartilhado separadamente de max-age.
Publique uma nova URL quando o conteúdo mudar, como um nome de arquivo com hash de conteúdo, e dê à versão imutável um tempo de vida longo e documentado.
Escolha um tempo de vida curto ou comportamento de validação baseado no custo de conteúdo desatualizado; não reutilize uma regra de ativo para preços, inventário ou estado de conta.
Use 'private' para respostas destinadas a um único usuário. Um cookie sozinho não torna uma resposta segura para um cache compartilhado.
Faça da invalidação uma exceção, não o plano de release
Invalidation, ou purga, ordena a uma CDN gerenciada que descarte objetos armazenados selecionados antes do vencimento normal. Use-a para correções, não para todo deploy. Confirme que a origem já esteja retornando a substituição antes de purgar; caso contrário, um refill pode preservar a resposta ruim. Caches de navegador estão fora do controle de purge da CDN, então versionamento de URL permanece confiável para arquivos que mudam.
Prefira um caminho específico, grupo de release ou uma tag de cache suportada pelo provedor em vez de uma purga do site inteiro; misses amplos podem carregar a origem de repente.
Uma purga distribuída pode não alcançar todas as bordas ao mesmo tempo. Verifique a semântica de conclusão do provedor e teste uma URL representativa.
Registre a URL antiga e a nova, a regra de cache, o escopo da purga, o resultado esperado e o passo de reversão.
Mantenha a origem atrás da camada de entrega
Acesso direto à origem pode contornar o cache da CDN e os controles de borda. Restrinja-o para que a CDN, e somente caminhos pretendidos, possam alcançá‑la. Dependendo da sua stack, use controle de acesso de origem em cloud, regras de firewall com intervalos de egress documentados da CDN, rede privada, requisições assinadas de origem ou mutual TLS (mTLS), onde ambos os lados se autenticam com certificados.
De uma localização de teste autorizada, confirme que a origem rejeita requisições públicas enquanto o hostname da CDN funciona.
Escopo health checks, ferramentas de deploy e acesso interno por identidade e rede em vez de uma regra pública ampla.
A autenticação de origem difere por CDN e origem. Use a orientação atual do provedor e revisão de segurança.
Trate o TLS como duas conexões
HTTPS na borda protege a conexão visitante→CDN, mas a conexão CDN→origem também precisa de proteção. Exija criptografia em ambas as pernas, valide o certificado de origem para o modo da CDN e atribua propriedade de hostname e renovação. A OWASP recomenda TLS 1.3 por padrão e permite TLS 1.2 para compatibilidade; diz que TLS 1.0 e 1.1 devem ser desabilitados. Obtenha revisão qualificada para dados regulados, fluxos de pagamento ou compatibilidade de cliente incomum.
Liste os proprietários dos certificados de borda e de origem, rotas de renovação e resposta a falhas.
Teste HTTP→HTTPS, host canônico e redirects profundos para loops ou caminhos perdidos.
Criptografia não torna uma resposta segura para cache; defina regras de cache separadamente para páginas autenticadas, pessoais e relacionadas a pagamentos.
Teste o caminho real de entrega antes de mudar o tráfego
Comece em um hostname de staging ou em um caminho de produção restrito, depois teste o hostname da CDN, não apenas a origem. O Chrome DevTools Network mostra status da requisição, domínio, tempo, tamanho e cabeçalhos. Teste um hard reload com cache vazio para aproximar uma primeira visita, depois uma visita repetida para inspecionar reutilização. Compare cabeçalhos e conteúdo esperados, não apenas uma página aparentemente mais rápida. Repita a partir de regiões representativas quando a audiência for distribuída.
Inspecione Cache-Control e os cabeçalhos cache-status do provedor. Confirme que ativos públicos são reutilizados e que páginas sensíveis não são compartilhadas inesperadamente.
Exercite um miss, correção de conteúdo stale, erro de origem e rollback de um ativo ou rota antes de um lançamento amplo.
Salve URLs testadas, capturas de cabeçalho, versão da regra de rota e timings antes-e-depois com o registro de mudança.
Escolha um CDN pelas necessidades operacionais, depois comprove
Não escolha uma CDN apenas pelo número de pontos de presença ou por uma alegação genérica de velocidade. O desempenho varia com geografia, horário, distribuição de tráfego, roteamento e taxa de cache hit. Compare candidatos em rotas, ativos e regiões representativas. Pergunte se cada um suporta os controles de cache necessários, invalidação direcionada, restrição de origem, fluxo de certificados, logs, papéis de acesso, preços, suporte e processo de mudança.
Use cabeçalhos de cache, comportamento de origem e páginas idênticos para os candidatos; registre resultados de primeira visita e visita repetida separadamente.
Revise custos de requisição, transferência, invalidação, logging e suporte, além de um surto por cache-miss. Preços e controles variam por plano.
Exija configuração exportável, princípio do menor privilégio, rollback testado e propriedade clara antes de cobrir rotas críticas.