103 Early Hints

A RFC 8297 (2017) define o 103 como forma de enviar cabeçalhos que provavelmente estarão na resposta final. São só dicas: o cliente não pode tratá-los como metadados do próprio 103, e o servidor pode enviar mais de um 103 antes do status final, por exemplo quando uma CDN acrescenta os seus.

O suporte nos navegadores é mais estreito que a especificação. Segundo a documentação do Chrome, Chrome e Edge usam dicas de preconnect e preload desde a versão 103, o Firefox suporta preconnect desde a 120 e preload desde a 123, e o Safari 17 só suporta preconnect. As dicas valem apenas para navegações de página inteira, prefetch é ignorado e a maioria dos navegadores só as aceita em HTTP/2 ou HTTP/3.

O Early Hints assumiu o papel que o Server Push do HTTP/2 deveria cumprir. O Push mandava os bytes mesmo que o navegador já os tivesse em cache; o 103 só aponta os recursos e deixa o navegador decidir, ao custo de uma ida e volta a mais.

• Páginas em que o servidor demora para pensar: HTML renderizado no servidor que espera banco de dados ou API antes do primeiro byte.
• Indique só recursos que toda visita usa e cujas URLs são estáveis: a folha de estilo principal, uma fonte, preconnect para sua CDN ou servidor de fontes.
• Envie apenas em navegações (Sec-Fetch-Mode: navigate) sobre HTTP/2 ou HTTP/3, como o Chrome recomenda, e repita os mesmos cabeçalhos Link na resposta final para clientes que ignoraram o 103.

Se você administra o servidor

• O Early Hints está configurado, mas o DevTools não mostra ganho: a conexão é HTTP/1.1, o pedido não é uma navegação ou a dica usa rel=prefetch.
• O navegador baixa um arquivo duas vezes: a URL indicada (por exemplo app.3f9c.css) não bate mais com o nome com hash no HTML depois de um deploy.
• Um cliente ou proxy HTTP/1.1 antigo quebra com o 1xx inesperado; a RFC 8297, seção 3, avisa exatamente sobre isso.

Se você administra o servidor

• Gere a lista de dicas a partir do mesmo manifest do build que escreve o HTML, assim os nomes com hash sempre batem.
• Envie o 103 só em HTTP/2 ou HTTP/3 e com Sec-Fetch-Mode: navigate; no nginx 1.29+ use early_hints $http2$http3.
• Confira com curl -v --http2 https://example.com/: o bloco 103 com as linhas Link deve aparecer antes do 200.

Route handlers do Next.js e o FastAPI não emitem 103. Coloque na frente uma CDN ou proxy que gere Early Hints a partir dos cabeçalhos Link das respostas finais, como a Cloudflare faz.

app.get('/', async (req, res) => {
  // Node 18.11+: flushes "103 Early Hints" immediately
  res.writeEarlyHints({
    link: [
      '</assets/app.css>; rel=preload; as=style',
      '<https://fonts.gstatic.com>; rel=preconnect'
    ]
  });
  const html = await renderPage(); // the slow part
  res.send(html);
});

mux.HandleFunc("GET /{$}", func(w http.ResponseWriter, r *http.Request) {
	w.Header().Add("Link", "</assets/app.css>; rel=preload; as=style")
	w.Header().Add("Link", "<https://fonts.gstatic.com>; rel=preconnect")
	w.WriteHeader(http.StatusEarlyHints) // 103 goes out now (Go 1.19+)

	html := renderPage() // the slow part
	// The Link headers stay in the map and are repeated on the 200.
	w.Header().Set("Content-Type", "text/html; charset=utf-8")
	w.WriteHeader(http.StatusOK)
	w.Write(html)
})

# nginx 1.29.0+: pass the app's 103 to HTTP/2 and HTTP/3 clients only
location / {
  early_hints $http2$http3;
  proxy_pass http://app;
}

103 vs 200

Cabeçalhos Link no 200 também funcionam, mas só quando a página está pronta; o 103 entrega as mesmas dicas enquanto o servidor ainda processa.

103 vs 100

O 100 Continue responde ao Expect do cliente sobre enviar o corpo; o 103 vem sem ser pedido e trata da resposta que o cliente vai receber.

Quais navegadores suportam o 103 Early Hints?

Chrome e Edge 103+ suportam preconnect e preload. O Firefox suporta preconnect desde a 120 e preload desde a 123. O Safari 17 suporta apenas preconnect. Todos aplicam as dicas só em navegações de página.

O 103 Early Hints substitui o Server Push do HTTP/2?

Na prática, sim. O Chrome desligou o Server Push por padrão em 2022 e indicou o Early Hints no lugar, que deixa o navegador pular recursos que já tem em cache em vez de recebê-los de qualquer jeito.

A resposta final deve repetir os cabeçalhos Link?

Sim. Navegadores que ignoraram o 103, e caches que guardam a resposta final, só enxergam os cabeçalhos do 200. A orientação do Chrome é manter os Link também na resposta final.

É seguro enviar 103 em HTTP/1.1?

É arriscado. Alguns clientes HTTP/1.1 antigos não esperam uma resposta informativa que não pediram e interpretam o fluxo errado. A RFC 8297 e a documentação do nginx sugerem limitar o uso a HTTP/2 e HTTP/3.