Métricas

Publicado em 23 de junho de 2022, última atualização em 13 de outubro de 2026

As métricas no CrUX são baseadas em APIs padrão da plataforma da Web expostas por navegadores. No conjunto de dados do BigQuery, esses dados são agregados à resolução de origem. Os proprietários de sites que precisam de análises e insights mais detalhados (por exemplo, resolução no nível do URL) sobre a performance do site podem usar as mesmas APIs para coletar dados detalhados de medição de usuários reais (RUM, na sigla em inglês) para as próprias origens. Embora todas as APIs estejam disponíveis no Chrome, outros navegadores podem não oferecer suporte ao 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

"O Cumulative Layout Shift (CLS) é uma métrica importante e centrada no usuário para medir a estabilidade visual, porque ajuda a quantificar a frequência com que os usuários têm mudanças inesperadas de layout. Um CLS baixo ajuda a garantir que a página seja agradável."

web.dev/articles/cls (link em inglês)

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 (link em inglês)

Primeira pintura

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

API Paint Timing (link em inglês)

Primeira exibição de conteúdo

"A Primeira exibição de conteúdo (FCP, na sigla em inglês) informa o momento em que o navegador fez a primeira renderização de texto, imagem (incluindo imagens de plano de fundo), tela não branca ou SVG. Isso inclui texto com webfonts pendentes. É a primeira vez que os usuários podem começar a consumir o conteúdo da página."

API Paint Timing (link 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. Uma INP baixa garante que a página seja responsiva de forma confiável em todos os momentos."

web.dev/articles/inp (link em inglês)

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 imagem mais holística da capacidade de resposta geral de uma página durante toda a vida útil.

Largest Contentful Paint

Largest Contentful Paint (LCP) é uma métrica importante e centrada no usuário para medir a velocidade de carregamento percebida, porque marca o ponto na linha do tempo de carregamento de 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 (link em inglês)

Tipo de recurso da Maior exibição de conteúdo

"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 - What elements are considered for LCP (link em inglês)

O texto e a imagem (incluindo a imagem do primeiro frame de 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 da LCP permite entender melhor as métricas e os caminhos de otimização da LCP.

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

Subpartes de imagem do Largest Contentful Paint

"A otimização da LCP pode ser uma tarefa mais complexa quando o PageSpeed Insights não oferece a resposta sobre como melhorar essa métrica. Com tarefas complexas, geralmente é melhor dividi-las em tarefas menores e mais gerenciáveis e abordar cada uma separadamente."

web.dev/articles/optimize-lcp - LCP breakdown into subparts (link em inglês)

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

As subpartes de imagem da 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ó são incluídas para imagens, e isso não inclui imagens do primeiro frame de vídeo, porque elas são um pouco mais complicadas, já que não podemos medir o tempo de download completo. Os primeiros frames de vídeo são incluídos na métrica de tipo de recurso da 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 LCPs de imagens. Para sites que são feitos principalmente de LCPs de texto, as métricas gerais de TTFB e gerais de FCP são divisões úteis, embora sejam em todas as LCPs e não específicas para LCPs de texto.

Para mais informações, consulte a postagem do blog de lançamento das subpartes de imagem da LCP (link em inglês).

A métrica tipos de navegação fornece uma divisão 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 para o qual 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 e, quando possível, pode resultar em melhorias de performance notáveis por poder ser armazenado em cache localmente e em uma CDN.
reload O usuário recarregou a página, clicando no botão de recarga, pressionando Enter na barra de endereço ou desfazendo o fechamento de uma guia. As recargas de página geralmente resultam na revalidação de volta ao servidor para verificar se a página principal foi alterada. Uma alta porcentagem de recargas 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 foi removida por motivos de memória. No Chrome para Android, elas são informadas como "recarregar".
back_forward Uma navegação no histórico, o que significa que a página foi visualizada 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 bfcache evita isso.
back_forward_cache Uma navegação no histórico que foi 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 procurar
prerender A página foi pré-renderizada, o que, de maneira semelhante ao bfcache, pode resultar em carregamentos de página 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, o CrUX informa a primeira correspondência na ordem inversa da tabela (de baixo para cima).

Mais informações podem ser encontradas na postagem de anúncio dos tipos de navegação (link em inglês).

Onload

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

MDN (link em inglês)

Tempo de retorno

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

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

Métricas experimentais

As métricas experimentais estão disponíveis no conjunto de dados do CrUX usando BigQuery e na API CrUX, embora nem todas as métricas estejam disponíveis em ambos. Essas métricas estão sujeitas a mudanças à medida que evoluem com base no feedback do usuário. Consulte as notas da versão para ficar atualizado sobre as mudanças mais recentes.

Métricas experimentais de Core Web Vitals de navegação suave

A versão de outubro de 2026 introduziu versões experimentais das métricas de Core Web Vitals, incluindo navegações suaves:

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

Essas métricas incluem carregamentos de página inteira e navegações suaves.

Para mais detalhes, consulte Introducing experimental Core Web Vitals metrics to the Chrome UX Report (link em inglês).

Time to First Byte

O TTFB no CrUX só é coletado em carregamentos de página inteira, ao contrário de outros timers (como a LCP), que também são coletados em navegações de cache de retorno (bfcache) e páginas pré-renderizadas. Assim, o tamanho da amostra do TTFB pode ser menor do que outras métricas e não pode ser comparado diretamente com elas. O TTFB no CrUX vai incluir carregamentos de página fria, carregamentos de página armazenada em cache e carregamentos de página de uma conexão estabelecida (por exemplo, carregamentos de página no site).

O TTFB não é uma medida direta do tempo de resposta do servidor, já que inclui medidas anteriores, incluindo o tempo de redirecionamento, e é afetado se uma resposta é veiculada do cache ou da CDN ou do servidor. Isso é particularmente aparente em dados de campo, como o CrUX, enquanto os testes de laboratório normalmente 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. A classificação 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.), com cada classificação excluindo a anterior (por exemplo, 5 mil é na verdade 4 mil URLs, excluindo 1 mil). O limite superior é dinâmico à medida que o conjunto de dados cresce.

A popularidade é fornecida como um guia para análise ampla, por exemplo,para determinar a performance por país para as 1.000 principais origens.

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.

Métricas de anúncios

O Chrome oferece métricas e ferramentas públicas para sites e outros, como anunciantes, para entender melhor as experiências de anúncios dos usuários reais e o impacto delas.

Esperamos que essas métricas sejam particularmente úteis para anunciantes da Web e os serviços que eles usam para veicular anúncios. Recebemos feedback de uma grande seção transversal de partes interessadas do ecossistema de anúncios de que essas métricas podem melhorar a forma como elas valorizam as oportunidades de anúncios e tomam decisões sobre produtos de anúncios.

Para mais informações, consulte a postagem do blog de lançamento das métricas de anúncios e a documentação de medições de anúncios.