Saiba como seu servidor pode enviar dicas ao navegador sobre sub-recursos críticos.
Publicado em 23 de junho de 2022, atualizado pela última vez em 10 de julho de 2026
O que são as dicas iniciais?
Os sites se tornaram mais sofisticados com o tempo. Por isso, não é incomum que um servidor precise realizar um trabalho não trivial (por exemplo, acesso a bancos de dados ou CDNs que acessam o servidor de origem) para produzir o HTML da página solicitada. Infelizmente, esse "tempo de processamento do servidor" resulta em latência extra antes que o navegador possa começar a renderizar a página. De fato, a conexão fica inativa pelo tempo necessário para o servidor preparar a resposta.
As dicas iniciais são um código de status HTTP (103 Early Hints) usado para enviar uma resposta HTTP preliminar antes de uma resposta final. Isso permite que um servidor envie dicas ao navegador sobre sub-recursos críticos (por exemplo, folhas de estilo da página, JavaScript crítico) ou origens que provavelmente serão usadas pela página, enquanto o servidor está ocupado gerando o recurso principal. O navegador pode usar essas dicas para aquecer as conexões e solicitar sub-recursos enquanto aguarda o recurso principal. Em outras palavras, as dicas iniciais ajudam o navegador a aproveitar esse "tempo de processamento do servidor" fazendo algum trabalho com antecedência, acelerando assim os carregamentos de página.
Em alguns casos, a melhoria de desempenho no Largest Contentful Paint pode variar de várias centenas de milissegundos, conforme observado pela Shopify e pela Cloudflare, e até um segundo mais rápido, como mostrado nesta comparação antes e depois:
Como usar dicas iniciais
A primeira etapa para aproveitar as dicas iniciais consiste em identificar as principais páginas de destino, ou seja, as páginas em que os usuários normalmente começam quando visitam seu site. Essa pode ser a página inicial ou páginas de informações do produto populares se você tiver muitos usuários acessando de outros sites. O motivo pelo qual esses pontos de entrada são mais importantes do que outras páginas é que a utilidade das dicas iniciais diminui à medida que o usuário navega pelo site (ou seja, é mais provável que o navegador tenha todos os sub-recursos necessários na segunda ou terceira navegação subsequente). Também é sempre uma boa ideia causar uma ótima primeira impressão.
Agora que você tem essa lista priorizada de páginas de destino, a próxima etapa é identificar quais origens ou sub-recursos seriam bons candidatos para preconnect ou preload dicas. Normalmente, essas seriam origens e sub-recursos que mais contribuem para as principais métricas do usuário, como Largest Contentful Paint ou First Contentful Paint. Mais concretamente, procure sub-recursos de bloqueio de renderização, como JavaScript síncrono, folhas de estilo ou até mesmo fontes da Web. Da mesma forma, procure origens que hospedam sub-recursos que contribuem muito para as principais métricas do usuário.
Além disso, se seus recursos principais já estiverem usando preconnect ou preload, considere essas origens ou recursos entre os candidatos para dicas iniciais. Consulte Como otimizar a LCP para mais detalhes. No entanto, copiar ingenuamente as diretivas preconnect e preload do HTML para dicas iniciais pode não ser ideal.
Ao usar esses recursos em HTML, geralmente você quer preconnect ou preload recursos que o scanner de pré-carregamento não vai descobrir no HTML, por exemplo, fontes ou imagens de plano de fundo que seriam descobertas tarde. Para dicas iniciais, você não terá o HTML. Portanto, talvez seja melhor preconnect para domínios críticos ou preload recursos críticos que talvez seriam descobertos no HTML, por exemplo, pré-carregar main.css ou app.js. Além disso, nem todos os navegadores oferecem suporte a preload para dicas iniciais. Consulte Suporte ao navegador.
A segunda etapa consiste em minimizar o risco de usar dicas iniciais em recursos ou origens que podem estar obsoletos ou não serem mais usados pelo recurso principal. Por exemplo, recursos que são atualizados e versionados com frequência (por exemplo, example.com/css/main.fa231e9c.css) podem não ser a melhor escolha. Essa preocupação não é específica para dicas iniciais. Ela se aplica a qualquer preload ou preconnect em que estiver presente. Esse tipo de detalhe é melhor tratado com automação ou modelos (por exemplo, um processo manual tem mais probabilidade de levar a URLs de hash ou versão incompatíveis entre preload e a tag HTML real que usa o recurso).
Como exemplo, considere o fluxo a seguir:
GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
O servidor prevê que main.abcd100.css será necessário e sugere o pré-carregamento usando dicas iniciais:
103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]
Alguns instantes depois, a página da Web, incluindo o CSS vinculado, é veiculada. Infelizmente, esse recurso CSS é atualizado com frequência, e o recurso principal já está cinco versões à frente (abcd105) do recurso CSS previsto (abcd100).
200 OK
[...]
<HTML>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.abcd105.css">
Em geral, procure recursos e origens que sejam bastante estáveis e amplamente independentes do resultado do recurso principal. Se necessário, considere dividir seus principais recursos em duas partes: uma parte estável projetada para ser usada com dicas iniciais e uma parte mais dinâmica deixada para ser buscada depois que o recurso principal for recebido pelo navegador:
<html>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.css">
<link rel="stylesheet" href="/experimental.3eab3290.css">
Por fim, no lado do servidor, procure solicitações de recursos principais enviadas por navegadores conhecidos por oferecer suporte a dicas iniciais e responda imediatamente com 103 dicas iniciais. Na resposta 103, inclua as dicas de pré-conexão e pré-carregamento relevantes. Quando o recurso principal estiver pronto, siga com a resposta normal (por exemplo, 200 OK se for bem-sucedida). Para compatibilidade com versões anteriores, é recomendável incluir também cabeçalhos HTTP Link na resposta final, talvez até mesmo aumentando com recursos críticos que se tornaram evidentes como parte da geração do recurso principal (por exemplo, a parte dinâmica de um recurso principal se você seguiu a sugestão "dividir em duas"). Confira como isso seria:
GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Alguns instantes depois:
200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.css">
<link rel="stylesheet" href="/experimental.3eab3290.css">
<script src="/common.js"></script>
<link rel="preconnect" href="https://fonts.googleapis.com">
Suporte ao navegador
Embora as 103 dicas iniciais sejam compatíveis com todos os principais navegadores, as diretivas que podem ser enviadas em uma dica inicial variam de acordo com o navegador:
Suporte a pré-conexão :
Browser Support
Suporte a pré-carregamento :
Browser Support
O Chrome DevTools também oferece suporte a 103 dicas iniciais, e os cabeçalhos Link podem ser vistos nos recursos do documento:
Link dicas iniciais são mostrados no Chrome DevTools.Observação: para usar os recursos de dicas iniciais, Disable cache não pode ser marcada no DevTools, porque as dicas iniciais usam o cache do navegador. Para recursos pré-carregados, o iniciador será mostrado como Early-hints e o tamanho como (Disk cache):
early-hints e são carregados do cache em disco.Isso também exige um certificado confiável para testes HTTPS.
O Firefox não tem suporte explícito para 103 dicas iniciais como um iniciador no DevTools, mas os recursos carregados usando dicas iniciais são mostrados como cached na coluna Transferido e, quando clicados, têm um cabeçalho da solicitação HTTP X-Moz: early hint.
Suporte a servidor
Confira um resumo rápido do nível de suporte para dicas iniciais entre softwares de servidor HTTP de código aberto populares:
- Apache:com suporte usando mod_http2.
- H2O: com suporte.
- NGINX:com suporte.
- Node:com suporte para http e http2
Ativar dicas iniciais da maneira mais fácil
Se você estiver usando uma das seguintes CDNs ou plataformas, talvez não seja necessário implementar dicas iniciais manualmente. Consulte a documentação on-line do provedor de soluções para saber se ele oferece suporte a dicas iniciais ou consulte a lista não exaustiva aqui:
Como evitar problemas para clientes que não oferecem suporte a dicas iniciais
As respostas HTTP informativas no intervalo de 100 fazem parte do padrão HTTP, mas alguns clientes ou bots mais antigos podem ter dificuldades com elas porque, antes do lançamento de 103 dicas iniciais, elas eram raramente usadas para navegação geral na Web.
Apenas emitir 103 dicas iniciais em resposta a clientes que enviam um cabeçalho da solicitação HTTP sec-fetch-mode: navigate só deve enviar essas dicas para clientes mais recentes que entendem que precisam aguardar a resposta subsequente. Além disso, como as dicas iniciais só são compatíveis com solicitações de navegação (consulte as limitações atuais), isso tem o benefício adicional de evitar o envio desnecessário dessas dicas em outras solicitações.
Além disso, as dicas iniciais são recomendadas para serem enviadas apenas por conexões HTTP/2 ou HTTP/3 e a maioria dos navegadores só as aceita nesses protocolos.
Padrão avançado
Se você aplicou totalmente as dicas iniciais às suas principais páginas de destino e está procurando mais oportunidades, talvez se interesse pelo seguinte padrão avançado.
Para visitantes que estão na n-ésima solicitação de página como parte de uma jornada típica do usuário, talvez seja necessário adaptar a resposta de dicas iniciais ao conteúdo que está mais abaixo e mais profundo na página, em outras palavras, usando dicas iniciais em recursos de menor prioridade. Isso pode parecer contra-intuitivo, já que recomendamos focar em sub-recursos ou origens de alta prioridade e de bloqueio de renderização. No entanto, quando um visitante navega por um tempo, é muito provável que o navegador já tenha todos os recursos críticos. A partir daí, pode fazer sentido mudar sua atenção para recursos de menor prioridade. Por exemplo, isso pode significar usar dicas iniciais para carregar imagens de produtos ou JS/CSS adicionais que só são necessários para interações menos comuns do usuário.
Limitações atuais
Confira as limitações das dicas iniciais implementadas no Chrome:
- Disponível apenas para solicitações de navegação (ou seja, o recurso principal do documento de nível superior).
- Oferece suporte apenas a
preconnectepreload(ou seja,prefetchnão é compatível). - As dicas iniciais seguidas por um redirecionamento entre origens na resposta final resultarão em navegadores que descartam os recursos e as conexões obtidas usando dicas iniciais.
- Os recursos pré-carregados usando dicas iniciais são armazenados no cache HTTP e recuperados de lá pela página mais tarde. Portanto, apenas recursos armazenáveis em cache podem ser pré-carregados usando dicas iniciais, ou o recurso será buscado duas vezes (uma pelas dicas iniciais e outra pelo documento). No Chrome, o cache HTTP é desativado para certificados HTTPS não confiáveis (mesmo que você continue carregando a página).
- O pré-carregamento de imagens responsivas (usando
imagesrcset,imagesizesoumedia) pode não ser compatível com cabeçalhos HTTP<link>, já que a janela de visualização não é definida até que o documento seja criado. No melhor dos casos, eles vão aguardar até que o documento seja recebido, negando os principais benefícios de 103 dicas iniciais.
Outros navegadores têm limitações semelhantes e, como observado anteriormente, alguns restringem ainda mais as 103 dicas iniciais apenas a preconnect apenas.
Relação com H2/Push
Se você já conhece o recurso HTTP2/Push descontinuado, talvez se pergunte como as dicas iniciais são diferentes. Embora as dicas iniciais exijam uma viagem de ida e volta para que o navegador comece a buscar sub-recursos críticos, com o HTTP2/Push o servidor pode começar a enviar sub-recursos junto com a resposta. Embora isso pareça incrível, resultou em uma desvantagem estrutural importante: com o HTTP2/Push, era extremamente difícil evitar o envio de sub-recursos que o navegador já tinha. Esse efeito de "over-pushing" resultou em um uso menos eficiente da largura de banda da rede, o que prejudicou significativamente os benefícios de desempenho. No geral, os dados do Chrome mostraram que o HTTP2/Push era, na verdade, um negativo líquido para o desempenho na Web.
Por outro lado, as dicas iniciais têm um desempenho melhor na prática porque combinam a capacidade de enviar uma resposta preliminar com dicas que deixam o navegador responsável por buscar ou se conectar ao que ele realmente precisa. Embora as dicas iniciais não cubram todos os casos de uso que o HTTP2/Push poderia abordar na teoria, acreditamos que as dicas iniciais são uma solução mais prática para acelerar as navegações.
Imagem em miniatura de Pierre Bamin.