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