O que acontece quando você digita uma URL no navegador? Parte 1: Da URL à resposta HTTP

Neste artigo

Você digita um endereço, aperta Enter e espera a página aparecer. Quando o JavaScript da aplicação começa a rodar, o navegador já tomou várias decisões: o que solicitar, se precisa acessar a rede e como chegar ao servidor com segurança.

Esse trabalho ajuda a explicar por que uma página parece lenta antes de renderizar o primeiro componente, ou por que uma pessoa vê a versão nova do site enquanto outra continua vendo a de ontem.

Este artigo abre a série Browser e Web Platform com o caminho entre uma URL e uma resposta HTTP. Vamos acompanhar a busca de um documento HTML, relacionando DNS, TLS, HTTP, cache e CDN às demoras que você pode investigar no DevTools. A transformação desse HTML em pixels fica para o próximo artigo.

O navegador não repete todos os passos a cada visita. Respostas em cache, conexões existentes e trabalho antecipado podem encurtar o caminho.

NETWORK EXPLORER

Uma navegação por dentro

example.com/productsHTTPS
01Navegador
https://example.com/products

A barra aceita endereços e pesquisas. Aqui, a entrada é uma URL HTTPS explícita, mesmo sem visita anterior. O navegador identifica esquema, host e caminho; o fragmento fica no cliente.

Explore as etapas
01 / 10
Explore uma etapa ou dê play. Modelo de HTTPS com HTTP/2 e CDN, sem redirecionamentos ou service worker. Animações sem escala de tempo real.

Antes da rede: endereço ou pesquisa?

A barra de endereços também é um campo de busca. Ao digitar um texto e apertar Enter, você pode estar escolhendo um endereço, uma sugestão do histórico ou uma pesquisa. O navegador interpreta a entrada; as regras e sugestões variam entre navegadores e configurações. Não é preciso já ter visitado um site para que seu endereço seja reconhecido.

Uma entrada como “como funciona DNS” normalmente vira uma busca no mecanismo configurado. Nesse caso, o navegador navega para a URL de pesquisa desse serviço. Já um endereço explícito como https://example.com/products?id=123#reviews indica uma navegação para esse host. Se você omitir o esquema, o navegador precisa defini-lo, conforme suas políticas e configurações.

Vamos seguir esse endereço HTTPS como se não houvesse resposta HTTP armazenada, conexão aberta ou informações DNS aproveitáveis. É um cenário didático de partida do zero: na prática, mesmo sua primeira visita pode aproveitar o cache de um resolvedor compartilhado ou de uma CDN. O computador já tem conectividade com a rede; configurar Wi-Fi e obter essa conectividade ficam fora do percurso.

O que o endereço diz ao navegador

Definido o destino, o navegador interpreta as partes da URL. Explore o exemplo:

URLUm endereço, cinco partes
example.com

HTTPS indica HTTP protegido por TLS. O navegador precisa de uma conexão segura para acessar este endereço.

Destino na requisição HTTP
GET /products?id=123
Fica no navegador
#reviews
Origemhttps://example.com:443
Selecione uma parte para explorar sua função. A porta 443 é implícita no HTTPS.

O servidor decide como interpretar o caminho e os parâmetros; eles não precisam corresponder a um arquivo em disco. Já o fragmento fica no navegador: pode orientar a rolagem até um elemento ou ser usado pela aplicação, mas não é enviado no destino da requisição HTTP.

Para uma URL HTTPS, o navegador também determina a origem a partir do esquema, do nome do host e da porta. Neste caso, a origem é https://example.com, com a porta padrão 443. Escrever essa porta explicitamente resulta na mesma origem; trocar HTTPS por HTTP, usar um subdomínio ou escolher a porta 8443 resulta em outra.

Essa distinção importa porque a segurança do navegador usa origens como fronteiras. A política de mesma origem, por exemplo, restringe como um script pode acessar recursos de outra origem. Dois endereços podem pertencer à mesma empresa e ainda assim ter origens diferentes.

Esta navegação precisa da rede?

O navegador pode já ter uma resposta aproveitável no cache HTTP. Dependendo das regras de cache, ele pode reutilizá-la imediatamente ou perguntar ao servidor se a versão armazenada continua atual. No segundo caso, o cache economiza o download, mas ainda exige uma ida à rede.

