Os dados brutos do Chrome UX Report (CrUX) estão disponíveis no BigQuery, um banco de dados no Google Cloud. Para usar o BigQuery, é preciso ter um projeto do GCP e conhecimento básico de SQL.
Neste guia, você vai aprender a usar o BigQuery para escrever consultas no conjunto de dados do CrUX e extrair resultados úteis sobre o estado das experiências do usuário na Web:
- Entender como os dados são organizados
- Escrever uma consulta básica para avaliar o desempenho de uma origem
- Escrever uma consulta avançada para acompanhar o desempenho ao longo do tempo
Organização dos dados
Comece analisando uma consulta básica:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
Para executar a consulta, insira-a no editor de consultas e pressione "Executar consulta". botão:
Essa consulta tem duas partes:
SELECT COUNT(DISTINCT origin)significa consultar o número de origens na tabela. Em resumo, dois URLs fazem parte da mesma origem se tiverem o mesmo esquema, host e porta.FROM chrome-ux-report.all.202206especifica o endereço da tabela de origem, que tem três partes:- O nome do projeto do Cloud
chrome-ux-reportem que todos os dados CrUX estão organizados - O conjunto de dados
all, que representa dados de todos os países - A tabela
202206, o ano e o mês dos dados no formato AAAAMM
- O nome do projeto do Cloud
Também há conjuntos de dados para cada país. Por exemplo, chrome-ux-report.country_ca.202206 representa apenas os dados de experiência do usuário originados do Canadá.
Dentro de cada conjunto de dados há tabelas para todos os meses desde 201710. Novas tabelas do mês anterior são publicadas regularmente.
A estrutura das tabelas de dados (também conhecida como esquema) contém:
- A origem (por exemplo,
origin = 'https://www.example.com'), que representa a distribuição agregada da experiência do usuário em todas as páginas desse site - A velocidade da conexão no momento do carregamento da página, por exemplo,
effective_connection_type.name = '4G' - O tipo de dispositivo, por exemplo,
form_factor.name = 'desktop' - As próprias métricas de UX
Os dados de cada métrica são organizados como uma matriz de objetos. Na notação JSON, first_contentful_paint.histogram.bin seria semelhante a este exemplo:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Cada agrupamento contém um horário de início e término em milissegundos e uma densidade que representa a porcentagem de experiências do usuário nesse período. Em outras palavras, 12, 34% das experiências de FCP referentes a essa origem hipotética, velocidade de conexão e tipo de dispositivo são inferiores a 100 ms. A soma de todas as densidades de agrupamento é 100%.
Navegue pela estrutura das tabelas no BigQuery.
Avaliar o desempenho
Podemos usar nosso conhecimento do esquema da tabela para escrever uma consulta que extraia esses dados de desempenho.
SELECT
fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
effective_connection_type.name = '4G' AND
form_factor.name = 'phone' AND
fcp.start = 0
O resultado é 0.01115, o que significa que 1,115% das experiências do usuário nessa origem ficam entre 0 e 100 ms em 4G e em um smartphone. Se quisermos generalizar a consulta para qualquer conexão e qualquer tipo de dispositivo, podemos omití-los da cláusula WHERE e usar a função agregadora SUM para somar todas as densidades de bin:
SELECT
SUM(fcp.density)
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start = 0
O resultado é 0.05355, ou 5,355% em todos os dispositivos e tipos de conexão. Podemos modificar ligeiramente a consulta e adicionar as densidades de todos os agrupamentos que estão na tabela "rápido" Intervalo de FCP de 0 a 1.000 ms:
SELECT
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
Isso nos dá 0.6977. Em outras palavras, 69,77% das experiências do usuário da FCP no web.dev são consideradas "rápidas" de acordo com a definição do intervalo da FCP.
Acompanhar o desempenho
Agora que extraímos dados de desempenho sobre uma origem, podemos compará-los com os dados históricos disponíveis em tabelas mais antigas. Para fazer isso, podemos reescrever o endereço da tabela de um mês anterior ou podemos usar a sintaxe de caractere curinga para consultar todos os meses:
SELECT
_TABLE_SUFFIX AS yyyymm,
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.*`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
GROUP BY
yyyymm
ORDER BY
yyyymm DESC
Aqui, vemos que a porcentagem de experiências rápidas da FCP varia em alguns pontos percentuais a cada mês.
| aaaamm | fast_fcp |
|---|---|
| 202206 | 69,77% |
| 202205 | 70,71% |
| 202204 | 69,04% |
| 202203 | 69,82% |
| 202202 | 67,75% |
| 202201 | 58,96% |
| 202112 | 41,69% |
| … | … |
Com essas técnicas, é possível consultar o desempenho de uma origem, calcular a porcentagem de experiências rápidas e acompanhá-la ao longo do tempo. A próxima etapa é consultar duas ou mais origens e comparar o desempenho delas.
Perguntas frequentes
Estas são algumas perguntas frequentes sobre o conjunto de dados CrUX do BigQuery:
Quando devo usar o BigQuery em vez de outras ferramentas?
O BigQuery só é necessário quando você não consegue acessar as mesmas informações em outras ferramentas, como o painel do CrUX e o PageSpeed Insights. Por exemplo, o BigQuery permite dividir os dados de forma significativa e até mesmo mesclá-los a outros conjuntos de dados públicos, como o HTTP Archive, para fazer uma mineração de dados avançada.
Há alguma limitação no uso do BigQuery?
Sim, a limitação mais importante é que, por padrão, os usuários só podem consultar 1 TB de dados por mês. Além disso, aplica-se a taxa padrão de US $5/TB.
Onde posso saber mais sobre o BigQuery?
Confira a documentação do BigQuery para mais informações.