Fabrício Silva

Por que todo desenvolvedor deveria entender o caminho de uma requisição

| Tempo de leitura ~7 minutos

Internet

Todo desenvolvedor, mais cedo ou mais tarde, encara um problema que não está no código que acabou de escrever.

A página demora para abrir, mas o JavaScript parece normal. O deploy subiu, mas alguns usuários ainda veem a versão antiga. No seu computador funciona, no celular usando 4G não. A primeira reação costuma ser procurar erro no framework, no banco ou no CSS. Às vezes está ali mesmo. Muitas vezes não está.

Durante muito tempo eu achava que bastava escrever um bom código. Se a aplicação estava lenta, eu procurava o problema no JavaScript, no CSS ou no banco de dados. Só depois percebi que, muitas vezes, o gargalo estava entre o navegador e o servidor.

Entender o caminho de uma requisição mudou a forma como passei a investigar performance. Este texto não é uma aula teórica de redes. É um mapa prático do que acontece entre digitar uma URL e ver uma página na tela.

A internet não é uma nuvem, é um cabo

Esqueça o marketing. A internet é, em grande parte, cabo enterrado no chão ou passando pelo fundo do oceano. A maior parte do tráfego viaja por fibra óptica espalhada por cidades e cabos submarinos. Em alguns cenários entram rádio e satélites, mas o cabo ainda segura boa parte da história.

Para quem desenvolve, o primeiro passo é separar os papéis:

A requisição não viaja inteira. Ela é quebrada em pacotes pequenos. Quem decide o caminho desses pacotes é o roteador. Ele lê o IP de destino, como se fosse o endereço no envelope, e escolhe o próximo salto.

Isso ajuda a tirar uma ilusão comum: a internet não é um tubo único entre seu computador e o servidor. É uma sequência de decisões pequenas, repetidas várias vezes, até que os pacotes cheguem ao destino.

DNS: o caminho até o IP

Máquinas trabalham com números, os IPs. Humanos preferem nomes como google.com. O DNS existe para fazer essa tradução. O Recursive Resolver, geralmente operado pelo provedor ou por um serviço público de DNS, nem sempre sabe a resposta de cabeça, mas sabe quem consultar.

A busca funciona mais ou menos assim:

  1. Cache local: o navegador consulta o próprio cache e o arquivo hosts. Se não encontrar, chama o Resolver.
  2. Root Server: o Resolver consulta um Root Server, que aponta quem cuida daquele domínio de topo, como .com.
  3. TLD Server: o servidor do .com, por exemplo, indica qual é o Authoritative Name Server daquele domínio.
  4. Authoritative: é onde a informação oficial mora. Ele devolve o IP para o Resolver, que entrega a resposta ao sistema operacional.

Reflexão prática: por que o deploy demora a aparecer? Por causa do cache. Cada servidor no caminho guarda a resposta por um tempo, definido pelo TTL. Até que esses caches expirem e perguntem de novo ao servidor autoritativo, alguns usuários ainda podem cair no site antigo.

É por isso que trocar DNS em produção exige calma. O problema nem sempre é “não propagou”. Muitas vezes propagou, mas algum cache ainda está segurando a resposta antiga.

Não é preciso decorar cada protocolo. O importante é entender que cada etapa existe para resolver um problema específico e que caches existem para ganhar tempo, mesmo quando atrapalham um deploy.

Onde seu código mora

Você nunca “compra” um domínio para sempre. Na prática, você registra e renova esse domínio por meio de empresas como Namecheap, Registro.br ou Cloudflare.

Depois vem a pergunta que parece simples: onde esse código vai rodar? A resposta define o quanto de infraestrutura vai cair no seu colo.

Hoje muita gente foge dessa manutenção usando cloud, como AWS e GCP, ou serviços gerenciados. Você paga para alguém cuidar de parte do sistema operacional e da operação, enquanto foca mais no código.

Essa escolha é menos glamourosa do que escolher framework, mas costuma pesar mais no dia ruim. Quando o servidor cai, não importa se o componente está bonito. Importa saber quem reinicia, quem aplica patch, quem olha log e quem responde pelo backup.

HTTP e o custo invisível das “8 viagens”

HTTP é o protocolo da conversa entre cliente e servidor. Só que essa conversa tem custo. Estabelecer uma conexão pode exigir várias idas e voltas entre as duas pontas, e cada ida e volta adiciona alguns milissegundos de latência.

Em uma rede boa, isso quase desaparece. Em uma rede móvel instável, vira diferença entre uma página que parece instantânea e uma página que parece quebrada.

Dica de desenvolvedor: no HTTPS, o handshake começa com o “Client Hello”, em que o navegador informa o que suporta, e o “Server Hello”, em que o servidor escolhe a cifra e envia o certificado. Primeiro entra a criptografia assimétrica, com chaves pública e privada, para trocar o segredo. Depois a conexão usa criptografia simétrica, que é mais rápida para o payload do dia a dia.

Quando você olha uma aba Network do DevTools, cada linha ali carrega parte desse custo. DNS, conexão, TLS, espera do servidor, download. Performance começa a ficar mais concreta quando você para de olhar só para o tamanho do arquivo e começa a olhar para o tempo gasto em cada fase.

O navegador é um sistema operacional disfarçado

O navegador não apenas “mostra” texto. Ele processa uma montanha de dados na main thread.

O pipeline de renderização costuma seguir este caminho:

  1. Parsing: transforma bytes em caracteres, depois em tokens, e cria o DOM.
  2. CSSOM: cria a árvore de estilos. Atenção aqui: o CSSOM bloqueia a execução do JavaScript. Se o CSS não carregou, o motor de JS para e espera.
  3. Render Tree: junta DOM e CSSOM.
  4. Layout e Paint: calcula o tamanho das caixas e pinta os pixels.
  5. Compositing: elementos como opacity ou transform podem ser isolados em camadas e processados pela GPU, o que libera a CPU e ajuda a evitar jank.

Ponto de atenção: scripts sem defer ou async interrompem o parsing do HTML. O navegador para tudo para baixar e rodar o JavaScript, e o usuário fica olhando para uma tela branca.

Esse detalhe muda a forma de escrever front-end. Um CSS pesado pode atrasar JavaScript. Um JavaScript mal posicionado pode atrasar HTML. Uma imagem sem tamanho definido pode empurrar a página depois que o usuário começou a ler.

O navegador parece tolerante porque tenta consertar quase tudo. Mas ele cobra a conta em tempo de renderização.

O que levar para o dia a dia

Algumas perguntas simples já melhoram muito uma investigação:

Essas perguntas não substituem ferramentas, mas orientam o olhar. Em vez de abrir o DevTools procurando qualquer coisa vermelha, você começa a seguir o caminho da requisição.

Conclusão

Saber o que acontece nesses milissegundos, do cabo submarino até a pintura de pixels na GPU, muda o jeito de depurar. Quando aparecer um problema de performance, não olhe só para o for loop. Olhe também para o DNS, para o handshake, para o bloqueio do CSSOM e para a quantidade de round-trips.

Da próxima vez que você abrir um site, vale lembrar que aquele clique passou por cabos, protocolos, servidores e várias decisões de engenharia antes de chegar à sua tela. Depois de entender esse caminho, fica mais difícil olhar para um “Hello World” do mesmo jeito.

Foi estudando esses fundamentos que passei a enxergar a web de outra forma. Frameworks mudam. Bibliotecas surgem e desaparecem. Protocolos, redes e navegadores continuam ali, sustentando quase tudo o que a gente publica.

Referências