Projeto guiado: por que essa requisição está lenta?
Um runbook passo a passo pra descobrir, camada por camada, onde uma requisição está perdendo tempo.
"Tá lento" pode significar coisas completamente diferentes — DNS demorando, handshake TLS, um proxy congestionado, um cache MISS na CDN, um load balancer mandando tráfego pra um servidor sobrecarregado, ou uma query lenta no banco de dados. Esse projeto junta praticamente toda a trilha de networking num único runbook de diagnóstico, na ordem em que o tráfego realmente percorre esses pontos.
Clique em “Reproduzir fluxo” para ver a requisição passo a passo.
Passo 1 — onde exatamente o tempo está sendo gasto?
Antes de suspeitar de qualquer camada específica, abra a aba Network do navegador (lição anterior) e olhe a divisão de tempo da requisição: DNS Lookup, Initial connection/SSL, Waiting (TTFB), Content Download. O restante deste runbook segue essa ordem, porque é a ordem em que o tráfego passa por cada camada.
Passo 2 — DNS lento
Se DNS Lookup aparece alto, confirme com dig consultando um resolvedor público direto. TTL muito baixo (forçando consulta a cada poucos segundos) ou um provedor de DNS distante/sobrecarregado são as causas mais comuns.
dig @8.8.8.8 howtodev.sitePasso 3 — handshake TLS lento
Se SSL aparece alto mesmo com a conexão TCP já rápida, use curl -v pra ver o handshake isoladamente. Na maioria dos casos essa etapa é rápida (poucos round-trips) — quando não é, geralmente aponta pra um proxy/terminador TLS sobrecarregado, não pro certificado em si.
curl -v https://howtodev.sitePasso 4 — proxy e cache MISS na CDN
Muitas CDNs expõem um header dizendo se aquela resposta veio do cache do edge ou precisou buscar na origem (algo como X-Cache: HIT ou MISS, o nome exato varia por provedor). Um MISS constante no mesmo recurso pode indicar Cache-Control configurado errado na origem, fazendo a CDN nunca guardar aquele conteúdo.
curl -sI https://howtodev.site/logo.png | grep -i cachePasso 5 — load balancer mandando tráfego pro servidor errado
Se só uma fração das requisições está lenta (não todas), suspeite de um servidor específico atrás do load balancer estar sobrecarregado ou com health check falhando de forma intermitente — o sintoma típico é latência inconsistente entre requisições idênticas, já que o round-robin (ou outra estratégia) às vezes acerta o servidor saudável e às vezes o problemático.
Passo 6 — o gargalo mais comum de todos: o banco de dados
Depois de descartar DNS, TLS, CDN e load balancer, o que sobra costuma ser o próprio processamento da aplicação — na prática, na maioria das vezes uma query lenta no banco (índice faltando, tabela grande demais pra aquela consulta). É exatamente esse tempo que aparece como Waiting (TTFB) alto na aba Network, mesmo com toda a infraestrutura de rede funcionando bem.
Exercício
Rodando curl -v numa rota de API, você percebe: conexão e handshake TLS somam 90ms, mas passam 4.2s entre o fim do handshake e a primeira linha da resposta chegar. Seguindo o runbook desta lição, em qual camada você concentraria a investigação, e por quê?