103 Early Hints: Pré-carregue Recursos Críticos Durante o Tempo de Processamento do Servidor

Última revisão por Arjen Karel em março de 2026

O que são 103 Early Hints?

Early Hints é um código de status HTTP (103) enviado antes do servidor web enviar a resposta final. Permite ao servidor informar o navegador, no início do processo de carregamento, que certos recursos como uma imagem ou uma folha de estilos são críticos para a renderização da página.

A maioria das páginas dinâmicas demora tempo a gerar. O servidor consulta uma base de dados, executa lógica de aplicação e monta o HTML. Durante esse tempo de processamento, o navegador apenas espera. 103 Early Hints preenchem essa lacuna ao informar o navegador sobre o que descarregar enquanto espera pela resposta real.

Early Hints substituem o descontinuado HTTP/2 Server Push, que o Chrome removeu na versão 106. O Server Push incluía recursos com a resposta final e frequentemente enviava bytes que o navegador já tinha em cache. Early Hints evitam esse problema porque apenas sugerem; o navegador decide se age com base nelas.

Suporte de navegadores

103 Early Hints é suportado por 93% dos navegadores globalmente:

• Chrome 103+ e Edge 103+: suporte completo para preconnect e preload (desde junho de 2022)
• Firefox 123+: suporte completo para preconnect e preload (desde fevereiro de 2024)
• Safari 17+: apenas preconnect. O Safari não suporta preload em respostas 103

A limitação do Safari é importante. Se a sua estratégia de Early Hints depende inteiramente do pré-carregamento de imagens ou fontes, os utilizadores do Safari não beneficiarão. Inclua hints de preconnect juntamente com hints de preload para que o Safari pelo menos aqueça a ligação às origens dos seus recursos.

Early Hints só funcionam sobre HTTP/2 ou HTTP/3. Não funcionam sobre HTTP/1.1, a partir de iframes, ou para pedidos que não sejam de navegação. O navegador processa hints apenas para preload e preconnect; dns-prefetch e prefetch não são suportados em respostas 103.

Como são os 103 Early Hints?

Quando um navegador solicita uma página, o servidor retorna imediatamente uma resposta 103 antes de ter terminado de gerar o HTML. Esta resposta diz ao navegador para começar a descarregar a imagem LCP e a folha de estilos:

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Entretanto, o servidor gera a página. Quando está pronta, envia a resposta final:

HTTP/2 200 OK
Content-Length: 1234
[the rest of the response]

Quando o navegador recebe a resposta 200, já começou a descarregar a imagem e a folha de estilos. Essa vantagem inicial é o que torna o Largest Contentful Paint mais rápido.

Como enviar 103 Early Hints

Tem três opções principais, da mais fácil à de maior controlo.

Cloudflare (mais fácil)

Se já usa Cloudflare para performance, ativar Early Hints é um único interruptor. Navegue até Speed > Settings > Content Optimization e ative Early Hints. Está disponível em todos os planos, incluindo o gratuito.

O Cloudflare faz cache dos headers Link das respostas 200 da sua origem. Em pedidos subsequentes, envia esses headers em cache como uma resposta 103 antes de encaminhar o pedido para a sua origem. Fornece as hints enviando headers Link a partir da sua aplicação:

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (nativo desde 1.29.0)

O NGINX adicionou suporte nativo a 103 Early Hints na versão 1.29.0 (junho de 2025). A diretiva early_hints encaminha respostas 103 do seu backend para o cliente:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

O mapa sec-fetch-mode garante que as hints são enviadas apenas para pedidos de navegação sobre HTTP/2 ou HTTP/3. A sua aplicação backend deve gerar a resposta 103; o NGINX encaminha-a.

Apache (2.4.58+)

O Apache pode gerar respostas 103 por si próprio usando mod_http2. Ative-o com a diretiva H2EarlyHints e defina os recursos a sugerir:

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

Ao contrário do NGINX, o Apache gera a resposta 103 ao nível do servidor sem precisar que a sua aplicação a produza.

Quando Early Hints ajudam (e quando não ajudam)

103 Early Hints são mais eficazes quando o seu servidor demora tempo perceptível a responder: páginas dinâmicas que consultam bases de dados, chamam APIs ou renderizam templates. Quanto mais lento o Time to First Byte, mais tempo o navegador tem para agir com base nas hints.

Early Hints proporcionam menos benefício quando:

• O seu servidor responde em menos de 100ms. Se o TTFB já é rápido, não há lacuna para o navegador preencher. Concentre-se na priorização de recursos no seu HTML.
• As páginas são servidas a partir de cache. Uma resposta HTML totalmente em cache carrega tão rapidamente que a resposta 103 quase não tem vantagem.
• Sugere demasiados recursos. Sugerir 10+ recursos satura a ligação e pode abrandar as coisas. A Shopify descobriu que em dispositivos móveis, hints agressivas levaram a degradação de performance em TTFB, FCP e LCP. Mantenha-se em 2 a 4 recursos críticos.

Apesar de 93% de suporte nos navegadores, a adoção permanece baixa. De acordo com o 2025 Web Almanac, apenas cerca de 5% dos principais sites usam 103 Early Hints. A principal barreira é saber quais recursos sugerir para cada página, algo que a maioria dos CMS não trata automaticamente.

Como verificar se Early Hints estão a funcionar

Abra o Chrome DevTools, vá ao painel Network e recarregue a página. Clique no pedido do documento e verifique os headers de resposta. Se Early Hints estiverem a funcionar, verá um status 103 antes do 200 na análise de timing.

A partir da linha de comandos, pode verificar com curl:

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

Deverá ver tanto uma resposta 103 como uma 200.

Resultados dos testes

Testei dois cenários para medir o impacto no First Contentful Paint e no Largest Contentful Paint.

1. Early Hints apenas na imagem LCP

A imagem LCP apareceu no ecrã 35% mais cedo com 103 Early Hints comparado com um preload regular no HTML.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. Early Hints com uma folha de estilos grande e a imagem LCP

Adicionar um ficheiro CSS de 85kb às hints tornou a diferença ainda mais notável. O FCP melhorou de 1,8 segundos para 1,4 segundos, e o LCP melhorou de 3,2 segundos para 2,0 segundos.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Estes números estão alinhados com o que a Cloudflare mediu em mais de 100.000 clientes: uma melhoria de LCP de 6% no percentil 50 e 16% no percentil 75 em desktop. A Shopify viu uma melhoria de 500ms no LCP no p50 durante a Black Friday e Cyber Monday. Os maiores ganhos vêm em páginas com tempos de resposta do servidor lentos, que é exatamente quando Early Hints têm mais tempo para funcionar.

Early Hints e TTFB

Há uma nuance de medição a ter em conta. Desde o Chrome 133, o timing responseStart do navegador (usado pela maioria das ferramentas para reportar o TTFB) inclui a resposta 103. Isto significa que o seu TTFB reportado vai baixar após ativar Early Hints, embora o tempo real de processamento do servidor não tenha mudado.

Se precisar de medir o tempo de processamento do servidor separadamente, o Chrome 133 introduziu um novo timestamp firstResponseHeadersStart que reporta quando os headers finais da resposta 200 chegam. Ferramentas de Real User Monitoring que registam ambos os valores dão-lhe a imagem completa: quanto tempo Early Hints pouparam ao navegador e quanto tempo o seu servidor realmente demorou a responder.