Como otimizar a LCP usando trocas assinadas

Como medir e otimizar as trocas assinadas para aproveitá-las ao máximo

As trocas assinadas (SXGs) são um meio de melhorar a velocidade da sua página, principalmente a Maior exibição de conteúdo (LCP). Ao indicar sites (atualmente a Pesquisa Google) que direcionam os usuários para uma página, eles podem fazer a pré-busca dela no cache do navegador antes de o usuário clicar no link.

É possível criar páginas da Web que, quando pré-buscadas, não precisam de rede no caminho crítico para renderizar a página. Em uma conexão 4G, o carregamento de página vai de 2,8 s para 0,9 s (os 0,9 s restantes são principalmente pelo uso da CPU):

A maioria das pessoas que publicam SXGs atualmente usa o recurso de trocas assinadas automáticas (ASX, na sigla em inglês) do Cloudflare, embora também existam opções de código aberto:

Em muitos casos, marcar a caixa para ativar esse recurso é o suficiente para obter o tipo de melhoria substancial mostrado acima. Às vezes, há mais algumas etapas para garantir que essas SXGs funcionem conforme o esperado em cada estágio do pipeline e para otimizar as páginas para aproveitar ao máximo a pré-busca.

Nos últimos meses, desde o lançamento do Cloudflare, li e respondi a perguntas em vários fóruns e aprendendo a orientar os sites sobre como garantir que eles aproveitem ao máximo as implantações de SXG. Esta postagem é uma coleção dos meus conselhos. Vamos seguir as etapas para:

• Analise o desempenho das SXG usando o WebPageTest.
• Depure o pipeline de SXG se a etapa "Analisar" mostrar que ele não está funcionando.
• Otimize páginas para a pré-busca de SXG, incluindo a configuração de max-age ideal e o pré-carregamento de subrecursos de bloqueio de renderização.
• Avalie a melhoria das SXG usando o Google Analytics. Para isso, selecione os grupos experimentais e de controle adequados.

Introdução

Uma SXG é um arquivo que contém um URL, um conjunto de cabeçalhos de resposta HTTP e um corpo de resposta, tudo assinado criptograficamente por um certificado de ICP da Web. Quando o navegador carrega uma SXG, ele verifica todos estes itens:

• As SXG não expiraram.
• A assinatura corresponde ao URL, cabeçalhos, corpo e certificado.
• O certificado é válido e corresponde ao URL.

Se a verificação falhar, o navegador abandonará as SXG e buscará o URL assinado. Se a verificação for bem-sucedida, o navegador vai carregar a resposta assinada, tratando como se ela tivesse vindo diretamente do URL assinado. Isso permite que as SXGs sejam re-hospedadas em qualquer servidor, desde que não tenham expirado ou tenham sido modificadas após a assinatura.

No caso da Pesquisa Google, as SXG permitem a pré-busca de páginas nos resultados da pesquisa. Para páginas compatíveis com SXGs, a Pesquisa Google pode fazer a pré-busca da cópia em cache da página, hospedada em webpkgcache.com. Esses URLs de webpkgcache.com não afetam a exibição ou o comportamento da página, porque o navegador respeita o URL original assinado. A pré-busca pode permitir que sua página carregue muito mais rápido.

Analisar

Para conhecer os benefícios das SXGs, comece usando uma ferramenta de laboratório para analisar o desempenho delas em condições repetíveis. É possível usar o WebPageTest para comparar hierarquias e LCP com e sem a pré-busca de SXG.

Gere um teste sem as SXG da seguinte maneira:

• Acesse WebPageTest e faça login. Ao fazer login, seu histórico de testes é salvo para facilitar a comparação posteriormente.
• Insira o URL que você quer testar.
• Acesse a Configuração avançada. Você precisará da Configuração avançada para o teste de SXG, então usá-la aqui ajuda a garantir que as opções de teste sejam as mesmas.
• Na guia Configurações de teste, pode ser útil definir a conexão como 4G e aumentar o "Número de testes a serem executados" para 7.
• Clique em Iniciar teste.

