Типы навигации теперь доступны в Crux

Barry Pollard

Johannes Henkel

Начиная с набора данных за март 2024 года , в отчет об опыте пользователей Chrome (CrUX) включена метрика navigation_types . Это обеспечивает агрегированную статистику о типах навигации по загрузке страниц для запрошенного измерения .

Различные типы навигации приводят к различиям в показателях производительности, поэтому при анализе производительности вашего сайта полезно понимать относительную частоту этих разных типов. Например, когда навигация использует обратную связь (bfcache) , это обычно приводит к почти мгновенной навигации, что отражается в очень маленьких метриках LCP и FCP, а также уменьшенных метриках CLS и INP.

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

Метрика navigation_types доступна в ежедневном CrUX API , CrUX History API (с историей за 3 недели, доступной изначально и увеличивающейся еженедельно до полного охвата в течение следующих 6 месяцев), последнем наборе данных CrUX BigQuery и панели мониторинга CrUX . Наличие истории также позволяет владельцам сайтов просматривать изменения в использовании типов навигации с течением времени. Это может позволить отслеживать улучшения (например, устранение блокировки bfcache). Это также может помочь объяснить изменения в показателях, даже если на их сайтах не было внесено никаких изменений.

Какие типы навигации доступны в CrUX?

В следующей таблице CrUX различает следующие типы навигации:

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

Ограничения типов навигации в CruX

Поскольку CrUX является общедоступным набором данных, степень детализации его отчетов ограничена. Для многих источников и URL-адресов показатель navigation_types недоступен из-за недостаточного подходящего трафика. Дополнительную информацию см. в методологии CruX .

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

Мы рекомендуем сайтам реализовать собственный мониторинг реальных пользователей (RUM), чтобы иметь возможность сегментировать трафик по таким критериям, как типы навигации. Обратите внимание, что вы можете увидеть различия в типах навигации в этих решениях в зависимости от сообщаемых типов и включенных просмотров страниц — см. статью «Почему данные CrUX отличаются от моих данных RUM?» .

RUM также может предоставить более подробную информацию о конкретных проблемах с производительностью. Например, хотя CrUX может подразумевать, что было бы целесообразно улучшить соответствие требованиям bfcache, API bfcache notRestoredReasons может точно сообщить, почему загрузка конкретной страницы не может быть обслужена из bfcache.

Типы навигации в CrUX API

Чтобы просмотреть типы навигации в API, включите в запрос метрику navigation_types или не задавайте метрику, чтобы были включены все метрики:

export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.com", metrics: ["navigation_types"]}'

Формат запроса более подробно описан в документации API , включая объяснение того, как получить ключ API , и руководство по API . Это вернет такой объект:

{
  "record": {
    "key": {  "origin": "https://example.com" },
    "metrics": {
      "navigation_types": {
        "fractions": {
          "navigate": 0.5335,
          "navigate_cache": 0.2646,
          "reload": 0.0885,
          "restore": 0.0023,
          "back_forward": 0.0403,
          "back_forward_cache": 0.0677,
          "prerender": 0.0031
        }
      }
    },
    "collectionPeriod": {
      "firstDate": { "year": 2024, "month": 3, "day": 6 },
      "lastDate": { "year": 2024, "month": 4, "day": 2 }
    }
  }
}

В ответе CrUX сообщает метрику navigation_types как объект с долей загрузки страниц для каждого из типов навигации. Каждая дробь представляет собой значение от 0.0 (обозначающее 0 % загрузок страниц) до 1.0 (обозначающее 100 % загрузок страниц) для данного ключа.

Из этого ответа видно, что за период сбора данных, начинающийся с 6 марта 2024 г. (до 2 апреля 2024 г. включительно), 6,77% переходов (загрузок страниц) обслуживались из bfcache браузера. Аналогичным образом, некоторые другие дроби могут помочь определить возможности оптимизации загрузки страниц. Обратите внимание, что для любого данного ключа (включая комбинацию URL-адреса или источника и форм-фактора) дроби navigation_types в сумме будут составлять примерно 1,0.

Типы навигации в API истории CrUX

API истории CrUX может предоставить временные ряды для типов навигации с до 25 точками данных на каждую фракцию, что позволяет визуализировать эти дроби с течением времени. Чтобы изменить запрос с CrUX API на CrUX History API, запустите его с конечной точкой queryHistoryRecord вместо queryRecord . Например, наш CrUX History Colab отображает метрику navigation_types в виде столбцов, расположенных друг над другом:

На предыдущем снимке экрана история доступна только для трех периодов сбора данных (по 28 дней каждый с интервалом 7 дней). После полного заполнения он будет охватывать все 25 периодов сбора данных. Визуализация этой истории позволяет подтвердить, что оптимизации вступили в силу или пошли на спад. Это особенно актуально для настройки HTTP-кэша, оптимизации страницы для bfcache и предварительной отрисовки.

Типы навигации в CruX BigQuery

Таблицы CrUX BigQuery теперь включают запись navigation_type , созданную для каждого типа, а сводные материализованные представления включают несколько столбцов navigation_types_* — по одному для каждого типа.

