Uma página de produto que eu atendo levava de 3 a 5 segundos para ficar interativa, e o cliente já reclamava de carrinho abandonado. Troquei um script de terceiro que vinha de uma CDN externa por uma cópia hospedada no próprio servidor — o tempo daquela requisição caiu de 500ms para 100ms, 5 vezes mais rápido, sem mudar uma linha da lógica do script.
O suspeito errado
O primeiro palpite foi imagem pesada ou consulta lenta no banco — a página tinha fotos de produto e um catálogo grande, então parecia óbvio. Não era nada disso. Rodei o Lighthouse e, no relatório, a requisição que mais atrasava o tempo até a página ficar interativa era uma biblioteca JS minificada, carregada de uma CDN externa. A CDN, que devia acelerar o carregamento, era o próprio gargalo — e eu só enxerguei isso porque medi, não porque adivinhei.
Por que hospedar local ganhou
Faz sentido a CDN existir — mas nem sempre ela ganha da hospedagem local, e o motivo está em como o navegador abre conexões:
- Domínio novo =
DNS lookup+ handshake TLS extra. Uma CDN não é "grátis" em latência quando o site já usa HTTP/2 no domínio próprio. - O cache da CDN pode estar frio, ou o servidor mais próximo do visitante fica longe mesmo assim.
- Um ponto de falha a mais: CDN lenta ou fora do ar trava o carregamento do script.
- No mesmo domínio, o navegador reaproveita a conexão HTTP/2 já aberta com o site. Script de terceiro em outro domínio não aproveita nada disso.
NA PRÁTICA
O argumento clássico a favor da CDN era o cache compartilhado: o mesmo arquivo, baixado uma vez, servindo vários sites diferentes. Hoje os navegadores particionam o cache por origem — cada site baixa o arquivo de novo, mesmo que outro site já tenha carregado o mesmo script minutos antes. Esse argumento não vale mais na prática.
Como medir: Lighthouse pelo terminal
A extensão do Chrome funciona, mas rodar o Lighthouse pelo terminal permite automatizar: uma pasta com um relatório por página, direto do CI ou de um script local. O relatório mostra a árvore de requisições no caminho crítico, ordenada por impacto. Foi ali que a CDN apareceu no topo — não porque eu suspeitava dela, mas porque o número não mentia.
npx lighthouse https://example.com --output=json --output-path=./relatorio.json
# para varias paginas de uma vez
for url in https://example.com/ https://example.com/produto/ https://example.com/sobre/; do
npx lighthouse "$url" --output=html --output-path="./relatorios/$(echo $url | md5sum | cut -c1-8).html"
done
A correção em 5 passos
- Baixar o script da CDN e servir do próprio domínio (ex.:
wp-content/themes/tema/js/). - Trocar a tag
<script src="https://cdn.example.com/lib.min.js">pelo caminho local. - Adicionar hash ou versão no nome do arquivo, para cache-busting nos próximos deploys.
- Medir de novo com o Lighthouse e comparar antes/depois no mesmo relatório.
- Repetir o teste em 3G simulado — o Lighthouse já simula por padrão — porque é onde a diferença mais aparece.
Quando a CDN ainda faz sentido
Hospedar local não é regra sem exceção. A CDN ainda vale quando:
- A biblioteca é grande e atualizada com frequência, e você não quer manter o build dela.
- Você não controla o build ou o deploy do script (ex.: um SDK de terceiro que só é distribuído pela CDN do próprio fornecedor).
Fora esses dois casos, hospedar local costuma ganhar hoje em dia. Testar é mais barato que supor — antes de aceitar que "todo mundo usa CDN, então funciona", rode o Lighthouse na sua página e veja o que realmente está no caminho crítico.
