CDN detetado - Docs do MetricSpot

O que esta verificação faz

Olha para os cabeçalhos de resposta HTTP no URL auditado e identifica a CDN (Content Delivery Network) que o está a servir. Esta é uma verificação informativa — não há pass/fail. O resultado diz-te se existe uma camada de edge entre os utilizadores e o teu servidor de origem, e por que fornecedor és encaminhado.

Porque é importante

Uma CDN faz cache dos teus assets em dezenas ou centenas de pontos de presença pelo mundo. Utilizadores em São Paulo batem num nó de edge em São Paulo, não no teu servidor de origem em Frankfurt. Essa única camada muda o piso de todas as métricas de desempenho que a auditoria mede:

Tempo de resposta do servidor — primeiro byte de um PoP próximo, não uma viagem transatlântica.
Largest Contentful Paint — imagens hero e CSS chegam no mesmo orçamento de RTT.
Pontuação de desempenho Lighthouse — cada métrica de laboratório melhora com cache de edge.

Uma CDN também absorve tráfego DDoS, termina TLS no edge e deixa-te correr lógica (auth, redirecionamentos, splits A/B) perto do utilizador via edge workers. Se o MetricSpot reporta “Nenhuma CDN detetada” e a tua audiência é global, essa é a mudança de infraestrutura com maior alavancagem que podes fazer.

Como corrigir

Esta verificação é informativa, pelo que a ação depende do que foi detetado.

Nenhuma CDN detetada. Põe uma à frente da tua origem. Defaults que funcionam para a maioria dos sites:

Cloudflare — o tier gratuito cobre a maioria dos sites de marketing e landing pages SaaS. A melhor proteção DDoS. Detetado via Server: cloudflare e o cabeçalho CF-Ray.
Bunny — o egress mais barato para sites com muitas imagens e vídeo. Pay-as-you-go, sem mínimos. Detetado via Server: BunnyCDN e CDN-PullZone.
Fastly — lógica de edge granular via VCL. Forte para publishers e ecommerce que precisam de invalidação de cache em milissegundos. Detetado via X-Served-By e X-Cache.
AWS CloudFront — encaixe natural se a tua origem está na AWS. Detetado via X-Amz-Cf-Id e Via: ... cloudfront.net.
Vercel / Netlify Edge — automático se fazes deploy em qualquer das plataformas. Detetado via X-Vercel-Id / X-Vercel-Cache e Server: Netlify.

CDN detetada, mas o desempenho ainda é mau. A CDN está a encaminhar para a tua origem sem cache. Causas comuns:

Cache-Control: no-store ou private em respostas HTML da tua origem.
Set-Cookie em cada resposta (algumas CDNs recusam fazer cache de respostas com cookies).
Cabeçalhos Cache-Control em falta totalmente — o Cloudflare não faz cache de HTML por defeito; precisas de uma Page Rule ou de um cabeçalho Cache-Control: public, max-age=....

Verifica o cabeçalho de cache para rácio de hit:

curl -I https://oteudominio.com/ | grep -iE 'cache|cf-cache|x-cache|x-vercel'

HIT significa cache no edge. MISS ou DYNAMIC significa que cada pedido bate na tua origem — estás a pagar uma CDN que não estás a usar.

Escolher entre fornecedores. Se já estás no Vercel ou Netlify, usa o edge deles — mudar custa mais do que poupa. Se precisas de proteção DDoS ou corres um site WordPress / shared-hosting, Cloudflare. Se os custos de egress dominam (vídeo, imagens grandes, downloads de software), Bunny. Se os teus engenheiros querem escrever código de edge como preocupação primária, Fastly ou Cloudflare Workers.

Perguntas frequentes

Vale a pena uma CDN para um site B2B de uma só região?

Se 95% do teu tráfego está num país e estás alojado nesse país, o benefício de cache da CDN é pequeno — a maioria dos utilizadores já está perto da tua origem. Ainda assim ganhas terminação TLS, proteção DDoS e filtragem de bots, o que vale o tier gratuito no Cloudflare. Salta os planos pagos até a forma do tráfego mudar.

O MetricSpot deteta CDNs à frente de CDNs?

Apenas a camada mais externa — é o que o navegador do visitante vê. Se tens Cloudflare → Fastly → origem, reportamos Cloudflare. A configuração encadeada é incomum fora de grandes publishers e normalmente significa que uma migração está em curso; uma das duas deve sair.

Uma CDN parte o meu analytics ou testes A/B?

Não, mas pode mascarar o IP do cliente dos logs da tua origem. As CDNs reencaminham o IP original em X-Forwarded-For ou CF-Connecting-IP; o código da tua aplicação ou a ferramenta de analytics precisa de ler esse cabeçalho em vez do IP TCP de origem. A maioria dos frameworks de servidor tem uma definição de trusted-proxy para isto — configura uma vez e funcionalidades baseadas em IP (geolocalização, rate limits) funcionam como esperado.