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

Рик Вискоми

Необработанные данные отчета Chrome UX ( 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 представляет только данные о пользовательском опыте, полученные из Канады.

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

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

  • Источник, например origin = 'https://www.example.com' , который представляет совокупное распределение пользовательского опыта для всех страниц этого веб-сайта.
  • Скорость соединения на момент загрузки страницы, например, effective_connection_type.name = '4G'
  • Тип устройства, например form_factor.name = 'desktop'
  • Сами UX-метрики
    • first_paint (ФП)
    • first_contentful_paint (FCP)
    • dom_content_loaded (DCL)
    • загрузка (OL)
    • Experimental.first_input_delay (FID)

Данные для каждой метрики организованы в виде массива объектов. В нотации 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.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

Запрос CrUX FCP в BigQuery

Результат — 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

Суммирование CrUX FCP в BigQuery

Результат — 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

Запрос быстрого FCP в BigQuery

Это дает нам 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

Запрос таймсерии CrUX FCP в BigQuery

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

ггггмм fast_fcp
202206 69,77%
202205 70,71%
202204 69,04%
202203 69,82%
202202 67,75%
202201 58,96%
202112 41,69%
... ...

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

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

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

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

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

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

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

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

Дополнительную информацию можно найти в документации BigQuery .