Descubra como seu servidor pode enviar dicas para o navegador sobre sub-recursos críticos.
O que são as primeiras dicas?
Os sites se tornaram mais sofisticados com o tempo. Dessa forma, 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 reflexão do servidor" resulta em latência extra antes que o navegador comece a renderizar a página. De fato, a conexão fica efetivamente inativa pelo tempo que o servidor leva para 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 para a 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 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 reflexão do servidor" fazendo um trabalho com antecedência, acelerando o carregamento da página.
Em alguns casos, a melhoria de desempenho da Largest Contentful Paint pode variar de várias centenas de milissegundos, conforme observado pela Shopify e pelo Cloudflare, e até um segundo mais rápida, como vimos na comparação de antes e depois:
Como usar as dicas iniciais
A primeira etapa para aproveitar as dicas iniciais consiste em identificar as principais páginas de destino, ou seja, as páginas que os usuários geralmente começam a usar quando acessam seu site. Pode ser a página inicial ou as páginas mais acessadas das informações do produto, caso muitos usuários venham de outros sites. A razão pela qual esses pontos de entrada são mais importantes do que outras páginas é porque 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 de que precisa 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 dicas preconnect
ou preload
. Normalmente, são as origens e os sub-recursos que mais contribuem para as principais métricas do usuário, como Largest Contentful Paint ou First Contentful Paint. Mais especificamente, procure sub-recursos bloqueadores 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 de usuários.
Caso seus principais recursos já estejam usando preconnect
ou preload
, você pode considerar essas origens ou recursos entre os candidatos às dicas iniciais. Confira como otimizar a LCP para mais detalhes. No entanto, copiar de forma simples as diretivas preconnect
e preload
do HTML para as dicas iniciais pode não ser o ideal.
Ao usá-los em HTML, é recomendado preconnect
ou preload
recursos que o Scanner de pré-carregamento não descobrirá no HTML, por exemplo, fontes ou imagens de plano de fundo que seriam descobertas tardias. Para as dicas iniciais, você não tem o HTML, portanto, pode querer preconnect
para domínios críticos ou preload
recursos essenciais que talvez poderiam ser descobertos no início do HTML, por exemplo, pré-carregando main.css
ou app.js
. Além disso, nem todos os navegadores oferecem suporte a preload
para dicas iniciais. Consulte Suporte do navegador.
A segunda etapa consiste em minimizar o risco de usar as dicas iniciais em recursos ou origens que podem estar obsoletas ou não ser mais usadas pelo recurso principal. Por exemplo, recursos com atualizações e controle de versões frequentes (por exemplo, example.com/css/main.fa231e9c.css
) podem não ser a melhor escolha. Essa preocupação não é específica às dicas iniciais, ela se aplica a preload
ou preconnect
, onde quer que estejam presentes. Esse é o tipo de detalhe que lida melhor com automação ou modelos. Por exemplo, um processo manual tem mais chances de gerar URLs de hash ou versão incompatíveis entre preload
e a tag HTML real usando o recurso.
Por 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 as Early Hints:
103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]
Alguns instantes depois, a página da Web, incluindo o CSS vinculado, é exibida. Infelizmente, este recurso de CSS é atualizado com frequência, e o recurso principal já está cinco versões à frente (abcd105
) do recurso de 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 em grande parte independentes do resultado do recurso principal. Se necessário, considere dividir os principais recursos em duas: uma parte estável, projetada para ser usada com as primeiras dicas, e uma parte mais dinâmica, que deve ser buscada após o recebimento do recurso principal 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 as principais solicitações de recursos enviadas por navegadores conhecidos por serem compatíveis com as Early Hints e responda imediatamente com as 103 Early Hints. Na resposta 103, inclua as dicas relevantes de pré-conexão e pré-carregamento. Quando o recurso principal estiver pronto, dê a resposta habitual (por exemplo, 200 OK se for bem-sucedido). Para compatibilidade com versões anteriores, é recomendável incluir também cabeçalhos HTTP Link
na resposta final, talvez até mesmo complementando 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 de chave, se você tiver seguido a sugestão "dividir em dois"). Veja como isso ficaria:
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:
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 diferem de acordo com o navegador:
Suporte para pré-conexão:
Compatibilidade com navegadores
Suporte para pré-carregamento:
Compatibilidade com navegadores
O Chrome DevTools também tem suporte de 103 dicas iniciais, e os cabeçalhos Link
podem ser vistos nos recursos do documento:
Para usar os recursos de dicas iniciais, Disable cache
não pode estar marcado 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 será exibido como (Disk cache)
:
Isso também exige um certificado confiável para teste de HTTPS.
O Firefox (a partir da versão v126) não tem suporte explícito às 103 Early Hints no DevTools, mas os recursos carregados usando as Early Hints não mostram as informações do cabeçalho HTTP, que é um indicador de que eles foram carregados usando as Early Hints.
Suporte a servidor
Aqui está um breve resumo do nível de suporte para dicas iniciais entre os softwares de servidor HTTP de software de código aberto conhecidos:
- Apache:compatível com mod_http2.
- H2O:compatível.
- NGINX::módulo experimental (links em inglês).
- Nó:com suporte desde a versão 18.11.0 para http e http2
Ative as dicas iniciais de forma mais fácil
Se você estiver usando uma das CDNs ou plataformas a seguir, talvez não seja necessário implementar as dicas iniciais manualmente. Consulte a documentação on-line do seu provedor de soluções para descobrir se ele oferece suporte às dicas iniciais ou consulte a lista com alguns exemplos:
- Dicas iniciais do Cloudflare
- Dicas iniciais do Fastly (em inglês).
- Dicas iniciais da Akamai (em inglês).
Como evitar problemas para clientes que não oferecem suporte às dicas iniciais
Respostas HTTP informativas de 100 pessoas fazem parte do padrão HTTP, mas alguns clientes ou bots mais antigos podem ter dificuldades com elas, porque, antes do lançamento das 103 dicas iniciais, elas raramente eram usadas para navegação geral na Web.
Emitir apenas 103 dicas iniciais em resposta aos clientes que enviam um cabeçalho de solicitação HTTP sec-fetch-mode: navigate
garante que essas dicas sejam enviadas apenas para clientes mais novos que entendam que precisam aguardar a resposta subsequente. Além disso, como as dicas iniciais só podem ser usadas em solicitações de navegação (consulte as limitações atuais), você evita o envio desnecessário de outras solicitações.
Além disso, recomendamos que as primeiras dicas sejam enviadas somente por conexões HTTP/2 ou HTTP/3, e a maioria dos navegadores só as aceitará por esses protocolos.
Padrão avançado
Se você já aplicou totalmente as Dicas iniciais às suas principais páginas de destino e está procurando mais oportunidades, talvez tenha interesse no seguinte padrão avançado.
Para os visitantes que estão na enésima solicitação de página como parte de uma jornada típica do usuário, convém adaptar a resposta das dicas iniciais ao conteúdo que está abaixo e a fundo na página. Em outras palavras, use as dicas iniciais em recursos de menor prioridade. Isso pode parecer contraditório porque recomendamos focar em origens ou sub-recursos bloqueadores de renderização de alta prioridade. No entanto, quando o visitante navega por algum 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 as dicas iniciais para carregar imagens de produtos ou JS/CSS adicional necessário apenas para interações menos comuns do usuário.
Limitações atuais
Estas são 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
preconnect
epreload
(ou seja,prefetch
não é compatível). - As dicas iniciais seguidas por um redirecionamento de origem cruzada na resposta final farão com que o Chrome descarte os recursos e conexões obtidos usando as dicas iniciais.
- Recursos pré-carregados com as dicas iniciais são armazenados no cache HTTP e recuperados de lá pela página mais tarde. Portanto, somente recursos armazenáveis em cache podem ser pré-carregados com as dicas iniciais ou o recurso será buscado duas vezes (uma vez 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
,imagesizes
oumedia
) não é compatível com cabeçalhos HTTP<link>
porque a janela de visualização não é definida até que o documento seja criado. Isso significa que 103 As dicas iniciais não podem ser usadas para pré-carregar imagens responsivas e podem carregar a imagem incorreta quando usada para isso. Acompanhe esta discussão sobre propostas de como lidar melhor com isso.
Outros navegadores têm limitações semelhantes e, como observado anteriormente, alguns restringem ainda mais as 103 dicas iniciais apenas a preconnect
.
A seguir
Dependendo do interesse da comunidade, podemos ampliar nossa implementação das dicas iniciais com os seguintes recursos:
- Dicas iniciais para recursos não armazenáveis em cache usando o cache de memória em vez do cache HTTP.
- Dicas iniciais enviadas em solicitações de sub-recursos.
- Dicas iniciais enviadas em solicitações de recursos principais do iframe.
- Compatibilidade com pré-busca no Early Hints.
Agradecemos sua opinião sobre quais aspectos devem ser priorizados e como podemos melhorar as dicas iniciais.
Relação com H2/Push
Se você conhece o recurso HTTP2/Push descontinuado, pode se perguntar qual é a diferença entre as dicas iniciais. Embora as dicas iniciais exijam uma ida e volta para o navegador começar a buscar sub-recursos críticos, com HTTP2/Push, o servidor pode começar a enviar sub-recursos junto com a resposta. Embora isso pareça incrível, isso resultou em uma desvantagem estrutural importante: com HTTP2/Push, era extremamente difícil evitar enviar sub-recursos que o navegador já tinha. Essa "explosão excessiva" resultou em um uso menos eficiente da largura de banda da rede, o que prejudicava muito o desempenho. De modo geral, os dados do Chrome mostraram que o HTTP2/Push teve, na verdade, uma queda no desempenho na Web.
Em contraste, 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 encarregado de buscar ou se conectar ao que ele realmente precisa. Embora as dicas iniciais não abordem todos os casos de uso que o HTTP2/Push poderia abordar em 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.