O que acontece quando você digita uma URL no navegador?

Você digita um endereço, aperta Enter e, alguns instantes depois, uma aplicação aparece. Parece uma operação simples, mas nesse intervalo o navegador pode resolver um domínio, estabelecer uma conexão segura, trocar mensagens com servidores e transformar arquivos em uma interface.

Quando trabalhamos com React, Node.js ou outro framework, normalmente acompanhamos apenas uma parte desse caminho. O componente renderiza, a API responde e os dados aparecem. Mas o que acontece antes de a requisição chegar ao backend? E depois que a resposta sai dele?

Este é mais um artigo da série “Coisas que usamos todos os dias, mas raramente paramos para entender.” Vamos acompanhar uma navegação para conectar navegador, redes, backend e infraestrutura, sem tentar esgotar cada assunto.

Para isso, considere este endereço fictício:

https://loja.example/produtos?categoria=livros#ofertas

1. O navegador interpreta o endereço

Antes de buscar qualquer coisa na rede, o navegador precisa interpretar a URL.

Como a porta não foi informada, HTTPS utiliza a porta padrão 443.

Um detalhe importante: o fragmento #ofertas não é enviado na requisição HTTP. Ele pode orientar o navegador a navegar até uma seção da página ou ser interpretado pelo código da aplicação.

Já o caminho e a query string fazem parte da solicitação enviada ao servidor.

Também podem existir decisões anteriores à navegação, como distinguir um endereço de uma pesquisa ou atualizar uma navegação para HTTPS.

2. Nem toda navegação começa do zero

Antes de seguir, precisamos ajustar uma expectativa: as etapas deste artigo não acontecem integralmente em toda navegação.

O navegador pode ter uma resposta em cache, uma resolução DNS ainda válida ou uma conexão que pode ser reutilizada. Em aplicações que utilizam service workers, a navegação também pode ser interceptada e atendida conforme as regras implementadas.

Vamos acompanhar o caso em que precisamos acessar a rede e estabelecer uma conexão. Depois, voltaremos ao papel dessas otimizações.

3. DNS: como encontrar o destino?

Nós usamos nomes como loja.example. Para iniciar a comunicação com um destino na rede, o cliente precisa obter informações como seus endereços IP.

É aí que entra o DNS, Domain Name System.

A resolução pode aproveitar caches locais ou consultar um resolvedor recursivo. Quando necessário, esse resolvedor percorre a hierarquia do DNS, consultando servidores raiz, servidores do domínio de topo e servidores autoritativos.

Essa sequência não precisa ser repetida inteira a cada acesso, porque as respostas podem ser armazenadas em cache conforme seus tempos de validade.

Registros do tipo A informam endereços IPv4, enquanto registros AAAA informam endereços IPv6. Também podem existir aliases e outras informações envolvidas na resolução.

O IP obtido não precisa apontar diretamente para a máquina que executa sua aplicação. Ele pode levar a uma CDN ou a outro ponto de entrada da infraestrutura.

DNS também não procura o caminho /produtos. Ele resolve informações sobre o nome do host; a rota será interpretada em outra etapa.

4. IP, transporte e segurança têm responsabilidades diferentes

Com um endereço de destino disponível, os dados precisam atravessar a rede. O IP participa do endereçamento e encaminhamento dos pacotes, mas não realiza sozinho todo o trabalho necessário para uma conversa confiável entre navegador e servidor.

Para entender o restante do caminho, podemos separar as responsabilidades:

Essa organização tem uma particularidade: com QUIC, a negociação de segurança é integrada ao estabelecimento da conexão. Por isso, não devemos imaginar todas essas etapas como blocos independentes executados sempre na mesma ordem.

5. TCP ou QUIC: qual conexão será usada?

O caminho com TCP

Em conexões HTTP/1.1 e HTTP/2 sobre HTTPS, o navegador normalmente utiliza TCP e, sobre ele, TLS.

O estabelecimento de uma conexão TCP costuma ser apresentado pelo three-way handshake:

1. O cliente envia SYN.
2. O servidor responde com SYN-ACK.
3. O cliente confirma com ACK.

O TCP oferece um fluxo de bytes confiável e ordenado. Seus mecanismos lidam, por exemplo, com retransmissão e controle de congestionamento.

Se uma conexão existente puder ser reutilizada, não será necessário criar uma nova para cada recurso.

O caminho com QUIC

HTTP/3 utiliza QUIC, um protocolo de transporte baseado em UDP.

Isso não significa que HTTP/3 simplesmente abriu mão de confiabilidade. O QUIC implementa mecanismos próprios de entrega confiável, controle de congestionamento e múltiplos fluxos.

A perda de dados de um fluxo não impõe a mesma espera de ordenação aos demais que ocorre ao compartilhar um único fluxo TCP. Entretanto, fluxos ainda compartilham recursos, como a capacidade da conexão.