Подробные таблицы

Подробная схема таблицы в CrUX BigQuery предоставляет подробные гистограммы для показателей веб-производительности, которые позволяют нам показать в этом примере анализа, как определенные типы навигации могут коррелировать с мгновенной или хорошей производительностью загрузки.

В качестве примера мы рассмотрели долю back_forward_cache и ее корреляцию с тем, как часто страницы загружаются мгновенно ( instant_lcp_density определяется как LCP <= 200 мс) и как часто наблюдается хороший LCP ( good_lcp_density определяется как LCP <= 2500 мс). Мы наблюдали сильную статистическую корреляцию между back_forward_cache и instant_lcp_density (ρ=0,87), показанную на следующем графике, а также умеренную корреляцию между back_forward_cache и good_lcp_density (ρ=0,29).

Colab для этого анализа хорошо прокомментирован; здесь мы обсуждаем только запрос, который извлекает дроби Navigation_types для 10 тысяч самых популярных источников из подробных таблиц в CrUX BigQuery:

• Мы получаем доступ к таблице all.202403 здесь (см. предложение FROM ), фильтруем form_factor для phone и выбираем источники с рейтингом популярности <= 10000 для топ-10 тысяч самых популярных источников (см. предложение WHERE ).
• При запросе метрики navigation_types в BigQuery необходимо разделить на общее количество фракций navigation_types , так как они будут суммироваться только для каждого источника, а не для каждой комбинации (происхождение, форм-фактор).
• Не все источники будут иметь navigation_types , поэтому рекомендуется использовать SAVE_DIVIDE .

WITH tmp AS (
  SELECT
    origin,
    SUM(navigation_types.navigate.fraction) AS navigate,
    SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
    SUM(navigation_types.reload.fraction) AS reload,
    SUM(navigation_types.restore AS restore,
    SUM(navigation_types.back_forward.fraction) AS back_forward,
    SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
    SUM(navigation_types.prerender.fraction) AS prerender,
    SUM(navigation_types.navigate.fraction
      + navigation_types.navigate_cache.fraction
      + navigation_types.reload.fraction
      + navigation_types.restore.fraction
      + navigation_types.back_forward.fraction
      + navigation_types.back_forward_cache.fraction
      + navigation_types.prerender.fraction) AS total
  FROM
    `chrome-ux-report.all.202403`
  WHERE
    experimental.popularity.rank <= 10000 AND
    form_factor.name = 'phone'
  GROUP BY
    origin
)

SELECT
  origin,
  ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
  ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
  ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
  ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
  ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
  ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
  ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
  tmp

Материализованные таблицы

Когда сводки достаточно, зачастую целесообразнее (и дешевле) вместо этого запросить материализованные таблицы . Например, следующий запрос извлекает доступные данные navigation_types из таблицы chrome-ux-report.materialized.device_summary . В этой таблице указаны месяц, происхождение и тип устройства.

SELECT
  yyyymm,
  device,
  navigation_types_navigate,
  navigation_types_navigate_cache,
  navigation_types_reload,
  navigation_types_restore,
  navigation_types_back_forward,
  navigation_types_back_forward_cache,
  navigation_types_prerender
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://example.com' AND
  navigation_types_navigate IS NOT NULL
ORDER BY
  yyyymm DESC,
  device DESC

Обратите внимание, что сумма этих дробей не составит 1,0 на строку, поэтому необходимо разделить каждую дробь на сумму результатов, по которым будет интерпретироваться запрос.

Причина этого в том, что дроби navigation_type в chrome-ux-report.materialized.device_summary — как и плотности гистограмм — добавляются до 1,0 на источник, а не на источник и устройство на дату. Это позволяет просмотреть распределение типов навигации по устройствам:

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

В этом результате запроса дроби отражают процент загрузки страниц для источника https://www.google.com : 6,63% этих загрузок страниц имели тип навигации back_forward на телефоне, 1,79% на настольном компьютере и 0,09% на планшете.

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

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

SELECT
  device,
  navigation_types_back_forward_cache /
    (navigation_types_back_forward + navigation_types_back_forward_cache)
    AS back_forward_cache_hit_rate
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

Таким образом, похоже, что высокая скорость back_forward на телефонах связана не с меньшим использованием bfcache, а скорее с отражением того, как пользователи чаще перемещаются вперед и назад на телефонах.

Типы навигации на панели управления CruX

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

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

Заключение

Мы надеемся, что разбивка типов навигации в Crux окажется для вас полезной и поможет вам понять и оптимизировать производительность вашего сайта. Обеспечивая эффективное использование HTTP-кэширования, bfcache и предварительной визуализации, сайты могут добиться гораздо более быстрой загрузки страниц, чем загрузки страниц, требующие обратного обращения к серверу.

Мы также рады сделать данные доступными во всех различных точках доступа CrUX, чтобы пользователи могли использовать данные по своему усмотрению и видеть разбивку по типам по URL-адресам для тех, которые представлены в API-интерфейсах CrUX.

Нам бы хотелось услышать отзывы об этом дополнении к CrUX в социальных сетях или в дискуссионной группе CrUX .