Um service worker acrescenta outra possibilidade. Se o site tiver um service worker ativo cujo escopo abranja essa navegação, seu código pode tratar a requisição e responder com conteúdo armazenado, acessar a rede ou combinar as duas estratégias. Em uma primeira visita de fato, esse worker ainda não estará instalado para atender à navegação inicial.

Service workers costumam usar a Cache API para armazenar pares de requisição e resposta. Esse armazenamento é separado do cache HTTP: o código da aplicação gerencia suas entradas, e elas não expiram automaticamente conforme os cabeçalhos de cache HTTP. Essa diferença ajuda a investigar sites que continuam exibindo conteúdo antigo mesmo depois de uma mudança nas configurações de cache HTTP.

Existe também o back-forward cache, ou bfcache. Ele pode preservar uma página inteira, incluindo o estado do JavaScript, para restaurá-la quando você volta ou avança no histórico. Sua função é diferente da de um cache de respostas, e ele não é o mecanismo usado em uma navegação comum para um novo endereço digitado na barra.

Daqui em diante, vamos considerar que o navegador precisa buscar o documento pela rede.

Encontrando um servidor com DNS

Para abrir uma nova conexão com example.com, o navegador precisa de um endereço IP. O DNS, sigla de Domain Name System, fornece registros que podem levar a um ou mais endereços IPv4 ou IPv6.

A resposta pode estar no cache do navegador, do sistema operacional ou de um resolvedor recursivo. Esse resolvedor é o serviço que faz consultas DNS em nome do cliente. Dependendo da configuração, o navegador pode acessá-lo por meio do sistema operacional ou diretamente, por exemplo usando DNS sobre HTTPS.

Sem as informações em cache, o resolvedor consulta a hierarquia do DNS a partir dos servidores raiz cujos endereços já conhece pela sua configuração. Veja quem participa de cada troca:

DNSComo o navegador encontra o IP

O navegador conversa com o resolvedor. O resolvedor consulta os outros servidores até encontrar o endereço.

Navegador

Qual é o IP de example.com?

Resolvedor

Vou consultar o DNS para você.

O navegador pede ao resolvedor o IP de example.com. O resolvedor faz as consultas seguintes em nome do navegador.

1 / 5
Exemplo sem cache. 192.0.2.10 é um IP ilustrativo, não o endereço real de example.com. Aliases podem exigir outras consultas.

Se o nome não existir ou a resolução falhar, o navegador não terá um endereço para essa conexão e poderá exibir um erro. Com os endereços em mãos, pode tentar uma conexão. O destino também pode ser uma CDN, em vez da máquina que executa a aplicação.

O DNS ganha relevância quando uma página depende de muitos hosts externos. Fontes, ferramentas de analytics, imagens e widgets podem exigir novas conexões. Uma indicação de DNS-prefetch permite pedir ao navegador que resolva um nome antecipadamente; uma de preconnect também pode preparar a conexão. Elas ajudam em requisições futuras durante o carregamento, mas não têm efeito retroativo sobre a navegação que trouxe o HTML em que foram declaradas.

Abrindo uma conexão segura

Se já houver uma conexão adequada, o navegador pode reutilizá-la. Caso contrário, precisa abrir uma. Os passos dependem da versão do HTTP.

Para HTTPS com HTTP/1.1 ou HTTP/2, o navegador abre uma conexão TCP, normalmente por uma negociação em três etapas: o cliente envia SYN, o servidor responde com SYN/ACK e o cliente confirma o recebimento. O TCP oferece entrega confiável e ordenada de bytes.

Em seguida, o TLS protege essa conexão. Em uma negociação completa típica, o navegador verifica se o certificado do servidor corresponde ao nome solicitado e se sua cadeia de certificados é confiável. Cliente e servidor estabelecem chaves criptográficas para proteger o tráfego e detectar alterações. A autenticação por certificado permite verificar com quem o navegador está se comunicando; só criptografar os dados não comprovaria essa identidade.

