Métricas

As métricas no CrUX são alimentadas por APIs padrão da plataforma da Web expostas pelos navegadores. No conjunto de dados do BigQuery, esses dados são agregados à resolução de origem. Os proprietários de sites que precisam de uma análise mais detalhada (por exemplo, resolução no nível do URL) e insights sobre a performance do site podem usar as mesmas APIs para coletar dados detalhados de medição de usuários reais (RUM) para as próprias origens. Embora todas as APIs estejam disponíveis no Chrome, outros navegadores podem não ser compatíveis com o conjunto completo de métricas.

A maioria das métricas é representada como uma agregação de histograma, permitindo a visualização da distribuição e a aproximação dos valores de percentil.

Cumulative Layout Shift

"A mudança de layout cumulativa (CLS) é uma métrica importante e focada no usuário para medir a estabilidade visual. Ela ajuda a quantificar a frequência com que os usuários encontram mudanças inesperadas de layout. Uma CLS baixa ajuda a garantir que a página seja agradável."

web.dev/articles/cls

Conteúdo DOM carregado

"O DOMContentLoaded informa o momento em que o documento HTML inicial foi completamente carregado e analisado, sem esperar que folhas de estilo, imagens e subframes concluam o carregamento."

MDN

Primeira pintura

"A primeira renderização informa o momento em que o navegador foi renderizado pela primeira vez após a navegação. Isso exclui a pintura de segundo plano padrão, mas inclui a pintura de segundo plano não padrão. Esse é o primeiro momento importante para os desenvolvedores no carregamento da página: quando o navegador começa a renderizar a página."

API Paint Timing (em inglês)

First Contentful Paint

"A Primeira exibição de conteúdo (FCP) informa o momento em que o navegador renderizou pela primeira vez qualquer texto, imagem (incluindo imagens de plano de fundo), tela não branca ou SVG. Isso inclui texto com webfonts pendentes. Esta é a primeira vez que os usuários podem começar a consumir o conteúdo da página".

API Paint Timing (em inglês)

Interaction to Next Paint

"A Interaction to Next Paint (INP) é uma métrica de campo que avalia a capacidade de resposta. A INP registra a latência de todas as interações durante todo o ciclo de vida da página. O valor mais alto dessas interações (ou próximo ao mais alto para páginas com muitas interações) é registrado como a INP da página. Um INP baixo garante que a página seja responsiva de forma confiável em todos os momentos."

web.dev/articles/inp

A Interaction to Next Paint (INP) foi adicionada ao conjunto de dados do CrUX em fevereiro de 2022. Essa nova métrica captura a latência de ponta a ponta de eventos individuais e oferece uma visão mais holística da capacidade de resposta geral de uma página durante todo o ciclo de vida dela.

Maior exibição de conteúdo

"O Largest Contentful Paint (LCP) é uma métrica importante e focada no usuário para medir a velocidade de carregamento percebida, porque marca o ponto na linha do tempo de carregamento da página em que o conteúdo principal provavelmente foi carregado. Uma LCP rápida ajuda a garantir ao usuário que a página é útil."

web.dev/articles/lcp

Tipo de recurso Largest Contentful Paint

"A LCP informa o tempo de renderização da maior imagem, do maior bloco de texto ou do maior vídeo visível na janela de visualização, em relação ao momento em que o usuário navegou até a página pela primeira vez."

web.dev/articles/lcp: quais elementos são considerados para o LCP

Texto e imagem (incluindo a imagem do primeiro frame do vídeo) geralmente têm características de carregamento e técnicas de otimização muito diferentes. Entender a proporção dos tipos de recursos de LCP ajuda a entender melhor as métricas de LCP e os caminhos de otimização.

Para mais informações, consulte a postagem do blog sobre o lançamento dos tipos de recursos LCP.

Subpartes da imagem da Maior exibição de conteúdo

"Otimizar a LCP pode ser uma tarefa mais complexa quando o PageSpeed Insights não informa como melhorar essa métrica. Com tarefas complexas, geralmente é melhor dividi-las em tarefas menores e mais fáceis de gerenciar e resolver cada uma separadamente".

web.dev/articles/optimize-lcp - LCP breakdown into subparts

Dividir os LCPs de imagens nas subpartes mais importantes permite usar recomendações e práticas recomendadas específicas para otimizar cada parte.

As subpartes da imagem LCP são fornecidas em quatro métricas separadas:

  • largest_contentful_paint_image_time_to_first_byte
  • largest_contentful_paint_image_resource_load_delay
  • largest_contentful_paint_image_resource_load_duration
  • largest_contentful_paint_image_element_render_delay

As subpartes são incluídas apenas para imagens, e isso não inclui imagens do primeiro frame de vídeo, já que elas são um pouco mais complicadas porque não podemos medir o tempo total de download. Os primeiros frames de vídeo são incluídos na métrica de tipo de recurso LCP, em que essa complicação não é relevante.

