HTTP/1.1, HTTP/2 e HTTP/3: o que mudou de verdade

Nos posts sobre DNS, load balancing e edge functions, a requisição HTTP aparece sempre como uma caixa preta que sai do navegador e chega no servidor. Vale abrir essa caixa, porque a versão do protocolo muda o jeito de otimizar um site, e várias dicas antigas de performance simplesmente deixaram de valer.

HTTP/1.1: uma requisição de cada vez por conexão

No HTTP/1.1, cada conexão TCP atende uma requisição por vez. O navegador pede o HTML, espera a resposta completa, e só então pede o próximo arquivo naquela conexão. Se o primeiro arquivo da fila demora, tudo que vem depois fica parado esperando, um problema chamado head-of-line blocking.

A solução paliativa foi o navegador abrir várias conexões em paralelo pro mesmo domínio, geralmente seis. Funciona, mas cada conexão tem custo de abertura (lembra do handshake do pool de conexões com banco? o princípio é o mesmo), e seis ainda é pouco pra uma página com dezenas de recursos.

Daí nasceram as otimizações típicas dessa época:

Juntar todos os arquivos CSS e JS num só, pra fazer menos requisições.
Usar sprites de imagem, reunindo vários ícones numa única imagem.
Espalhar recursos por vários subdomínios pra burlar o limite de seis conexões.

HTTP/2: várias requisições na mesma conexão

O HTTP/2 mudou o jeito de transportar os dados. Em vez de uma requisição por vez, ele faz multiplexação: várias requisições e respostas viajam intercaladas na mesma conexão, divididas em pequenos quadros que são remontados no destino.

HTTP/1.1:  [HTML........][CSS....][JS..........]   (em fila)
HTTP/2:    [HTML][CSS][JS][HTML][JS][CSS]...        (intercalado)

Com isso, uma única conexão por domínio basta, e um arquivo lento deixa de travar os outros no nível do protocolo. Outras melhorias vieram junto: compressão dos cabeçalhos (que se repetem muito de requisição em requisição) e o server push, que na prática acabou pouco usado e foi removido de vários navegadores.

O efeito prático: aquelas otimizações do HTTP/1.1 perderam o sentido, e algumas até atrapalham. Juntar tudo num arquivo gigante significa que mudar uma linha de CSS invalida o cache de tudo. Com HTTP/2, vale mais dividir em arquivos menores e cacheáveis separadamente.

O que o HTTP/2 ainda não resolveu

O HTTP/2 elimina o bloqueio no nível das requisições, mas continua rodando sobre TCP, e o TCP garante entrega em ordem. Se um único pacote se perde no caminho, o TCP segura todos os dados seguintes da conexão até aquele pacote ser reenviado. Como todas as requisições dividem a mesma conexão, a perda de um pacote trava todas ao mesmo tempo. Em rede instável, como o 4G no meio da rua, isso pode ser pior que as seis conexões do HTTP/1.1.

HTTP/3: trocando o TCP pelo QUIC

O HTTP/3 resolve isso trocando a base. Em vez de TCP, usa o QUIC, que roda sobre UDP e trata cada fluxo de requisição de forma independente. Se um pacote se perde, só o fluxo afetado espera a retransmissão, e os outros seguem normalmente.

O QUIC traz outros ganhos:

Handshake mais curto: a conexão e a criptografia (TLS 1.3) são negociadas juntas, economizando idas e vindas antes do primeiro byte.
Migração de conexão: a conexão é identificada por um ID, não pelo par de IP e porta. Quando o celular troca do Wi-Fi pro 4G, a conexão continua, sem recomeçar do zero.

O que isso muda pra você na prática

Na maior parte do tempo, nada que você precise programar. A versão é negociada automaticamente entre navegador e servidor, e plataformas como Vercel e Cloudflare já servem HTTP/2 e HTTP/3 por padrão. O que muda é o raciocínio de otimização:

Não gaste esforço juntando arquivos só pra reduzir o número de requisições.
Prefira arquivos menores e com cache bem configurado.
Confira se o seu servidor ou CDN suporta HTTP/2 e HTTP/3. Na aba Network do DevTools, dá pra ativar a coluna Protocol e ver h2 ou h3 em cada requisição.

Fechando

Cada versão do HTTP nasceu de um gargalo concreto da anterior: o HTTP/2 atacou o bloqueio entre requisições, e o HTTP/3 atacou o bloqueio causado pelo TCP. Saber disso evita aplicar regras de uma época que já passou e ajuda a entender por que um site pode ficar mais rápido só por trocar de servidor ou de CDN, sem mudar uma linha de código.