Publicado em 11 de fevereiro de 2025
A versão de fevereiro de 2025 do relatório de experiência do usuário do Chrome (CrUX) inclui várias métricas novas e alteradas:
- Subpartes de imagem e tipos de recursos da Maior exibição de conteúdo (LCP)
- Detalhes do tempo de retorno (RTT)
- Remoção da dimensão "Tipo de conexão vigente" (ECT, na sigla em inglês)
Cada uma delas fornece mais insights sobre as métricas de performance de origens e URLs disponíveis no CrUX. Neste post, vamos detalhar o motivo.
Informações de diagnóstico do LCP
Originalmente, apresentamos o conceito de subpartes de LCP na Google I/O 2022 como uma técnica eficaz para dividir o tempo de LCP de páginas com LCPs de imagem em componentes menores, garantindo que você estivesse dedicando seus esforços para otimizar as causas corretas de LCPs altos.
A análise dos dados do laboratório do HTTP Archive nessa palestra mostrou que o tempo de download de imagens geralmente era a menor parte do tempo de LCP. Muitas ferramentas de laboratório (incluindo o Lighthouse do Google) se concentram em conselhos para otimizar formatos e tamanhos de imagem e reduzir o tempo de download e melhorar a performance. Embora ainda correto, a análise mostrou que o conselho pode ter sido enfatizado demais e que um problema maior foi o atraso antes que a imagem fosse encontrada pelo navegador e começasse a ser transferida por download.
Embora a análise de dados de laboratório seja útil, a forma como a Web é usada na vida real pode ser diferente. Por isso, é fundamental conferir essas subpartes dos dados de campo. Uma postagem publicada no ano passado confirmou o equívoco comum sobre como otimizar o LCP com dados de campo.
Subpartes da imagem da LCP
Com essa versão, os proprietários de sites podem verificar as subpartes do LCP de imagem nos próprios sites, na origem ou no nível do URL.
As subpartes estão disponíveis apenas para imagens e não incluem as imagens do primeiro frame do vídeo, que são um pouco mais complicadas, já que não é possível medir o tempo de download completo. As subpartes de texto também não são incluídas, porque são menos úteis e distorceriam os números de LCPs de imagem. Para sites que são compostos principalmente de LCPs de texto, as métricas gerais de TTFB e FCP são divisões úteis, mas elas são aplicadas a todos os LCPs, não apenas aos de texto. Por fim, as subpartes da imagem são coletadas apenas em carregamentos de página completos, diferente da métrica LCP, que também é coletada em navegações de ida e volta e páginas pré-renderizadas.
Esses dados foram adicionados à API CrUX e à API CrUX History em fevereiro de 2025 (não no BigQuery). A API CrUX History tem duas semanas de dados no lançamento, e isso vai aumentar com o tempo para o histórico completo de 25 semanas. As APIs disponibilizam os dados como a 75ª percentil de cada subparte expressa em milissegundos.
Por exemplo, para receber as subpartes de imagem do LCP para https://web.dev/ em visualizações de página PHONE, use o seguinte comando curl (substituindo API_KEY pela sua própria chave):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"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"]}'
Você vai receber algo como isto:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Atualizamos a ferramenta CrUX Vis para incluir esses dados e esperamos que outras ferramentas de terceiros que usam as APIs CrUX também exponham esses dados valiosos:
Neste exemplo, podemos ver que, para um site de mídia popular, a duração do carregamento de recursos é o componente menor. As oportunidades reais de melhoria para este site estão no TTFB e no atraso no carregamento de recursos, com uma oportunidade menor no atraso na renderização de elementos.
Valores altos em cada subparte indicam diferentes problemas:
- Um tempo para o primeiro byte (TTFB) alto geralmente indica problemas de servidor, rede ou redirecionamento, conforme explicado em Otimizar o TTFB.
- Um atraso alto no carregamento de recursos indica que a imagem LCP é descoberta tarde pelo navegador. Por exemplo, uma imagem LCP injetada por JavaScript do lado do cliente que demora um pouco para ser executada.
- A duração do carregamento de recursos alta é onde você precisa reduzir o tamanho do download da imagem.
- O atraso de renderização de elemento alto ocorre quando a imagem está disponível (talvez por meio de um
<link rel=preload>, mas não é usada por um longo período), geralmente devido à necessidade de JavaScript do lado do cliente para mostrar a imagem.
Esperamos que, ao disponibilizar esses dados no CrUX na origem e no nível do URL (sujeito aos critérios de qualificação habituais), seja mais fácil para os sites otimizarem a métrica LCP.
Tipos de recursos de LCP
Como as subpartes são melhores para visualizar LCPs de imagem, o CrUX restringe esses dados apenas a páginas com imagens. Por isso, é importante entender quantos LCPs são de imagens e quantos são de texto (como títulos <h1> e parágrafos longos, por exemplo).
Além das subpartes de imagem do LCP, as APIs CrUX agora também incluem um detalhamento de recursos que mostra a divisão dos carregamentos de página do LCP entre texto e imagens.
Por exemplo, para conferir os tipos de recurso LCP de https://web.dev/ para visualizações de página PHONE, use o seguinte comando curl (substitua API_KEY por sua própria chave):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Você vai receber algo como isto:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
A visualização CrUX também foi atualizada para mostrar estes dados:
Na página inicial da web.dev, por exemplo, 98,5% das LCPs eram de texto, então as subpartes de LCP de imagem são menos úteis para essa página. Nesse caso, podemos usar as métricas TTFB e FCP originais como uma análise detalhada de diagnóstico potencialmente melhor.
Os tipos de recursos de LCP são outra ferramenta de diagnóstico útil para entender e melhorar o LCP, especialmente para saber o quão úteis são as subpartes da imagem do LCP.
Informações de diagnóstico de RTT
Também ampliamos a métrica RTT, lançada em agosto de 2024.
lixeiras de RTT
Adicionamos tri-bins às APIs CrUX para mostrar três agrupamentos de densidades de RTT:
| Latência de rede | Iniciar | Fim |
|---|---|---|
| Baixo | 0 milissegundo | < 75 milissegundos |
| Médio | 75 milissegundos | < 275 milissegundos |
| Alta | 275 milissegundos | ∞ |
Esses intervalos são mais informativos do que as categorias anteriores de ECT, que incluíam tudo menos de 270 milissegundos na categoria 4g. Com os avanços na tecnologia de rede desde o lançamento, a maioria dos sites teve a maior parte do tráfego nessa categoria, o que torna essa categorização menos útil.
Por isso, sugerimos usar os rótulos baixa, média e alta em vez dos rótulos bom, precisa de melhoria e ruim. Elas não são métricas que o proprietário do site pode melhorar diretamente e, portanto, são métricas de diagnóstico para entender as outras métricas e por que elas podem ser diferentes do esperado. Elas também podem ajudar a explicar por que outras métricas mudam ao longo do tempo, mesmo que o site não mude se elas mostrarem uma mudança na base de usuários.
Esses compartimentos estão disponíveis nas APIs CrUX, por exemplo, para web.dev para visualizações de página PHONE (substitua API_KEY por sua própria chave):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Que retorna algo como este:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Os intervalos são mostrados no CrUX Vis quando as distribuições são selecionadas:
RTT no BigQuery
Além de expandir a métrica RTT nas APIs CrUX para incluir os tri-bins, também disponibilizamos os dados no conjunto de dados mensal do BigQuery, incluindo um histograma completo em intervalos de 25 milissegundos nas tabelas brutas e tri-bins e valores p75 nas tabelas materializadas.
Isso permite um entendimento mais profundo da distribuição de dados além dos três compartimentos disponíveis nas APIs CrUX. Isso também nos permite recriar o detalhamento do ECT que foi removido do CrUX a partir deste mês (mais detalhes sobre isso mais tarde), com a pequena mudança de um limite de 275 milissegundos para 4g em vez do limite anterior de 270 milissegundos. Os detalhes do ECT (agora provenientes de dados de RTT) continuam disponíveis nas tabelas materializadas do BigQuery do Crux para que ferramentas como o Painel do Crux continuem mostrando esse detalhamento.
O conjunto de dados do BigQuery também inclui dados por país (conforme definido pela ISO 3166-1). Isso permite uma análise mais detalhada, que pode ser útil para explicar por que as métricas de performance são piores para alguns usuários. Por exemplo, podemos analisar os dados dos usuários do Google Phone verificando os dados de https://www.google.com:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Em seguida, visualizamos os dados em um mapa geográfico:
https://www.google.com(dados de origem com gráfico interativo).
Vemos que, embora a maior parte do mundo (principalmente o "mundo ocidental") tenha RTTs muito bons, a África Subsaariana, partes do Oriente Médio e da Ásia têm mais dificuldades. Na verdade, o gráfico é limitado a 500 milissegundos de RTT, porque o uso de todos os dados distorceu as cores, especialmente com a Eritreia no percentil 75 de 3.850 milissegundos.
Isso também pode ser útil quando os padrões de tráfego mudam. Por exemplo, uma proporção maior de usuários desses países com RTTs mais altos pode explicar estatísticas piores dos Core Web Vitals, mesmo que o site não tenha mudado nada.
Embora os sites não possam melhorar o RTT diretamente, disponibilizar esses dados para os visitantes do site permite entender melhor os usuários do seu site em todo o mundo. Isso também gera muitas oportunidades de análise no futuro, e esperamos que os pesquisadores encontrem insights interessantes com esse conjunto de dados.
Remoção da dimensão ECT
A última mudança na versão de fevereiro de 2025 é a desativação da dimensão "Tipo de conexão eficaz" (ECT) do BigQuery. Já removemos o RTT das APIs em setembro de 2024 quando apresentamos a métrica RTT como substituto.
Como mencionado anteriormente nesta postagem, a métrica RTT permite uma visualização mais detalhada dos detalhes de conexão dos visitantes de um site. Você pode recriar os buckets de ECT com base nesses histogramas. Tecnicamente, a ECT precisa ser uma combinação de RTT e velocidade de downlink, mas o Chrome só usou a RTT.
Uma diferença importante é que a ECT era uma dimensão do CrUX, o que significa que as outras métricas podiam ser segmentadas por ECT. O RTT é uma métrica do CrUX, não uma dimensão. Por isso, não é possível conferir o LCP por RTT, por exemplo, mas apenas os RTTs pelas outras dimensões (tipo de dispositivo e país).
Isso pode parecer mais limitado, mas a mudança de dimensão para métrica libera mais dados no CrUX. Isso acontece porque o CrUX tem certos limites mínimos antes de mostrar os dados. Já tornamos as dimensões opcionais em 2022, ou seja, removemos a ECT ou o dispositivo quando necessário para gerar relatórios em um nível mais alto. No entanto, as métricas que não estavam na maioria dos carregamentos de página (Interação até a próxima pintura (INP), diferentes tipos de navegação e agora subpartes de imagem do LCP) geralmente não estavam disponíveis para origens no BigQuery.
Ao reduzir o número de dimensões, os dados ficam menos segmentados, e o número de origens que atendem a esses requisitos mínimos aumenta. Em janeiro, informamos INP para 68,1% das origens, enquanto no conjunto de dados de dezembro, informamos INP apenas para 64,5% das origens. O mecanismo também se aplica aos tipos de navegação, às subpartes do LCP e aos tipos de recurso nesta versão. Todos eles se beneficiam da remoção da dimensão ECT. Nas APIs CrUX, o aumento da cobertura entrou em vigor no início de fevereiro.
As colunas de ECT vão permanecer no BigQuery para manter a consistência com os conjuntos de dados anteriores, e os dados de ECT nas visualizações materializadas vão continuar disponíveis, mas com base nas informações de RTT (com uma diferença de 5 milissegundos para 3g e 4g, conforme observado anteriormente), além do novo RTT p75 e dos tri-bins.
Conclusão
A adição de mais métricas ao conjunto de dados público do CrUX oferece aos proprietários de sites e pesquisadores muito mais informações para ajudar a diagnosticar e corrigir problemas de desempenho.
Como um conjunto de dados público, o CrUX tem algumas limitações no nível de detalhes que podemos mostrar. Por exemplo, os seletores de elementos individuais nunca vão aparecer no CrUX. Os proprietários de sites que buscam esse nível de detalhe são fortemente aconselhados a implementar uma solução de RUM, que não será tão restrita.
No entanto, dados agregados de nível mais alto, como os detalhados nesta postagem, podem ajudar a preencher a lacuna entre saber que você tem um problema e por que ele existe. Esperamos que esses dados adicionais sejam úteis. Entre em contato com o grupo de discussão se tiver feedback ou dúvidas.