O QUIC também integra o handshake TLS 1.3 ao estabelecimento da conexão. Portanto, HTTP/3 não segue o fluxo “primeiro TCP, depois TLS”.

A versão utilizada depende do suporte do cliente, do servidor e das condições de acesso.

6. TLS: estabelecendo uma comunicação segura

Como o endereço utiliza HTTPS, a comunicação precisa ser protegida.

Durante a negociação TLS, cliente e servidor estabelecem parâmetros criptográficos e chaves para proteger os dados. Na autenticação comum da Web, o navegador também verifica o certificado apresentado, incluindo sua validade para o nome acessado e a cadeia de confiança.

Isso oferece proteção contra leitura e alteração do conteúdo durante o transporte, dentro das garantias do protocolo.

Mas existe uma distinção importante: HTTPS protege a conexão; ele não comprova que o site possui boas intenções ou que suas regras de negócio são seguras.

Em uma infraestrutura com CDN ou proxy, a conexão TLS do navegador pode terminar nesse intermediário. A comunicação até o servidor de origem constitui outro trecho, que precisa de configuração própria.

7. HTTP: agora existe uma solicitação de recurso

Com a conexão disponível, o navegador envia uma requisição HTTP.

Uma representação didática em HTTP/1.1 seria:

GET /produtos?categoria=livros HTTP/1.1
Host: loja.example
Accept: text/html

O método GET solicita o recurso. O caminho e a query string indicam o que estamos buscando, e os headers fornecem informações adicionais.

Cookies aplicáveis àquela requisição também podem ser enviados, respeitando suas regras.

HTTP/2 e HTTP/3 usam formatos diferentes dessa representação textual. Mesmo assim, conceitos como método, headers e status permanecem.

A resposta pode conter um status, headers e um corpo:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!doctype html>
<html lang="pt-BR">
  ...
</html>

Nem toda resposta traz uma página. Ela pode indicar um redirecionamento, um erro, uma validação de cache ou outro tipo de recurso. Um redirecionamento pode levar o navegador a iniciar uma nova solicitação.

8. O “servidor” pode ser uma infraestrutura inteira

É comum resumir essa etapa como “a requisição chegou ao servidor”, mas ela pode passar por vários componentes.

Uma CDN pode responder com conteúdo armazenado. Um proxy reverso pode encaminhar a solicitação. Um balanceador pode distribuir o tráfego entre instâncias da aplicação.

Só então a execução pode chegar ao código responsável pela rota.

Em uma aplicação NestJS, por exemplo, o controller recebe a requisição já processada pelo servidor HTTP e pelo pipeline correspondente. Antes disso, resolução de nome, transporte, segurança e infraestrutura já participaram do acesso.

A aplicação pode consultar um banco de dados, buscar outro serviço, ler um cache ou executar regras de negócio. Também pode servir um arquivo estático sem realizar todas essas operações.

Não existe uma consulta ao banco obrigatória para cada página acessada.

9. Que HTML o navegador recebe?

Isso depende de como a aplicação foi construída.

HTML estático

A página pode ter sido gerada antes da requisição e estar pronta para ser entregue por uma CDN ou servidor de arquivos.

HTML gerado no servidor

O servidor pode consultar dados e produzir HTML para aquela solicitação. Também pode transmitir partes da resposta progressivamente, conforme ficam disponíveis.

Conteúdo construído no cliente

O HTML inicial pode trazer uma estrutura básica e referências a scripts. Depois que esses scripts são executados, eles buscam dados e constroem parte importante da interface.

Aplicações reais podem combinar essas estratégias. Em projetos com React e Next.js, entender essa divisão ajuda a explicar por que uma página exibe conteúdo antes de todo o JavaScript necessário às suas interações estar pronto.

10. Receber HTML inicia outras operações

A resposta inicial geralmente não contém todos os recursos da página.

Ao processar o HTML, o navegador encontra referências a CSS, JavaScript, imagens e fontes. Esses recursos podem gerar novas requisições, inclusive para outros domínios.

Enquanto recebe e interpreta o documento, o navegador pode descobrir e baixar recursos. Não precisa esperar o HTML inteiro chegar para começar todo o restante.

Por isso, carregar uma página envolve várias operações que se sobrepõem, e não uma única sequência rígida.

Um arquivo necessário descoberto tarde pode atrasar a experiência mesmo quando sua transferência é rápida. Dependências entre recursos também influenciam o carregamento.

11. Como os arquivos se transformam em pixels?

Para entender a renderização, podemos usar este modelo:

1. O HTML é interpretado e forma o DOM.
2. O CSS é interpretado e forma o CSSOM.
3. O navegador calcula os estilos e determina o que precisa ser renderizado.
4. O layout calcula tamanhos e posições.
5. O paint produz as instruções de desenho.
6. A composição combina o conteúdo das camadas para apresentação.

