Как использовать набор данных CruX BigQuery

Rick Viscomi

Исходные данные отчета Chrome UX Report ( CrUX ) доступны в BigQuery , базе данных Google Cloud. Для использования BigQuery требуется проект GCP и базовые знания SQL.

В этом руководстве вы узнаете, как использовать BigQuery для написания запросов к набору данных CrUX, чтобы получить ценные результаты о состоянии пользовательского опыта в интернете:

• Разберитесь, как организованы данные.
• Напишите простой запрос для оценки производительности источника.
• Напишите сложный запрос для отслеживания производительности с течением времени.

Организация данных

Начнём с рассмотрения простого запроса:

SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`

Чтобы выполнить запрос, введите его в редактор запросов и нажмите кнопку «Выполнить запрос»:

Этот запрос состоит из двух частей:

• SELECT COUNT(DISTINCT origin) означает запрос количества источников в таблице. Грубо говоря, два URL-адреса относятся к одному и тому же источнику, если у них одинаковая схема, хост и порт.

• FROM chrome-ux-report.all.202206 указывает адрес исходной таблицы, которая состоит из трех частей:

  • Облачный проект называется chrome-ux-report в рамках которого организованы все данные CrUX.
  • all набор данных содержит информацию по всем странам.
  • В таблице 202206 указаны год и месяц в формате ГГГГММ.

Также существуют наборы данных для каждой страны. Например, chrome-ux-report.country_ca.202206 содержит только данные об опыте использования, полученные в Канаде.

В каждом наборе данных содержатся таблицы за каждый месяц, начиная с 201710 года. Новые таблицы за предыдущий календарный месяц публикуются регулярно.

Структура таблиц данных (также известная как схема ) включает в себя:

• В качестве источника, например, origin = 'https://www.example.com' , что отражает совокупное распределение пользовательского опыта для всех страниц этого веб-сайта.
• Например, скорость соединения на момент загрузки страницы: effective_connection_type.name = '4G' ( удалено с февраля 2025 г. )
• Тип устройства, например, form_factor.name = 'desktop'
• Сами метрики UX
  • first_paint (FP)
  • first_contentful_paint ( FCP )
  • largest_contentful_paint ( LCP )
  • dom_content_loaded (DCL)
  • onload (OL)
  • layout_instability.cumulative_layout_shift ( CLS )
  • interaction_to_next_paint ( INP )

Данные для каждой метрики организованы в виде массива объектов. В формате JSON файл first_contentful_paint.histogram.bin будет выглядеть примерно так:

[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]

Каждый интервал содержит время начала и окончания в миллисекундах, а также плотность, представляющую процент пользовательских взаимодействий в этом временном диапазоне. Другими словами, 12,34% взаимодействий FCP для этого гипотетического источника, скорости соединения и типа устройства имеют время менее 100 мс. Сумма плотностей всех интервалов составляет 100%.

Просмотрите структуру таблиц в BigQuery.

Оцените производительность

Мы можем использовать наши знания о схеме таблицы, чтобы написать запрос, который извлекает эти данные о производительности.

SELECT
  fcp
FROM
  `chrome-ux-report.all.202502`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  form_factor.name = 'phone' AND
  fcp.start = 0

Результат равен 0.01115 , что означает, что 1,115% пользовательских взаимодействий на этом источнике происходят в диапазоне от 0 до 100 мс при использовании 4G и на телефоне. Если мы хотим обобщить наш запрос на любое соединение и любой тип устройства, мы можем исключить их из предложения WHERE и использовать функцию агрегирования SUM для суммирования всех соответствующих плотностей интервалов:

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

Результат составляет 0.05355 , или 5,355% для всех устройств и типов подключений. Мы можем немного изменить запрос и суммировать плотности для всех интервалов, находящихся в «быстром» диапазоне FCP от 0 до 1000 мс:

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

Это дает нам 0.6977 . Другими словами, 69,77% пользовательского опыта FCP на web.dev считается «быстрым» в соответствии с определением диапазона FCP.

Отслеживание производительности

Теперь, когда мы извлекли данные о производительности источника, мы можем сравнить их с историческими данными, доступными в более старых таблицах. Для этого мы можем изменить адрес таблицы на более ранний месяц или использовать синтаксис подстановочных символов для запроса всех месяцев:

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

Здесь мы видим, что процент быстрых запусков FCP меняется на несколько процентных пунктов каждый месяц.

С помощью этих методов вы можете узнать производительность определенного источника, рассчитать процент быстрых запросов и отслеживать его во времени. В качестве следующего шага попробуйте выполнить запрос к двум или более источникам и сравнить их производительность.

Часто задаваемые вопросы

Вот некоторые из часто задаваемых вопросов о наборе данных CrUX BigQuery:

В каких случаях лучше использовать BigQuery, а не другие инструменты?

BigQuery необходим только в тех случаях, когда получить ту же информацию из других инструментов, таких как CrUX Vis и PageSpeed ​​Insights, невозможно. Например, BigQuery позволяет сегментировать данные осмысленным образом и даже объединять их с другими общедоступными наборами данных, такими как HTTP Archive, для проведения расширенного анализа данных.

Существуют ли какие-либо ограничения при использовании BigQuery?

Да, самое важное ограничение заключается в том, что по умолчанию пользователи могут запрашивать только 1 ТБ данных в месяц. При превышении этого объема применяется стандартная ставка в 5 долларов за ТБ.

Где я могу узнать больше о BigQuery?

Для получения более подробной информации ознакомьтесь с документацией BigQuery .