O HTTP/3 segue outro caminho. Ele funciona sobre QUIC, que usa UDP e integra o TLS 1.3 ao estabelecimento da conexão. O QUIC fornece os fluxos confiáveis de que o HTTP precisa, portanto o uso de UDP não torna a entrega do HTTP/3 não confiável.

O custo prático está na latência: abrir uma conexão exige trocas pela rede antes que a resposta possa chegar. Reutilizá-la evita repetir essa preparação, e HTTP/2 e HTTP/3 permitem conduzir várias trocas de requisição e resposta simultaneamente na mesma conexão.

Pedindo o documento

Com uma conexão disponível, o navegador pode solicitar nossa página. Uma requisição HTTP/1.1 abreviada seria assim:

GET /products?id=123 HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: pt-BR
Accept-Encoding: gzip, br

A primeira linha solicita o recurso usando GET. Repare que o caminho e os parâmetros estão presentes, mas #reviews ficou de fora.

Os cabeçalhos detalham a requisição. Accept indica os tipos de mídia aceitos, Accept-Language informa preferências de idioma e Accept-Encoding anuncia os formatos de compressão suportados. O navegador também pode incluir cookies quando seus atributos e as políticas do navegador permitem.

HTTP/2 e HTTP/3 usam uma estrutura binária e pseudocabeçalhos como :method e :path no lugar dessa primeira linha textual. O significado da requisição HTTP permanece o mesmo.

O destino pode responder com um redirecionamento e um cabeçalho Location. Nesse caso, o navegador segue a nova URL, possivelmente fazendo outra consulta DNS ou abrindo outra conexão. Mesmo quando reutiliza a conexão, o redirecionamento acrescenta uma requisição antes da chegada do documento final.

De onde vem a resposta

Nossa requisição saiu do navegador, mas pode ser atendida antes de chegar à aplicação. Muitos sites colocam uma rede de distribuição de conteúdo, ou CDN, à frente dos seus servidores. A requisição chega a um servidor de borda, idealmente próximo do usuário em termos de rede. Se ele puder servir uma resposta em cache, não precisará buscar o documento no servidor de origem.

O cache da CDN fica na infraestrutura do site, separado do cache local do navegador. No exemplo, cache hit significa que a borda tem uma resposta que pode reutilizar; cache miss, que precisa buscá-la na origem. Compare os dois caminhos:

CDNAté onde a requisição precisa ir?
Resposta no cache da CDN
GET/products?id=123documento HTML
NavegadorBorda CDNOrigem
requisiçãorespostasem acesso à origem

A borda responde com o conteúdo armazenado.

A borda busca o conteúdo na origem e devolve a resposta.

Troque o cenário para comparar o percurso. Animação ilustrativa, sem representar tempos reais.

Aqui, servidor de origem significa o servidor responsável pelo conteúdo por trás da CDN. É um uso diferente de “origem” daquele conceito de segurança do navegador que vimos antes.

Quando a borda precisa buscar uma resposta, o servidor de origem pode ler um arquivo, renderizar HTML, consultar um banco de dados ou chamar outro serviço. Tudo isso pode contribuir para a espera. Arquivos estáticos são candidatos comuns ao cache da CDN; o HTML também pode ser armazenado quando seus requisitos de personalização e atualização permitem.

É nesse ponto que o tempo até o primeiro byte, ou TTFB, ajuda. Para uma navegação, ele mede a espera desde seu início até a chegada dos primeiros bytes da resposta. Esse intervalo pode incluir redirecionamentos, DNS, abertura da conexão e trabalho no servidor. Ele não isola o tempo de processamento da aplicação.

Um TTFB alto indica onde investigar. Sozinho, não revela se a causa é um servidor distante, uma resposta ausente no cache ou uma consulta lenta ao banco de dados.

Lendo a resposta

A resposta traz um código de status, cabeçalhos e, quando aplicável, um corpo. Na nossa página, o corpo é HTML. Estes são alguns cabeçalhos possíveis, representados no formato HTTP/1.1:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
ETag: "products-v42"
Content-Encoding: br

O status indica que a requisição foi bem-sucedida. Content-Type identifica HTML codificado em UTF-8. Content-Encoding informa que o corpo transferido usa compressão Brotli, que o navegador desfaz antes de interpretar o HTML.