Gere um teste com SXG seguindo as mesmas etapas acima, mas antes de clicar em Iniciar teste, acesse a guia Script, cole o script WebPageTest e modifique os dois URLs navigate conforme indicado:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

Para o primeiro URL navigate, se sua página ainda não aparecer nos resultados da Pesquisa Google, use esta página de pré-busca para gerar uma página de resultados de pesquisa fictícia para essa finalidade.

Para determinar o segundo URL navigate, acesse sua página usando a extensão SXG Validator do Chrome e clique no ícone da extensão para conferir o URL do cache:

Quando esses testes forem concluídos, acesse o Histórico de testes, selecione os dois testes e clique em Comparar:

Anexe &medianMetric=LCP ao URL de comparação para que o WebPageTest selecione a execução com LCP mediana para cada lado da comparação. O padrão é a mediana por índice de velocidade.

Para comparar hierarquias, expanda a seção Opacidade em hierarquia e arraste o controle deslizante. Para assistir o vídeo, clique em Ajustar configurações de tira de filme, role para baixo dentro dessa caixa de diálogo e clique em Ver vídeo.

Se a pré-busca de SXG for bem-sucedida, você vai perceber que a hierarquia "with SXG" não inclui uma linha para o HTML, e as buscas de sub-recursos vão começar mais cedo. Por exemplo, compare "Antes" e "Depois" aqui:

Depuração

Se o WebPageTest estiver mostrando que a SXG está sendo pré-buscada, ela concluiu todas as etapas do pipeline. Pule para a seção Otimizar para saber como melhorar ainda mais a LCP. Caso contrário, você vai precisar descobrir em que parte do pipeline ela falhou e por quê. Continue lendo para saber como.

Publicando

Verifique se as páginas estão sendo geradas como SXGs. Para fazer isso, finja ser um rastreador. A maneira mais fácil é usar a extensão SXG Validator do Chrome:

A extensão busca o URL atual com um cabeçalho de solicitação Accept que diz que prefere a versão SXG. Se aparecer uma marca de seleção (✅) ao lado de "Origin", isso significa que uma SXG foi retornada. Pule para a seção Indexação.

Se você vir um XG (❌), isso significa que uma SXG não foi retornada:

Se o ASX do Cloudflare estiver ativado, o motivo mais provável para um sinal de X (❌) é porque um cabeçalho de resposta de controle de cache o impede. O ASX analisa cabeçalhos com os seguintes nomes:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

Se algum desses cabeçalhos tiver algum dos seguintes valores, isso impedirá que uma SXG seja gerada:

• private
• no-store
• no-cache
• max-age menor que 120, a menos que substituído por s-maxage maior ou igual a 120

O ASX não cria SXGs nesses casos porque elas podem ser armazenadas em cache e reutilizadas em várias visitas e visitantes.

Outro motivo possível para um cruzamento (❌) é a presença de um destes cabeçalhos de resposta com estado, exceto Set-Cookie. O ASX remove o cabeçalho Set-Cookie para obedecer à especificação das SXG.

Outro motivo possível é a presença de um cabeçalho de resposta Vary: Cookie. O Googlebot busca SXGs sem credenciais de usuário e pode veiculá-las a vários visitantes. Se você veicular HTMLs diferentes para usuários distintos com base no cookie, eles poderão ter uma experiência incorreta, como uma visualização desconectada.

Como alternativa para a extensão do Chrome, você pode usar uma ferramenta como o curl:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

ou dump-signedexchange:

dump-signedexchange -verify -uri $URL

Se as SXG estiverem presentes e válidas, será exibida uma impressão legível delas. Caso contrário, uma mensagem de erro será exibida.

Indexação

Verifique se as SXGs foram indexadas pela Pesquisa Google. Abra o Chrome DevTools e faça uma Pesquisa Google para sua página. Se ela tiver sido indexada como SXG, o link do Google para sua página vai incluir um data-sxg-url que direciona para a cópia do webpkgcache.com:

Se a Pesquisa Google achar que o usuário provavelmente clicará no resultado, ela também fará a pré-busca dele:

O elemento <link> instrui o navegador a fazer o download das SXG no cache de pré-busca. Quando o usuário clicar no elemento <a>, o navegador vai usar as SXGs armazenadas em cache para renderizar a página.

