Publicado em 23 de junho de 2022, última atualização em 18 de novembro de 2025
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 o desempenho 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."
DOM Content Loaded
"O DOMContentLoaded informa a hora em que o documento HTML inicial foi completamente carregado e analisado, sem aguardar folhas de estilo, imagens e subestruturas para finalizar o carregamento."
Primeira pintura
"A primeira pintura informa a hora 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 de página, quando o navegador começa a renderizar a página.
First Contentful Paint
First Contentful Paint (FCP) informa a hora 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. Essa é a primeira vez que os usuários podem começar a consumir o conteúdo da página."
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."
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.
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 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.
Tipo de recurso do 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 pela primeira vez até a página."
web.dev/articles/lcp - What elements are considered for LCP
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 sobre o 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
A divisão das LCPs de imagens nas subpartes mais importantes oferece a capacidade de usar recomendações e práticas recomendadas específicas sobre como otimizar cada parte.
As subpartes de imagem da LCP são fornecidas em quatro métricas separadas:
largest_contentful_paint_image_time_to_first_bytelargest_contentful_paint_image_resource_load_delaylargest_contentful_paint_image_resource_load_durationlargest_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 do 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 das 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 sobre o lançamento das subpartes de imagem da LCP.
Tipos de navegação
A métrica tipos de navegação fornece um detalhamento 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 no 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, 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 do 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 essas duas ações. |
back_forward_cache |
Uma navegação no histórico que foi veiculada no 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 em ordem inversa da tabela (de baixo para cima).
Mais informações estão disponíveis na postagem de anúncio sobre os tipos de navegação.
onload
"O evento de carregamento é acionado quando a página e os recursos dependentes terminam de carregar."
Tempo de retorno
Fornece uma estimativa do tempo de retorno HTTP (camada de 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 dimensão anterior do
tipo de conexão efetiva (ECT, na sigla em inglês).
Para mais informações, consulte a postagem do blog sobre o 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 algumas também estão disponíveis na API CrUX. Essas métricas provavelmente vão mudar com frequência à 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.
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 avanço e retorno (bfcache) e páginas pré-renderizadas. Como tal, o tamanho da amostra do TTFB pode ser menor do que outras métricas e pode não ser comparado diretamente com elas. O TTFB no CrUX vai incluir carregamentos de páginas frias, carregamentos de páginas armazenadas em cache e carregamentos de páginas de uma conexão estabelecida (por exemplo, carregamentos de páginas internas do site).
O TTFB não é uma medida direta do tempo de resposta do servidor, porque inclui medidas anteriores, incluindo o tempo de redirecionamento, e é afetado se uma resposta é veiculada no cache ou na CDN ou no 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, muitas vezes, 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 das 1.000 principais origens.
Permissões de notificações
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.