Os campos de cache orientam uma próxima visita. no-cache permite armazenar a resposta, mas exige validá-la antes de reutilizá-la; no-store instrui os caches a não armazená-la. O ETag é um validador. Em uma requisição posterior, o navegador pode enviá-lo no cabeçalho If-None-Match. Se a representação não mudou, uma resposta 304 Not Modified permite reutilizar o corpo armazenado sem baixá-lo novamente.

Outros cabeçalhos afetam a página além desse download. Set-Cookie pede ao navegador que armazene um cookie, sujeito às suas políticas. Content-Security-Policy pode restringir quais scripts e outros recursos a página pode carregar. Essas instruções ajudam a entender por que receber o HTML com sucesso não garante que tudo na página funcionará.

O navegador pode começar a interpretar o HTML enquanto ele chega. Não precisa esperar a resposta inteira para descobrir folhas de estilo, scripts e imagens e iniciar suas requisições. Download e renderização, portanto, se sobrepõem: o navegador pode trabalhar na página enquanto mais partes do documento ainda estão chegando.

Acompanhando o caminho no DevTools

Para observar o processo no Chrome, abra o DevTools antes de navegar e selecione o painel Network. Ative Preserve log se quiser manter os redirecionamentos visíveis entre navegações. Depois, carregue a página e selecione a requisição do documento principal.

Comece por três lugares:

  • Headers mostra a URL, o status e os cabeçalhos da requisição e da resposta. Procure redirecionamentos, o tipo de conteúdo e as instruções de cache.
  • Timing separa a requisição em fases como consulta DNS, conexão, espera e download. Fases ausentes podem indicar informações DNS em cache ou reutilização de conexão.
  • As colunas Protocol e Size ajudam a identificar a versão do HTTP e se a resposta veio de um cache local. Você pode habilitar Protocol pelo menu dos títulos das colunas.
NETWORK / TIMINGOnde o tempo é gasto
InícioTempo decorrido
  1. DNSEncontrar o IP
  2. ConexãoTCP + TLS
  3. EnvioRequest sent
  4. EsperaWaiting (TTFB)
  5. DownloadReceber o corpo
Esquema de uma nova conexão HTTPS sobre TCP, sem escala real. A espera inclui rede e processamento no servidor. Filas e outras fases foram omitidas.

Compare uma visita com um recarregamento. Para testar sem o cache HTTP do navegador, marque Disable cache e mantenha o DevTools aberto. Isso não limpa caches DNS, não garante uma conexão nova, não ignora o cache da CDN e não desativa respostas de service workers. Para ignorar um service worker no Chrome, use Application > Service Workers > Bypass for network.

Também é possível consultar os tempos de navegação do documento atual no Console, depois que a página terminar de carregar:

const [navigation] = performance.getEntriesByType("navigation");

if (navigation) {
  console.table({
    dnsMs: navigation.domainLookupEnd - navigation.domainLookupStart,
    connectionMs: navigation.connectEnd - navigation.connectStart,
    navigationTtfbMs: navigation.responseStart - navigation.startTime,
    requestToFirstByteMs: navigation.responseStart - navigation.requestStart,
    downloadMs: navigation.responseEnd - navigation.responseStart,
  });
}

Os valores estão em milissegundos. O intervalo de conexão inclui a preparação da conexão segura quando aplicável. O TTFB da navegação abrange mais etapas do que o intervalo entre a requisição e o primeiro byte, então não se deve somar essas linhas. Valores zerados podem indicar etapas dispensadas ou reutilizadas, e restrições de privacidade do navegador podem limitar o detalhamento.

No painel Network, Waiting (TTFB) representa a espera pela resposta depois do envio da requisição. É um intervalo mais restrito que o TTFB da navegação calculado acima. Distinguir esses pontos de partida evita atribuir toda a espera ao processamento do servidor.

Quando você consegue localizar a demora, pode escolher uma correção pertinente: remover um redirecionamento, ajustar uma política de cache ou investigar o servidor. O próximo artigo, Do HTML aos pixels: DOM, CSSOM e a árvore de renderização, acompanha o HTML dentro do navegador: como ele constrói as estruturas do documento e dos estilos, combina essas informações e calcula o layout que prepara a página para a pintura.

Para se aprofundar