Também é possível ver evidências da pré-busca acessando a guia "Rede" no DevTools e pesquisando URLs que contenham webpkgcache.

Se <a> apontar para webpkgcache.com, isso significa que a indexação da troca assinada pela Pesquisa Google está funcionando. É possível pular para a seção Ingestão.

Caso contrário, pode ser que o Google ainda não tenha rastreado novamente sua página desde que você ativou as SXG. Teste a Ferramenta de inspeção de URL do Google Search Console:

A presença de um cabeçalho digest: mi-sha256-03=... indica que o Google rastreou a versão das SXG.

Se um cabeçalho digest não estiver presente, isso pode indicar que uma SXG não foi veiculada para o Googlebot ou que o índice não foi atualizado desde que você ativou as SXGs.

Se uma SXG for rastreada, mas ainda não estiver vinculada, talvez haja uma falha no cumprimento dos requisitos de cache das SXG. Vamos abordar isso na próxima seção.

Ingestão

Quando a Pesquisa Google indexa uma SXG, ela envia a cópia dela para o cache das SXG do Google, que a valida de acordo com os requisitos de cache. A extensão do Chrome mostra o resultado:

Se aparecer uma marca de seleção (✅), avance para Otimizar.

Se ele não cumprir os requisitos, vai aparecer um sinal de X (❌) e uma mensagem de aviso indicando o motivo:

Nesse caso, a página vai funcionar exatamente como antes de ativar as SXG. O Google vai criar um link para a página no host original sem uma pré-busca de SXG.

Se a cópia em cache tiver expirado e estiver sendo buscada novamente em segundo plano, você verá uma ampulheta (⌛):

O documento para desenvolvedores do Google sobre SXG também tem instruções para consultar o cache manualmente.

Otimizar

Se a extensão do Chrome SXG Validator mostrar todas as marcas de seleção (✅), você tem uma SXG que pode ser veiculada aos usuários. Continue lendo para saber como otimizar sua página da Web e conseguir o máximo de melhoria da LCP das SXG.

max-age

Quando as SXGs expiram, o cache das SXG do Google busca uma nova cópia em segundo plano. Enquanto aguardam essa busca, os usuários são direcionados para a página no host original, que não é pré-buscado. Quanto mais tempo você definir Cache-Control: max-age, menor será a frequência dessa busca em segundo plano e, portanto, com mais frequência a LCP pode ser reduzida pela pré-busca.

Há uma compensação entre desempenho e atualização, e o cache permite que os proprietários do site forneçam às SXGs um tempo máximo entre 2 minutos e 7 dias, para atender às necessidades específicas de cada página. Curiosamente, descobrimos que:

• max-age=86400 (1 dia) ou mais são bons para a performance
• max-age=120 (2 minutos) não

Esperamos aprender mais sobre os valores entre esses dois, à medida que estudarmos os dados mais.

user-agent

Uma vez, vi a LCP aumentar ao usar uma SXG pré-buscada. Executei o WebPageTest, comparando resultados médios com e sem a pré-busca de SXG. Clique em Depois abaixo:

Notei que a pré-busca estava funcionando. O HTML é removido do caminho crítico e, assim, todos os sub-recursos podem ser carregados mais cedo. Mas a LCP (a linha tracejada verde) aumentou de 2s para 2,1s.

Para diagnosticar isso, olhei para as tiras de filme. Descobri que a página foi renderizada de maneira diferente nas SXG. Em HTML simples, o Chrome determinou que o "maior elemento" da LCP era a manchete. No entanto, na versão SXG, a página adicionou um banner de carregamento lento, que colocava o título abaixo da dobra e fazia com que o novo maior elemento fosse a caixa de diálogo de consentimento de cookies com carregamento lento. Tudo era renderizado mais rápido do que antes, mas uma mudança no layout fez com que a métrica o informasse como mais lenta.

Investiguei a situação e descobri que o motivo da diferença no layout é que a página varia em User-Agent e há um erro de lógica. Ele estava veiculando uma página para computador, embora o cabeçalho de rastreamento de SXG indicasse dispositivos móveis. Depois que o problema foi corrigido, o navegador identificou corretamente o título da página como o maior elemento.