As subpartes de texto também não são incluídas porque são menos úteis e distorcem os números de LCP de imagem. Para sites que são feitos principalmente de LCPs de texto, as métricas gerais de TTFB e FCP são detalhamentos úteis, mas observe que elas abrangem todos os LCPs, não apenas os de texto.

Para mais informações, consulte a postagem do blog sobre o lançamento de subpartes de imagens LCP.

A métrica tipos de navegação mostra uma análise detalhada da porcentagem de visualizações de página das seguintes navegações:

Tipo Descrição
navigate Um carregamento de página que não se encaixa em nenhuma das outras categorias.
navigate_cache Um carregamento de página em que o recurso principal (o documento HTML principal) foi veiculado do cache HTTP. Os sites costumam usar o armazenamento em cache para sub-recursos, mas o documento HTML principal geralmente é armazenado em cache consideravelmente menos. Quando isso é possível, o desempenho melhora significativamente, já que o documento pode ser armazenado em cache localmente e em uma CDN.
reload O usuário atualizou a página pressionando o botão de atualização, a tecla "Enter" na barra de endereço ou desfazendo o fechamento de uma guia. As recargas de página geralmente resultam em revalidação de volta ao servidor para verificar se a página principal mudou. Uma alta porcentagem de recarregamentos de página pode indicar frustrações na experiência do usuário.
restore A página foi recarregada após a reinicialização do navegador ou uma guia que havia sido removida por motivos de memória. No Chrome para Android, eles são informados como "recarregar".
back_forward Uma navegação histórica, ou seja, a página foi acessada e retornada recentemente. Com o armazenamento em cache correto, essas experiências devem ser razoavelmente rápidas, mas ainda exigem que a página seja processada e o JavaScript seja executado, o que o bfcache evita.
back_forward_cache Uma navegação histórica veiculada do bfcache. Otimizar suas páginas para aproveitar o bfcache, removendo bloqueadores, deve resultar em experiências mais rápidas. Portanto, os sites precisam parecer
prerender A página foi pré-renderizada, o que, assim como o bfcache, pode resultar em carregamentos quase instantâneos.

Em alguns casos, um carregamento de página pode ser uma combinação de vários tipos de navegação. Nesse caso, a CrUX informa a primeira correspondência em ordem inversa da tabela (de baixo para cima).

Confira mais informações na postagem de anúncio sobre tipos de navegação.

Onload

"O evento de carregamento é disparado quando a página e os recursos dependentes dela terminam de carregar."

MDN

Tempo de retorno

Fornece uma estimativa do tempo de ida e volta HTTP (camada de aplicativo) no início da navegação, com base em conexões de rede recentes. Essa métrica é baseada na propriedade rtt da API Network Information, que é a mesma API responsável pela antiga dimensão Tipo de conexão efetiva (ECT).

Para mais informações, consulte a postagem do blog sobre o lançamento dos tipos de recursos LCP.

Métricas experimentais

As métricas experimentais estão disponíveis no conjunto de dados do CrUX usando o BigQuery. Algumas delas também estão disponíveis na API CrUX. Essas métricas provavelmente vão mudar regularmente à medida que evoluem com base no feedback dos usuários. Consulte as notas da versão para ficar por dentro das mudanças mais recentes.

Tempo até o primeiro byte

O TTFB no CrUX é coletado apenas em carregamentos de página inteira, ao contrário de outros timers (como o LCP), que também são coletados em navegações para frente e para trás e em páginas pré-renderizadas. Assim, o tamanho da amostra do TTFB pode ser menor do que o de outras métricas e não necessariamente ser comparado diretamente com elas.

O TTFB não é uma medida direta do tempo de resposta do servidor, já que inclui medidas anteriores, como o tempo de redirecionamento, e é afetado pela forma como uma resposta é veiculada (do cache, da CDN ou do servidor). Isso é particularmente evidente em dados de campo, como o CrUX, enquanto os testes de laboratório geralmente são menos afetados por esses fatores, já que o URL final é testado e geralmente nega repetidamente as mudanças de armazenamento em cache.

Popularidade

A métrica de classificação de popularidade é uma medida relativa da popularidade do site no conjunto de dados do CrUX, medida pelo número total de navegações na origem. O ranking está em uma escala log10 com etapas intermediárias (por exemplo, 1 mil, 5 mil, 10 mil, 50 mil, 100 mil, 500 mil, 1 milhão etc.), e cada classificação exclui a anterior (por exemplo, os 5 mil principais são, na verdade, 4 mil URLs, excluindo os 1 mil principais). O limite superior é dinâmico à medida que o conjunto de dados cresce.

A popularidade é fornecida como um guia para análises gerais, por exemplo,para determinar a performance por país das 1.000 origens principais.

Permissões de notificação

Para sites que pedem permissão para mostrar notificações aos usuários, essa métrica representa a frequência relativa das respostas dos usuários aos avisos: aceitar, negar, ignorar ou dispensar.