Tutoriais

Como funciona uma página web do navegador ao servidor

Do DNS ao rendering: entenda o que acontece entre digitar uma URL e a página aparecer — TCP, TLS, HTTP request/response e como o navegador monta os pixels.

Rafael Duarte

EDITOR TÉCNICO

Published

13 de jun. de 2026

Reading time

8 min

13 de jun. de 2026 · 8 MIN

COVER · Tutoriais

Você digita https://exemplo.com no navegador, pressiona Enter, e meio segundo depois aparece uma página. Parece mágica. Não é. São uns seis ou sete passos bem definidos que acontecem tão rápido que a maioria das pessoas nunca se pergunta o que ocorre entre o Enter e o carregamento. Se você está começando na web e quer entender de verdade o que rola nesse intervalo, este post é pra você.

O que acontece quando você digita uma URL

A URL (Uniform Resource Locator) é um endereço. https://exemplo.com/contato tem três partes principais: o protocolo (https), o domínio (exemplo.com), e o caminho (/contato).

Antes de qualquer request sair do seu computador, o navegador precisa transformar exemplo.com em um endereço IP — porque a internet não trabalha com nomes bonitos, trabalha com números. E pra isso ele precisa do DNS.

O que é DNS e por que ele existe

DNS (Domain Name System) é a agenda de contatos da internet. Você procura por exemplo.com, ele te devolve 93.184.216.34.

Quando você digita a URL, o navegador primeiro checa o cache local — se você acessou esse site recentemente, o IP pode já estar salvo. Se não estiver, ele pergunta ao servidor DNS configurado no seu sistema (geralmente o da sua operadora ou um público como 8.8.8.8 do Google).

Esse servidor DNS faz uma série de consultas hierárquicas:

Sabe quem é responsável por .com? (root servers)
Sabe quem é responsável por exemplo.com? (TLD servers)
Qual é o IP de exemplo.com? (name server autoritativo)

No fim das consultas, você tem o IP. Esse processo inteiro costuma levar menos de 100ms — mas é um roundtrip de rede que acontece mesmo antes de o request principal sair.

A conexão TCP e o handshake TLS

Com o IP em mãos, o navegador precisa abrir uma conexão com o servidor. Ele usa TCP (Transmission Control Protocol), que garante que os pacotes cheguem na ordem certa e sem perda.

Isso envolve o famoso three-way handshake:

Cliente → Servidor: SYN
Servidor → Cliente: SYN-ACK
Cliente → Servidor: ACK

Três mensagens antes de mandar qualquer coisa útil. Com HTTPS (que é HTTP sobre TLS), tem mais um passo: o TLS handshake, onde cliente e servidor negociam algoritmos de criptografia e trocam chaves. Esse processo garante que os dados trafegam criptografados — ninguém no meio do caminho consegue ler o que você está enviando ou recebendo.

É por isso que HTTPS importa mesmo em sites "simples". Não é só sobre login e senha — é sobre não expor dados de navegação pra qualquer roteador no caminho.

O HTTP request

Com a conexão estabelecida, o navegador finalmente manda o HTTP request. Uma request básica de GET parece assim:

GET /contato HTTP/1.1
Host: exemplo.com
Accept: text/html,application/xhtml+xml
Accept-Language: pt-BR,pt;q=0.9
User-Agent: Mozilla/5.0 ...

Alguns campos importantes:

Method: GET busca conteúdo, POST envia dados, PUT/PATCH atualiza, DELETE remove
Host: necessário porque um mesmo servidor pode hospedar vários domínios
Headers: metadados da request — o que o browser aceita, qual idioma prefere, cookies, tokens de autenticação

A response do servidor

O servidor recebe a request, processa (pode consultar banco de dados, rodar código, buscar arquivos), e devolve uma HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 12458
Cache-Control: max-age=3600

<!DOCTYPE html>
<html lang="pt-BR">
...

Os primeiros três dígitos são o status code — talvez o conceito mais útil de HTTP pra quem está começando:

Faixa	Significado	Exemplos
2xx	Sucesso	200 OK, 201 Created
3xx	Redirecionamento	301 Moved Permanently, 304 Not Modified
4xx	Erro do cliente	404 Not Found, 401 Unauthorized, 403 Forbidden
5xx	Erro do servidor	500 Internal Server Error, 503 Service Unavailable

Um 404 significa que o recurso não existe no servidor — não é um problema de conexão. Um 500 significa que o servidor explodiu por conta própria. Um 301 significa que a URL foi movida permanentemente para outro endereço. Cada código conta uma história diferente, e entender isso economiza bastante tempo de debug.

O navegador renderiza o HTML

O servidor mandou o HTML. Agora o navegador precisa transformar isso em pixels na tela. Esse processo tem um nome: rendering pipeline, e funciona mais ou menos assim:

1. Parsing do HTML → DOM

O navegador lê o HTML de cima pra baixo e constrói o DOM (Document Object Model) — uma árvore de objetos representando cada elemento da página. Uma <div> vira um nó, um <p> vira outro, e assim por diante.

Durante esse processo, se o browser encontra uma tag <link> de CSS ou <script>, ele dispara novos requests para buscar esses arquivos.