Ao clicar em "Depois", percebi que a LCP pré-buscada cai para 1,3 s:

As SXGs estão ativadas para todos os formatos. Para se preparar, verifique se uma das seguintes condições é verdadeira:

• Sua página não Vary por User-Agent. Por exemplo, ela usa design responsivo ou URLs separados para computador e dispositivo móvel.
• Caso a página use a veiculação dinâmica, ela será marcada como exclusiva para dispositivos móveis ou computadores usando <meta name=supported-media content=...>.

Recursos secundários

As SXGs podem ser usadas para fazer a pré-busca de sub-recursos (incluindo imagens) junto com o HTML. O Cloudflare ASX verificará o HTML em busca de elementos <link rel=preload> de mesma origem (próprios) e os converterá em cabeçalhos de link compatíveis com SXG. Detalhes no código-fonte aqui e aqui.

Se estiver funcionando, vão aparecer outras pré-buscas da Pesquisa Google:

Para otimizar a LCP, observe de perto sua hierarquia e descubra quais recursos estão no caminho crítico para renderizar o maior elemento. Se não for possível fazer a pré-busca deles, verifique se eles podem ser retirados do caminho crítico. Procure scripts que ocultem a página até que o carregamento seja concluído.

O cache das SXGs do Google permite até 20 pré-carregamentos de sub-recursos, e o ASX garante que esse limite não seja excedido. No entanto, há o risco de adicionar muitos pré-carregamentos de sub-recursos. O navegador só usará subrecursos pré-carregados se todos tiverem concluído a busca, para evitar o rastreamento entre sites. Quanto mais sub-recursos houver, menor será a probabilidade de todos terem concluído a pré-busca antes de o usuário clicar na sua página.

No momento, o SXG Validator não verifica sub-recursos. Para depurar, use curl ou dump-signedexchange.

Medida

Depois de otimizar a melhoria da LCP no WebPageTest, é útil medir o impacto da pré-busca de SXG no desempenho geral do seu site.

Métricas do lado do servidor

Ao avaliar métricas do lado do servidor, como Tempo até o primeiro byte (TTFB, na sigla em inglês), é importante observar que seu site só exibe SXGs a rastreadores que aceitam o formato. Limite a medição de TTFB a solicitações vindas de usuários reais, e não de bots. Talvez a geração de SXGs aumente o TTFB para solicitações do rastreador, mas isso não afeta a experiência dos visitantes.

Métricas do lado do cliente

As SXGs são as que geram o maior benefício de velocidade nas métricas do lado do cliente, especialmente na LCP. Para medir o impacto, basta ativar o Cloudflare ASX, esperar que ele seja rastreado pelo Googlebot, aguardar mais 28 dias para a agregação das Core Web Vitals (CWV) e analisar os novos números das Core Web Vitals. No entanto, a mudança pode ser difícil de detectar quando combinada entre todas as outras mudanças durante esse período.

Em vez disso, acho útil "aumentar o zoom" dos carregamentos de página potencialmente afetados e enquadrá-los como "SXGs afetam X% das visualizações de página, melhorando a LCP em Y milissegundos no 75o percentil".

Atualmente, a pré-busca de SXG só acontece sob certas condições:

• Navegador Chromium (por exemplo, Chrome ou Edge, exceto no iOS), versão M98 ou mais recente
• Referer: google.com ou outros domínios da Pesquisa Google. No Google Analytics, uma tag de referência se aplica a todas as visualizações de página na sessão, enquanto a pré-busca de SXG só se aplica à primeira visualização de página, diretamente vinculada à Pesquisa Google.

Leia a seção Estudo contemporâneo para saber como medir "X% das visualizações de página" e "melhorar a LCP em Y milissegundos".

Estudo contemporâneo

Ao analisar dados de monitoramento de usuários reais (RUM, na sigla em inglês), divida os carregamentos de página em SXG e não SXG. Ao fazer isso, é essencial limitar o conjunto de carregamentos de página que você analisa para que o lado não SXG corresponda às condições de qualificação das SXG, a fim de evitar viés de seleção. Caso contrário, todos os itens a seguir existiriam apenas no conjunto de carregamentos de página não SXG, que podem ter LCP inatamente diferentes:

• Dispositivos iOS:devido a diferenças na velocidade de hardware ou rede entre os usuários que têm esses dispositivos.
• Navegadores Chromium mais antigos:pelos mesmos motivos.
• Dispositivos desktop:pelos mesmos motivos ou porque o layout da página faz com que um "elemento maior" diferente seja escolhido.
• Navegações no mesmo site (visitantes que seguem links no site): porque elas podem reutilizar os sub-recursos em cache do carregamento de página anterior.

No Google Analytics (UA), crie duas dimensões personalizadas com o escopo "Hit", uma chamada "isSXG" e outra chamada "referrer". A dimensão integrada "Origem" tem escopo de sessão. Portanto, ela não exclui navegações no mesmo site.

Crie um segmento personalizado chamado "SXG contrafatual" com os seguintes filtros "AND":

• referrer começa com https://www.google.
• Browser corresponde exatamente a Chrome
• A versão Browser corresponde ao regex ^(9[8-9]|[0-9]{3})
• isSXG corresponde exatamente a false

Crie uma cópia deste segmento, com o nome "SXG", exceto quando isSXG corresponde exatamente a true.

No modelo do seu site, adicione o snippet a seguir acima do snippet do Google Analytics. Esta é uma sintaxe especial que a ASX mudará false para true ao gerar uma SXG:

<script data-issxg-var>window.isSXG=false</script>

Personalize seu script de relatório do Google Analytics conforme recomendado para registrar a LCP. Se você usa a gtag.js, modifique o comando 'config' para definir a dimensão personalizada (substituindo 'dimension1' e 'dimension2' pelos nomes que o Google Analytics recomenda usar):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

Se você estiver usando a analytics.js, modifique o comando 'create' conforme documentado aqui.

Depois de aguardar alguns dias para coletar alguns dados, acesse o Relatório de eventos do Google Analytics e adicione um detalhamento do segmento das SXG. Isso deve preencher o X em "SXGs afetam X% das visualizações de página":

Por fim, acesse o Relatório de Métricas da Web, selecione "Escolher segmentos" e escolha "Contrafatual SXG" e "SXG".

Clique em "Enviar" para ver as distribuições de LCP para os dois segmentos. O Y deve ser preenchido para "melhorar a LCP em Y milissegundos no 75o percentil":

Advertências

Depois de aplicar todos os filtros acima, os carregamentos de página contrafatos das SXG terão os seguintes elementos:

• Ausências no cache:se o cache das SXG do Google não tiver uma cópia nova das SXG para um determinado URL, ele vai ser redirecionado para o URL original no seu site.
• Outros tipos de resultados:no momento, a Pesquisa Google só é compatível com SXG para resultados padrão da Web e alguns outros tipos. Outros, como os trechos em destaque e o carrossel de notícias principais, terão links para o URL original do seu site.
• URLs não qualificados:se algumas páginas do seu site não estiverem qualificadas para SXG (por exemplo, porque não podem ser armazenadas em cache), elas poderão aparecer nesse conjunto.

Pode haver viés entre os carregamentos de página SXG e o conjunto acima de carregamentos de páginas não SXG, mas deve ser menor em magnitude do que os vieses mencionados na parte superior da seção "Estudo contemporâneo". Por exemplo, talvez as páginas que não podem ser armazenadas em cache sejam mais lentas ou mais rápidas do que as páginas que podem ser armazenadas em cache. Se você suspeitar que isso pode ser um problema, analise os dados limitados a um URL específico qualificado para SXG para ver se os resultados correspondem ao estudo geral.

Caso seu site tenha algumas páginas AMP, provavelmente não haverá melhorias de desempenho ao ativar as SXG, porque elas já podem ser pré-buscadas na Pesquisa Google. Considere adicionar um filtro para excluir essas páginas e "ampliar" ainda mais as alterações relevantes.

