Como otimizar a LCP usando trocas assinadas

Como medir e otimizar as trocas assinadas para conseguir o máximo de melhorias com elas

Devin mullins
Devin Mullins

As trocas assinadas (SXGs) são uma forma de melhorar a velocidade da página, principalmente a Maior exibição de conteúdo (LCP). Ao fazer referência a sites (atualmente a Pesquisa Google) têm links 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 dessa página vai de 2,8 s para 0,9 s (os 0,9 s restantes são principalmente por uso da CPU):

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

Painel de configurações do Cloudflare com a caixa de seleção para ativar as trocas assinadas automáticas

Em muitos casos, marcar a caixa para ativar esse recurso é 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, tenho lido e respondido perguntas em vários fóruns e aprendido como 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. Seguem as etapas para:

Introdução

As SXGs são arquivos que contêm um URL, um conjunto de cabeçalhos de resposta HTTP e um corpo de resposta, todos assinados 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-a como se ela tivesse vindo diretamente do URL assinado. Isso permite que as SXGs sejam re-hospedadas em qualquer servidor, desde que ele não tenha expirado nem tenha sido modificado desde 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 nem 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 ver 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. Portanto, 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 Start Test, 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, caso sua página ainda não apareça nos resultados da Pesquisa Google, use esta página de pré-busca para gerar uma página de resultados da pesquisa fictício.

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 ver o URL do cache:

Validador de SXG mostrando informações de cache, incluindo URL

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

Histórico de testes com dois testes marcados e o botão "Comparar" destacado

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 pelo índice de velocidade.

Para comparar cachoeiras, abra a seção Opacidade em cascata e arraste o controle deslizante. Para assistir o vídeo, clique em Ajustar configurações da tira de filme, role para baixo na caixa de diálogo e clique em Ver vídeo.

Se a pré-busca de SXG for bem-sucedida, você vai ver que a hierarquia "com SXG" não inclui uma linha para o HTML, e as buscas por sub-recursos começam antes. Por exemplo, compare "Antes" e "Depois" aqui:

Cascata de rede sem pré-busca de SXG. A primeira linha é a busca HTML, que leva 1.050 ms Hierarquia de rede com pré-busca de SXG. O HTML foi pré-buscado, permitindo que todos os sub-recursos comecem a buscar 1.050 ms antes

Depuração

Se o WebPageTest mostrar que as SXGs estão sendo pré-buscadas, isso significa que ele foi concluído em 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 o motivo da falha. 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:

Validador de SXG mostrando uma marca de seleção (✅) e um tipo de conteúdo de app/assinatura-assinado;v=b3

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

Um sinal de X (❌) significa que as SXG não foram devolvidas:

Validador de SXG mostrando um sinal de X (❌) e um tipo de conteúdo de texto/html

Se o Cloudflare ASX estiver ativado, o motivo mais provável para um cruzamento (❌) é 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 um dos seguintes valores de cabeçalho, isso impedirá a geração de SXG:

  • 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 para várias visitas e visitantes.

Outro motivo possível para o sinal de 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 à 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, você verá uma impressão legível delas. Caso contrário, uma mensagem de erro vai aparecer.

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:

Resultados da Pesquisa Google com DevTools mostrando uma tag âncora que aponta para webpkgcache.com

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

Resultados da Pesquisa Google com DevTools mostrando um link com rel=prefetch para webpkgcache.com.

O elemento <link> instrui o navegador a fazer o download das SXG para o cache de pré-busca. Quando o usuário clica no elemento <a>, o navegador usa 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 procurando URLs que contêm webpkgcache.

Se <a> apontar para webpkgcache.com, isso significa que a indexação da Pesquisa Google da troca assinada está funcionando. Pule para a seção Ingestão.

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

Ferramenta de inspeção de URL do Search Console, clicando em &quot;Ver página rastreada&quot; e em &quot;Mais informações&quot;.

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 as SXGs não foram veiculadas para o Googlebot ou que o índice não foi atualizado desde que as SXGs foram ativadas.