DOM e resultado visual não são a mesma coisa. Um elemento com display: none, por exemplo, pode existir no DOM sem produzir uma caixa no layout.

Também não é necessário concluir o carregamento de todos os recursos para apresentar qualquer conteúdo. Essas etapas podem ocorrer novamente quando chegam dados ou quando o JavaScript altera a página.

Aqui reencontramos os assuntos dos artigos anteriores: alterações no DOM podem gerar trabalho visual, e código pesado na thread principal pode atrasar interações e atualizações.

12. Onde entra o JavaScript?

Durante o carregamento, o navegador também precisa baixar, analisar e executar scripts.

Um script clássico sem async ou defer pode interromper o processamento do HTML enquanto é obtido e executado. Scripts com essas opções e scripts de módulo têm comportamentos próprios.

Essa diferença influencia quando o conteúdo fica disponível e quando o código pode interagir com ele. Não basta olhar apenas para o tamanho do arquivo.

Em uma aplicação React com HTML gerado no servidor, entra também a hidratação: o React conecta sua lógica ao HTML existente para gerenciar aquela interface e suas interações.

Esse HTML precisa ser compatível com o resultado inicial esperado no cliente. Divergências podem produzir erros de hidratação.

Mesmo antes da hidratação, recursos nativos do HTML, como links, podem funcionar. “A página apareceu” e “todas as interações da aplicação estão prontas” são momentos diferentes.

13. Cache muda o caminho das próximas visitas

Uma resposta pode ser reutilizada pelo navegador ou por um cache compartilhado, como uma CDN, conforme suas regras.

Headers como Cache-Control ajudam a definir esse comportamento. Quando é necessário revalidar uma representação armazenada, validadores como ETag podem permitir que o servidor responda sem retransmitir o corpo inteiro.

Isso explica por que visitas diferentes à mesma página podem ter custos distintos.

Também vale evitar uma confusão: o cache de DNS armazena informações de resolução de nomes. O cache HTTP armazena respostas e seus metadados. Eles evitam trabalhos diferentes.

Desabilitar o cache HTTP no DevTools, por exemplo, não significa necessariamente eliminar caches DNS ou impedir a reutilização de conexões.

14. Como observar esse caminho na prática?

Abra o DevTools, acesse a aba Network e navegue para uma página. Procure a requisição do tipo document, correspondente ao HTML principal.

Observe:

• O status e os headers.
• A versão do protocolo, na coluna Protocol.
• A resposta recebida.
• Os recursos descobertos depois.
• As etapas disponíveis na aba Timing.

DNS e estabelecimento de conexão podem não ter duração própria naquela requisição se houve reaproveitamento.

O tempo até o primeiro byte também não corresponde apenas à execução do backend. Ele inclui espera pela resposta através da rede e pode envolver intermediários.

A Navigation Timing API oferece medições relacionadas à navegação. Elas ajudam a distinguir resolução de nome, conexão, resposta e processamento do documento.

Para entender quando o conteúdo aparece e o que ocupa a thread principal, complemente a investigação com uma gravação na aba Performance.

15. Por que isso importa no desenvolvimento?

Imagine uma página lenta. O backend responde rapidamente em um teste isolado, mas a experiência no navegador continua ruim.

O atraso pode estar em novas conexões, redirecionamentos, distância de rede, um recurso descoberto tarde ou JavaScript pesado executando depois da resposta.

Agora imagine o contrário: o frontend é pequeno, mas precisa esperar uma página gerada no servidor que depende de várias consultas sequenciais.

As duas situações podem produzir uma percepção parecida para o usuário, mas exigem intervenções diferentes.

Conhecer o caminho ajuda a formular hipóteses e medir a etapa certa antes de adicionar cache, trocar infraestrutura ou tentar otimizar componentes.

Conclusão

Digitar uma URL pode iniciar um processo que atravessa resolução de nomes, transporte, segurança, HTTP, infraestrutura e execução da aplicação. Depois da resposta, o navegador ainda precisa interpretar os recursos e construir a interface.

Caches, conexões reutilizadas e diferentes estratégias de renderização alteram esse percurso. Por isso, o fluxo serve como um modelo para investigar o sistema, sem representar uma sequência idêntica em toda navegação.

Uma aplicação web não começa no React e não termina no controller do backend.

Entender o caminho completo ajuda a conectar decisões que costumamos discutir separadamente e a encontrar onde realmente está o custo de uma página.

Quando você investiga uma página lenta, costuma começar pelo Network, pelo processamento no navegador ou pelo backend?

Referências

• MDN: URI reference
• RFC 1034: Domain Names, Concepts and Facilities
• RFC 8446: TLS 1.3
• RFC 9114: HTTP/3
• MDN: Overview of HTTP
• MDN: Populating the page, how browsers work
• MDN: Critical rendering path
• MDN: HTTP caching
• MDN: Navigation timing
• React: hydrateRoot