Por fim, mesmo ao lidar com todos os vieses de seleção, há o risco de que o viés de sobrevivência faça as melhorias na LCP parecerem degradações nas estatísticas de RUM. Este artigo explica bem esse risco e sugere analisar alguma forma de métrica de abandono para detectar se isso está acontecendo.

Estudo de antes/depois

Para corroborar os resultados do estudo contemporâneo, pode ser útil fazer uma comparação da LCP antes e depois de ativar as SXG. Não se limite às visualizações de página de SXG para eliminar as possíveis tendências mencionadas acima. Em vez disso, observe os resultados qualificados para SXG, as definições de segmento acima, mas sem a restrição isSXG.

A Pesquisa Google pode levar várias semanas para rastrear novamente todas as páginas do site e identificar as SXGs ativadas. Nessas semanas, há outros possíveis vieses que podem ocorrer:

• Novas versões de navegadores ou melhorias no hardware dos usuários podem acelerar o carregamento de páginas.
• Eventos significativos, como um feriado, podem desviar o tráfego do normal.

Também é útil examinar a LCP geral do 75o percentil antes e depois para confirmar os estudos acima. Aprender sobre um subconjunto da população não nos diz necessariamente sobre a população geral. Por exemplo, digamos que as SXG melhore 10% dos carregamentos de página em 800 ms.

• Se esses já forem os carregamentos de página 10% mais rápidos, isso não vai afetar o 75o percentil.
• Se o carregamento de página for 10% mais lento, mas for mais de 800 ms mais lento do que a LCP do 75o percentil, isso não vai afetar o 75o percentil.

Esses são exemplos extremos que provavelmente não refletem a realidade, mas ilustram o problema. Na prática, é provável que as SXG afetem o 75o percentil para a maioria dos sites. As navegações entre sites tendem a ser algumas das mais lentas, e as melhorias da pré-busca tendem a ser significativas.

Desative alguns URLs

Por fim, uma maneira de comparar a performance das SXGs é desativá-las para alguns subconjuntos de URLs no seu site. Por exemplo, é possível definir um cabeçalho CDN-Cache-Control: no-store para evitar que o Cloudflare ASX gere uma SXG. Não recomendo usar esse recurso.

Ele provavelmente tem um risco maior de viés de seleção do que os outros métodos de estudo. Por exemplo, pode fazer uma grande diferença se a página inicial do seu site ou um URL igualmente popular será selecionado no grupo de controle ou no grupo experimental.

Estudo de retenção

A maneira ideal de medir o impacto seria realizar um estudo de restrição. Infelizmente, não é possível fazer esse tipo de teste no momento. Planejamos adicionar compatibilidade com esse teste no futuro.

Um estudo de restrição tem as seguintes propriedades:

• No grupo experimental, algumas frações aleatórias de visualizações de página que seriam SXGs são "retidas" e veiculadas como não SXG. Isso permite uma comparação justa entre usuários, dispositivos, cenários e páginas equivalentes.
• As visualizações de página contidas (também conhecidas como contrafatos) são identificadas dessa forma na análise. Isso permite uma visualização mais ampla dos dados, em que podemos comparar os carregamentos de página das SXG no controle com os contrafatos das SXG no experimento. Isso, por sua vez, reduz o ruído dos outros carregamentos de página que não seriam afetados pela pré-busca de SXG.

Isso eliminaria as possíveis fontes de viés de seleção mencionadas acima, embora não eliminaria o risco de viés de sobrevivência da LCP. Ambas as propriedades exigem que o navegador ou o referenciador sejam ativadas.

Conclusão

Ufa. Quanta gente! Esperamos que ele ofereça uma visão mais completa de como testar o desempenho das SXG em um teste de laboratório, como otimizar o desempenho em um feedback contínuo com o teste de laboratório e, por fim, como medir o desempenho no mundo real. A junção de tudo isso ajuda você a aproveitar ao máximo as SXGs e garantir que elas estejam beneficiando seu site e os usuários.

Se você tiver mais conselhos sobre como capturar o desempenho das SXG, entre em contato. Registre um bug em developer.chrome.com com as melhorias sugeridas.

Para mais informações sobre trocas assinadas, consulte a documentação web.dev e a documentação da Pesquisa Google.