Se uma SXG for rastreada, mas ainda não estiver vinculada, talvez haja falha em atender aos requisitos de cache das SXG. Vamos falar sobre 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 em relação aos requisitos de cache. A extensão do Chrome mostra o resultado:

Validador de SXG mostrando uma marca de seleção (✅) e nenhuma mensagem de aviso

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

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

Validador de SXG mostrando um sinal de X (❌) e uma mensagem de aviso dizendo

Nesse caso, a página vai funcionar como antes da ativação das SXG. O Google vai criar um link para a página no host original sem uma pré-busca de SXG.

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

SXG Validator mostrando uma ampulheta (⌛) e nenhuma mensagem de aviso

O documento do Google Developers sobre SXG também contém 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 a maior melhoria da LCP das SXG.

max-age

Quando as SXGs expiram, o Cache de 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é-buscada. Quanto mais você definir Cache-Control: max-age, menor será a frequência dessa busca em segundo plano e, portanto, maior a frequência com que a LCP pode ser reduzida pela pré-busca.

Essa é uma compensação entre desempenho e atualização, e o cache permite que os proprietários dos sites forneçam às SXGs uma idade máxima entre 2 minutos e 7 dias, para atender às necessidades específicas de cada página. Em termos gerais, descobrimos que:

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

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

user-agent

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

Hierarquia de rede sem pré-busca de SXG. A LCP tem 2 segundos Hierarquia de rede com pré-busca de SXG. O HTML foi pré-buscado, permitindo que todos os sub-recursos comecem a buscar 800 ms antes, mas a LCP tem 2,1 segundos.

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

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 o título. No entanto, na versão das SXG, a página adicionou um banner com carregamento lento, que colocou o título abaixo da dobra e fez com que o novo maior elemento fosse a caixa de diálogo de consentimento de cookies com carregamento lento. Tudo foi renderizado mais rápido do que antes, mas uma mudança no layout fez com que a métrica reportasse a velocidade como mais lenta.

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

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

Hierarquia de rede sem pré-busca de SXG. A LCP tem 2 segundos Hierarquia de rede com pré-busca de SXG.A LCP tem 1,3 segundo

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

Subrecursos

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, você verá mais pré-buscas da Pesquisa Google:

Resultados da Pesquisa Google com a guia &quot;Rede&quot; do DevTools, mostrando uma pré-busca de /sub/.../image.jpg

Para otimizar para 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. Fique atento a scripts que escondem a página até que eles terminem de carregar.

O cache das SXGs do Google permite até 20 pré-carregamentos de recursos secundários, 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á sub-recursos pré-carregados se todos tiverem concluído a busca, a fim de evitar o rastreamento entre sites. Quanto mais sub-recursos houver, menor será a probabilidade de todos eles terem concluído a pré-busca antes de o usuário clicar em 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 para o primeiro byte (TTFB, na sigla em inglês), é importante observar que seu site só exibe SXGs aos rastreadores que aceitam o formato. Limite a medição do TTFB a solicitações provenientes de usuários reais, e não de bots. Talvez você descubra que gerar SXGs aumenta 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 geram os melhores benefícios de velocidade para as métricas do lado do cliente, especialmente LCP. Para isso, basta ativar o Cloudflare ASX, aguardar o novo rastreamento do Googlebot, aguardar mais 28 dias para a agregação das Core Web Vitals (CWV) e conferir os novos números das CWV. No entanto, a mudança pode ser difícil de detectar quando misturada 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 sua LCP em Y milissegundos no 75o percentil".

Atualmente, a pré-busca de SXG acontece apenas sob determinadas condições:

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

Estudo contemporâneo

Ao analisar os 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 que não seja 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 intrinsecamente diferente:

  • Dispositivos iOS:devido a diferenças na velocidade de hardware ou de 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 "maior elemento" diferente seja escolhido.
  • Navegações no mesmo site (visitantes que seguem links dentro do site): porque elas podem reutilizar os sub-recursos armazenados 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.

Editor de dimensões do Google Analytics com configurações recomendadas

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

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