2. Parsing do CSS → CSSOM

O CSS baixado também é parseado numa árvore paralela: o CSSOM (CSS Object Model). Aqui ficam as regras de estilo associadas a cada seletor.

3. Render tree

DOM + CSSOM são combinados numa render tree — só os elementos visíveis, com seus estilos calculados. Um elemento com display: none nem entra nessa árvore.

4. Layout

O browser calcula a posição e tamanho de cada elemento na tela. Esse passo é caro — qualquer mudança no tamanho de um elemento pode afetar o layout de elementos vizinhos.

5. Paint e composite

Por último, os elementos são desenhados em camadas e compostos na tela final. É o que você vê.

O papel do JavaScript

HTML e CSS são declarativos — você descreve o que quer, o browser renderiza. JavaScript é diferente: é código que executa no browser.

Scripts bloqueiam o parsing do HTML por padrão. Se o browser encontra um <script> no <head> sem async ou defer, ele para de processar o HTML, baixa o script, executa, e só então continua. É por isso que scripts pesados no <head> deixam a página lenta.

<!-- Bloqueia o rendering: -->
<script src="app.js"></script>

<!-- Não bloqueia, executa quando disponível: -->
<script src="app.js" async></script>

<!-- Não bloqueia, executa após o HTML ser parseado: -->
<script src="app.js" defer></script>

Para a maioria dos scripts, defer é a escolha mais segura.

Cache: o que o navegador guarda

Requests são caros. O protocolo HTTP tem mecanismos para evitar que o browser baixe o mesmo recurso duas vezes:

Cache-Control: o servidor diz por quanto tempo o browser pode guardar o recurso (max-age=3600 = 1 hora)
ETag: um "fingerprint" do recurso. Na próxima request, o browser manda a ETag; se não mudou, o servidor responde com 304 Not Modified e sem body — economizando banda
Last-Modified: similar ao ETag, mas baseado em data de modificação

Na prática, arquivos de imagem e CSS com hash no nome (como app.abc123.css) podem ter max-age longo porque o hash muda quando o arquivo muda — forçando o browser a baixar a versão nova.

Perguntas frequentes

Por que alguns sites demoram mais para carregar?

Vários fatores: servidor fisicamente distante (latência de rede), muitos recursos para baixar (JS, CSS, imagens), JavaScript bloqueando o rendering, ausência de cache, ou CDN não configurado. A distância física entre cliente e servidor ainda é um dos maiores fatores — requisições têm velocidade finita.

O que é HTTPS e por que importa?

HTTPS é HTTP com TLS. Todo o conteúdo da comunicação é criptografado: URL, headers, body. Sem HTTPS, qualquer nó no caminho (roteador, provedor) consegue ler e modificar o que trafega. Browsers modernos marcam sites HTTP como "não seguros" e alguns recursos (geolocation, service workers) só funcionam em HTTPS.

Qual a diferença entre HTTP/1.1, HTTP/2 e HTTP/3?

HTTP/1.1 abre uma conexão por request (ou mantém conexões paralelas, com limite por domínio). HTTP/2 multiplexa várias requests numa mesma conexão TCP — significativamente mais eficiente. HTTP/3 substitui TCP por QUIC (baseado em UDP), reduzindo latência especialmente em conexões instáveis. Para o desenvolvedor web iniciante, a diferença prática é: sites modernos usam HTTP/2 ou HTTP/3 transparentemente, sem nada a configurar.

O que é um CDN?

CDN (Content Delivery Network) é uma rede de servidores distribuídos geograficamente. Em vez de todo mundo baixar os arquivos estáticos do servidor em São Paulo, usuários na Europa baixam de um servidor em Frankfurt. Latência menor, carregamento mais rápido. É por isso que grandes sites funcionam bem no mundo inteiro — eles replicam o conteúdo perto de quem vai consumir.

A pilha completa em menos de um segundo

Na prática, tudo isso — resolução DNS, handshake TCP/TLS, request HTTP, response, parsing HTML/CSS, download de recursos, execução de JS, rendering — acontece em frações de segundo. Um site bem otimizado carrega em menos de 1 segundo. Um site mal otimizado pode levar 10 segundos fazendo exatamente os mesmos passos, só que de forma ineficiente.

Quando uma page não abre, travar numa dessas etapas é o diagnóstico. DNS não resolve? Problema de DNS. Conexão recusada? Servidor fora. Status 500? Problema no servidor. Página branca com JS ativo? Erro de script. Entender a sequência é entender onde procurar.

Para ver na prática os status codes que o servidor devolve em cada situação, uso o HTTP Status Codes do Quick Tools — útil para consultar rapidamente o que cada código significa quando aparece num log ou no DevTools do browser.

Author

Rafael Duarte

Desenvolvedor backend com passagem por fintech e SaaS B2B — trabalhou em times que escalaram APIs de zero a milhões de requisições. Carrega cicatrizes de produção suficientes para ter opiniões fortes sobre ferramentas, padrões e decisões de arquitetura. Não é acadêmico: leu a RFC do UUID quando precisou escolher entre v4 e v7 para uma tabela de alta escrita.

View profile