Опубликовано: 11 февраля 2025 г.
Отчет об опыте пользователей Chrome (CrUX) за февраль 2025 года включает в себя ряд интересных новых (и измененных!) показателей:
- Крупнейшие части изображения Contentful Paint (LCP) и типы ресурсов
- Подробности о времени туда и обратно (RTT)
- Удаление измерения «Эффективный тип соединения» (ECT).
Каждый из них обеспечивает более глубокое понимание показателей производительности источников и URL-адресов, доступных в CrUX, и в этом посте мы подробно объясним, почему.
Диагностическая информация LCP
Первоначально мы представили концепцию подразделений LCP в Google I/O 2022 как эффективный метод разбиения времени LCP для страниц с изображениями LCP на более мелкие компоненты, чтобы гарантировать, что вы тратите свои усилия на оптимизацию правильных причин высокого LCP.
Анализ лабораторных данных HTTP Archive в этом докладе показал, что время загрузки изображения часто составляло наименьшую часть времени LCP. Многие лабораторные инструменты (включая собственный Lighthouse от Google) часто сосредоточены на советах по оптимизации форматов и размеров изображений, чтобы сократить время загрузки и повысить производительность. Несмотря на то, что это все же верно, анализ показал, что совету, возможно, было придано слишком большое значение, и более серьезная проблема заключалась в задержках, прежде чем изображение было найдено браузером и начало загружаться.
Хотя анализ лабораторных данных может быть полезен, способы использования Интернета в реальной жизни часто могут отличаться, поэтому возможность видеть эти части полевых данных имеет решающее значение. Сообщение, опубликованное в прошлом году, подтвердило это распространенное заблуждение о том, как оптимизировать LCP с помощью полевых данных.
Подчасти изображения LCP
В этом выпуске владельцы сайтов могут проверять свои собственные сайты на наличие частей изображения LCP на уровне источника или URL-адреса.
Подчасти доступны только для изображений, и они не включают изображения первого видеокадра (которые немного сложнее, поскольку мы не можем измерить полное время загрузки). Текстовые части также не включены, поскольку они менее полезны и могут исказить номера LCP изображений. Для сайтов, которые в основном состоят из текстовых LCP, общие показатели TTFB и общие показатели FCP являются полезными разбивками, однако обратите внимание, что они относятся ко всем LCP, а не только к текстовым LCP. Наконец, части изображения собираются только при полной загрузке страницы — в отличие от самой метрики LCP, которая также собирается при обратной навигации и предварительно обработанных страницах.
Эти данные были добавлены в CrUX API и CrUX History API с февраля 2025 года (примечание: не BigQuery). API истории CrUX при запуске содержит данные за две недели, и со временем они вырастут до полной 25-недельной истории. API предоставляют данные в виде 75-го процентиля каждой части, выраженного в миллисекундах.
Например, чтобы получить части изображения LCP для https://web.dev/ для просмотров страниц PHONE , вы можете использовать следующую команду Curl (заменив API_KEY своим собственным ключом ):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
И вы получите что-то вроде этого:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Мы обновили инструмент CrUX Vis , включив в него эти данные, и ожидаем, что другие сторонние инструменты, использующие API-интерфейсы CrUX, также будут предоставлять эти ценные данные:
В этом примере мы видим, что для популярного медиа-сайта продолжительность загрузки ресурса является наименьшей составляющей. Реальные возможности для улучшения этого сайта заключаются в TTFB и задержке загрузки ресурсов , с меньшей возможностью задержки рендеринга элементов .
Высокие значения в каждом подразделе указывают на различные проблемы:
- Высокое время до первого байта (TTFB) обычно указывает на проблемы с сервером, сетью или перенаправлением, как описано в разделе «Оптимизация TTFB» .
- Высокая задержка загрузки ресурса указывает на то, что образ LCP поздно обнаруживается браузером — например, образ LCP, внедренный клиентским JavaScript, для запуска которого требуется некоторое время.
- Высокая продолжительность загрузки ресурса — вот где вам следует подумать об уменьшении размера загружаемого изображения.
- Высокая задержка рендеринга элемента — это когда изображение доступно (возможно, через
<link rel=preload>, но не используется в течение длительного времени — опять же, часто из-за того, что для отображения изображения требуется JavaScript на стороне клиента.
Мы надеемся, что предоставление этих данных в CrUX как на уровне источника, так и на уровне URL-адреса (с учетом обычных критериев приемлемости ) поможет сайтам упростить оптимизацию своих показателей LCP.
Типы ресурсов LCP
Поскольку части лучше всего просматривать для LCP изображений, CrUX ограничивает эти данные только страницами с изображениями. Поэтому важно понимать, сколько из ваших LCP являются графическими LCP, а не текстовыми (например, заголовками <h1> и длинными абзацами).
В дополнение к частям изображений LCP API-интерфейсы CrUX теперь также включают разбивку ресурсов, показывающую разделение загрузки страниц LCP между текстом и изображениями.
Например, чтобы получить типы ресурсов LCP для https://web.dev/ для просмотров страниц PHONE , вы можете использовать следующую команду Curl (опять же, заменяя API_KEY своим собственным ключом ):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
И вы получите что-то вроде этого:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
CrUX Vis также был обновлен для отображения этих данных:
Например, для домашней страницы web.dev мы видим, что 98,5% LCP на самом деле были текстовыми LCP, поэтому части изображений LCP менее полезны для этой страницы. В этом случае мы можем использовать исходные метрики TTFB и FCP как потенциально лучшую диагностическую разбивку.
Типы ресурсов LCP — еще один полезный диагностический инструмент для понимания и улучшения LCP, особенно для определения того, насколько полезны части изображения LCP.
Диагностическая информация RTT
Мы также расширили показатель RTT, впервые представленный в августе 2024 года .
Три бункера RTT
Мы добавили три контейнера в API CrUX, показывающие три группы плотностей RTT:
| Задержка сети | Начинать | Конец |
|---|---|---|
| Низкий | 0 миллисекунд | < 75 миллисекунд |
| Середина | 75 миллисекунд | < 275 миллисекунд |
| Высокий | 275 миллисекунд | ∞ |
Эти интервалы более информативны, чем предыдущие категории ECT , которые включали в категорию 4g все, что длилось менее 270 миллисекунд. Благодаря достижениям в области сетевых технологий, произошедшим с момента их запуска, большинство сайтов видели большую часть своего трафика в этой категории, что делало эту категоризацию менее полезной.
Вот почему мы предлагаем использовать ярлыки «низкое» , «среднее» и «высокое» распределение вместо обычных ярлыков «хорошее» , «нужно улучшить » и «плохое» . Они не являются метриками, которые владелец сайта может улучшить самостоятельно, и, следовательно, являются диагностическими метриками, позволяющими понять другие метрики и понять, почему они могут отличаться от ожидаемых. Они также могут помочь объяснить, почему другие показатели меняются со временем, несмотря на то, что сайт не меняется, если они показывают изменения в пользовательской базе.
Эти бины доступны в API CrUX, например для web.dev для просмотров страниц PHONE (опять же, заменяя API_KEY своим собственным ключом ):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Что возвращает что-то вроде этого:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Контейнеры отображаются в CrUX Vis, когда выбраны дистрибутивы :
RTT в BigQuery
Помимо расширения метрики RTT в API-интерфейсах CrUX за счет включения три-бинов, мы также сделали данные доступными в ежемесячном наборе данных BigQuery, включая полную гистограмму в сегментах по 25 миллисекунд в необработанных таблицах и три-бинах, а также значения p75 в материализованных таблицах .
Это позволяет глубже понять распределение данных за пределами три-бинов, доступных в API-интерфейсах CrUX. Это также позволяет нам воссоздать разбивку ECT, которая была удалена из CrUX в этом месяце (подробнее об этом позже) — с небольшим изменением порога в 275 миллисекунд для 4g вместо предыдущего порога в 270 миллисекунд. Разбивка ECT (теперь полученная из данных RTT) по-прежнему доступна в материализованных таблицах CrUX BigQuery, поэтому такие инструменты, как панель мониторинга CrUX, могут продолжать отображать эту разбивку.
Набор данных BigQuery также включает данные по странам (согласно стандарту ISO 3166-1 ). Это позволяет провести более глубокий анализ, который может быть полезен для объяснения того, почему показатели производительности у некоторых пользователей хуже. Например, мы можем просмотреть данные о пользователях Google Phone, просмотрев данные https://www.google.com :
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Затем мы визуализируем данные на географической карте:
https://www.google.com( исходные данные с интерактивной диаграммой ).
Мы видим, что в то время как в большей части мира (особенно в «западном мире») есть очень хорошие RTT, в Африке к югу от Сахары, в некоторых частях Ближнего Востока и в некоторых частях Азии возникают более серьезные проблемы. На самом деле график ограничен 500 миллисекундами RTT, поскольку использование полных данных искажало цвета — особенно в Эритрее с 75-м процентилем в 3850 миллисекунд!
Это также может быть полезно при изменении структуры трафика. Например, большая доля пользователей из стран с более высоким RTT может объяснить худшую статистику Core Web Vitals, несмотря на то, что сайт ничего не меняет.
Хотя сайты не могут напрямую улучшить RTT, предоставление доступа к этим данным посетителям сайта позволяет лучше понять пользователей вашего сайта по всему миру. Это также открывает множество возможностей для анализа в будущем, и мы надеемся, что исследователи найдут интересные идеи из этого набора данных.
Удаление измерения ECT
Последним изменением в выпуске от февраля 2025 года является прекращение использования измерения «Тип эффективного соединения» (ECT) из BigQuery (мы уже удалили RTT из API с сентября 2024 года, когда тогда представили метрику RTT в качестве ее замены).
Как упоминалось ранее в этой статье, метрика RTT позволяет получить более детальное представление о деталях подключения посетителей сайта. Вы даже можете воссоздать сегменты ECT на основе этих гистограмм. (Технически ECT должен представлять собой комбинацию RTT и скорости нисходящей линии связи , но Chrome всегда использовал только RTT .)
Важным отличием является то, что ECT был измерением CrUX , то есть другие показатели можно было сегментировать с помощью ECT. RTT — это метрика CrUX , а не измерение, поэтому невозможно просмотреть LCP, например, по RTT, а можно увидеть только RTT по другим измерениям (типу устройства и стране).
Это может показаться более ограничивающим, но переход от измерения к метрике на самом деле открывает больше данных в CrUX. Это связано с тем, что у CrUX есть определенные минимальные пороговые значения, прежде чем мы сможем отображать данные. В 2022 году мы уже сделали измерения необязательными, то есть удалили ECT или устройство, где необходимо сообщать на более высоком уровне, но метрики, которых не было при большинстве загрузок страниц ( Взаимодействие с следующей отрисовкой (INP) , различные типы навигации, а теперь и части изображений LCP), часто были недоступны для источников в BigQuery.
Уменьшая количество измерений, данные становятся менее сегментированными, поэтому количество источников, отвечающих этим минимальным требованиям, увеличивается. В январе мы сообщаем INP для 68,1% стран происхождения, тогда как в декабрьском наборе данных мы сообщаем INP только для 64,5% стран происхождения. Этот механизм также применяется к типам навигации, подразделам LCP и типам ресурсов в этом выпуске — все они получают выгоду от удаления измерения ECT. В API Crux расширенное покрытие вступило в силу с начала февраля.
Столбцы ECT останутся в BigQuery для обеспечения согласованности с предыдущими наборами данных, а данные ECT в материализованных представлениях останутся доступными, но на основе информации RTT (с разницей в 5 миллисекунд для 3g и 4g , как отмечалось ранее) в дополнение к новым RTT p75 и тройным бункерам.
Заключение
Добавление дополнительных показателей в общедоступный набор данных CrUX дает владельцам сайтов и исследователям гораздо больше информации, которая поможет диагностировать и, в конечном итоге, устранять проблемы с производительностью.
Будучи общедоступным набором данных, CrUX имеет определенные ограничения на уровень детализации, которую мы можем показать — например, селекторы отдельных элементов никогда не смогут отображаться в CrUX. Владельцам сайтов, которым нужен такой уровень детализации, настоятельно рекомендуется внедрить решение RUM, которое не будет столь ограниченным.
Однако агрегированные данные более высокого уровня, такие как те, которые подробно описаны в этом посте, могут помочь преодолеть разрыв между знанием о том, что у вас есть проблема, и причинами ее существования. Мы надеемся, что эти дополнительные данные окажутся полезными. Если у вас есть какие-либо отзывы или вопросы , дайте нам знать в дискуссионной группе !