Crie uma cópia deste segmento, com o nome "SXG", mas se isSXG corresponder 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ê estiver usando a gtag.js, modifique o comando 'config' para definir a dimensão personalizada, substituindo 'dimension1' e 'dimension2' pelos nomes que o Google Analytics diz 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 de SXG. Isso deve preencher o X em "SXGs afetam X% das visualizações de página":

Relatório de eventos do Google Analytics com o segmento de SXG, mostrando 12,5% de eventos únicos

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

Relatório de Métricas da Web com seleções de contrafatual e SXG de SXG

Clique em "Enviar", e você verá as distribuições de LCP para os dois segmentos. Ele precisa preencher o Y para "melhorar a LCP em Y milissegundos no 75o percentil":

Relatório de Métricas da Web mostrando distribuições de LCP para contrafatos e SXG de SXG

Avisos

Depois de aplicar todos os filtros acima, os carregamentos de página contrafatos de SXG devem consistir em itens como:

  • Ausências no cache:se o cache das SXG do Google não tiver uma nova cópia das SXG em um determinado URL, ele vai redirecionar para o URL original no 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 snippets em destaque e o carrossel de notícias principais, vão direcionar para o URL original do seu site.
  • URLs não qualificados:se algumas páginas do seu site não estiverem qualificadas para as 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 de SXG e o conjunto acima de carregamentos de páginas que não são SXG, mas deve ser menor em magnitude do que as vieses mencionados na parte superior da seção Estudo contemporâneo. Por exemplo, talvez as páginas não armazenáveis em cache sejam mais lentas ou rápidas do que as 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, é provável que elas não tenham melhorias de desempenho com a ativação das SXG, porque elas já podem ser pré-buscadas na Pesquisa Google. Considere adicionar um filtro para excluir essas páginas e "aumentar o zoom" das alterações relevantes.

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

Estudo antes/depois

Para corroborar os resultados do estudo contemporâneo, pode ser útil fazer uma comparação de LCP antes e depois de ativar as SXG. Não se limite às visualizações de página de SXG para eliminar os possíveis vieses mencionados acima. Em vez disso, observe os resultados qualificados para SXG, que são 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 se as SXG foram ativadas. Nessas semanas, talvez ocorram outros vieses em potencial:

  • Novas versões de navegadores ou melhorias no hardware dos usuários podem acelerar o carregamento de páginas.
  • Um evento significativo, como um feriado, pode distorcer o tráfego do normal.

Também é útil analisar 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 melhorem 10% dos carregamentos de página em 800 ms.

  • Se esses já fossem os carregamentos de página 10% mais rápidos, isso não vai afetar o 75o percentil.
  • Se eles eram os 10% carregamentos de página mais lentos, mas fossem mais de 800 ms mais lentos do que a LCP no 75o percentil, isso não vai afetar o 75o percentil.

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

Desativar alguns URLs

Por fim, uma maneira de comparar a performance das SXG é desativar as SXG em 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 fazer isso.

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 estratégia de retenção parcial do investimento. Infelizmente, não é possível realizar 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, uma fração aleatória de visualizações de página que seria SXG 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áginas retidas (também conhecidas como contrafatos) são rotuladas dessa forma no Analytics. Isso permite uma visualização "detalhada" dos dados, em que podemos comparar os carregamentos de página de SXG no controle com os contrafatos de SXG no experimento. Isso, por sua vez, reduz o ruído dos outros carregamentos de página que não foram 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 de LCP. Essas duas propriedades exigem a ativação pelo navegador ou pelo referenciador.

Conclusão

Ufa. Quanta gente! Esperamos que ele mostre um quadro mais completo de como testar o desempenho das SXG em um teste de laboratório, como otimizar seu desempenho em um ciclo de feedback rígido com o teste de laboratório e, por fim, como medir o desempenho no mundo real. A combinação de tudo isso vai ajudar você a aproveitar ao máximo as SXGs e garantir que elas estejam beneficiando seu site e os usuários.

Fale com a gente caso você tenha mais conselhos sobre como melhorar a performance das SXG. Registre um bug em developer.chrome.com com as melhorias sugeridas.

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