Лабораторные замеры из Lighthouse выдают разные цифры даже для одной и той же страницы, потому что тестовая среда условна и повторить поведение живой аудитории не может. Настоящий сайт работает иначе: у посетителей разные телефоны, сети и привычки, и именно их суммарный опыт решает, останется человек на ресурсе или уйдёт к конкуренту. Chrome User Experience Report собирает этот реальный опыт от самих посетителей Chrome и превращает его в агрегированные метрики качества страниц. Сервис CrUX Dashboard на базе Looker Studio визуализирует полевую статистику в виде помесячного тренда Core Web Vitals по конкретному сайту, поэтому владелец видит динамику LCP, INP и CLS без единой строки кода. Ниже разобрано, откуда набор берёт цифры, какими ограничениями он скован, как подключить дашборд за пять шагов, как читать стрелки улучшения и ухудшения и чем полевые данные дополняют привычные инструменты оптимизатора.
Что представляет собой CrUX и откуда берутся полевые данные
CrUX, развёрнутое название которого Chrome User Experience Report, представляет собой публичный набор полевых данных, который команда Chrome ведёт с 2017 года. Источник выборки виден из названия: отчёты приходят от самих пользователей браузера, согласившихся в настройках делиться историей посещений. Данные анонимизируются и агрегируются, поэтому персональных сведений в наборе нет, зато каждая строка отражает суммарный опыт тысяч реальных загрузок страниц.
Полевые данные принципиально отличаются от лабораторных. Lighthouse запускает эмулированный прогон в одинаковых условиях, а CrUX фиксирует то, что пережили настоящие посетители на настоящих устройствах: медленный мобильный интернет, фоновые вкладки, тяжёлые рекламные баннеры. Скользящее окно равно 28 дням, то есть каждая точка отчёта описывает поведение аудитории за последние четыре недели, а обновление набора происходит раз в месяц, обычно во второй декаде. Разовый скачок посещаемости или краткий сбой хостинга не способен резко изменить картину, метрики движутся плавно. Для трендов это плюс, для оперативной реакции на инциденты минус.
Главная точка отсчёта – 75-й перцентиль. Набор сообщает не среднее значение, а уровень, ниже которого лежит опыт 75% загрузок. Логика здравая: довольна ли аудитория в целом, определяется состоянием большинства, а не удачливого меньшинства. Пороги Core Web Vitals такие. LCP до 2,5 секунды попадает в хорошую зону, от 2,5 до 4,0 секунды требует улучшений, дальше считается плохим. INP хорош до 200 миллисекунд, терпим до 500, выше уже провал. CLS укладывается в норму при значениях до 0,1, границей плохой зоны служит 0,25. Все три метрики обязаны держаться в зелёной зоне одновременно, иначе общая оценка Core Web Vitals падает. С марта 2024 года третье место в тройке занимает INP, заменивший FID: новая метрика измеряет задержку отклика интерфейса на всём сроке жизни страницы, а не только на первом впечатлении.
Порог видимости, уровень origin и прочие ограничения набора данных
Ограничения CrUX полезно держать в голове до первого запроса, иначе цифры вызовут недоумение. Первое касается браузера: выборку образуют только посетители Chrome, согласовавшие передачу статистики. Посетители с другими браузерами и те, кто отключил сбор данных, в отчёт не попадают. В большинстве регионов это устойчивое большинство трафика, однако доля охвата различается по странам и нишам, поэтому сопоставлять CrUX с полной аналитикой посещений напрямую некорректно.
Второе ограничение связано с порогом видимости. Публичные данные публикуются только для тех origin и URL, где набирается достаточно статистики, точное минимальное количество посетителей не раскрывается. На практике это значит, что молодому сайту, разделу с низким трафиком или свежей странице отчёт не достанется: дашборд ответит, что данные недоступны. Спасение в том, чтобы смотреть уровень origin целиком, а не отдельные адреса, и подождать один или два цикла обновления, пока аудитория накопится.
Третье разграничение касается детализации. Под origin понимается домен вместе с протоколом, например https://example.com. По origin данные доступны в дашборде, а по отдельным URL они существуют в API и в PageSpeed Insights, при условии, что конкретная страница собирает достаточно собственных загрузок. Четвёртое ограничение временное: отчётность ежемесячная, без понедельной детализации, поэтому сезонные всплески внутри месяца растворяются в 28-дневном окне. Наконец, в набор попадают только публично доступные страницы, закрытые авторизацией зоны остаются невидимыми.
Подключение дашборда CrUX в Looker Studio и первые настройки
Дашборд построен на Looker Studio, бесплатном инструменте визуализации от Google, и распространяется готовым шаблоном, который копируется в личное хранилище отчётов. Настраивать диаграммы с нуля не требуется, весь путь занимает несколько минут:
- Войти в аккаунт Google, без авторизации Looker Studio отчёты не открывает;
- Открыть страницу дашборда CrUX в сервисе Looker Studio;
- Вставить в поле ввода адрес origin в формате https://example.com вместе с протоколом;
- Нажать кнопку создания отчёта и дождаться копирования шаблона в личный кабинет;
- Переименовать отчёт понятным именем и сохранить ссылку в закладках для ежемесячных проверок.
Если после вставки адреса появляется сообщение о недоступности данных, причина почти всегда в пороге видимости: origin слишком новый или мало посещаем. Дашборд работает исключительно на уровне origin, отдельный URL в него не вставить, для адресов страниц применяют API или PageSpeed Insights.
Разделы отчёта, разбивка по метрикам и типам устройств
Отчёт состоит из нескольких связанных страниц. Первая страница показывает сводную оценку Core Web Vitals: три главных метрики одновременно, по месяцам и по устройствам. Дальше идут отдельные страницы для LCP, INP и CLS, каждая со своей гистограммой распределения. По горизонтальной оси отложены значения метрики, по вертикальной доля загрузок, а линия перцентиля отмечает положение 75-го процентиля. Цветовая шкала повторяет пороги: зелёная хорошая зона, жёлтая зона улучшений, красная проблемная область.
Фильтр по типам устройств переключает срез между телефонами, десктопами и планшетами. Разбивка критична, потому что три аудитории живут в разных условиях: телефоны чаще встречают медленные сети и слабые процессоры, поэтому LCP на телефонах почти всегда хуже десктопного. Сравнение срезов подсказывает направление поиска: если на десктопе все метрики зелёные, а на телефонах INP красный, проблема в объёме и тяжести исполняемого кода, а не в сервере.
Главная ценность помесячной ленты – это стрелки рядом с метриками. Зелёная стрелка фиксирует улучшение относительно предыдущего месяца, красная стрелка фиксирует ухудшение. Нюанс, который путает новичков: для LCP, INP и CLS меньшее значение лучше, поэтому падение числа на графике оборачивается зелёной стрелкой. Читается лента по знаку изменения оценки, а не по направлению кривой.
Помесячный тренд и чтение перцентилей на числовом примере
Перцентиль проще всего понять на конкретном значении. Запись LCP p75 равен 2,6 секунды означает, что 75% загрузок завершили отрисовку главного контента быстрее 2,6 секунды, а каждая четвёртая загрузка была медленнее. Именно поэтому оценка считается честной: она отсекает и молниеносные выборки, и катастрофические хвосты, оставляя картину типичного опыта аудитории.
Пусть дашборд по origin в срезе телефонов показывает такие значения 75-го перцентиля:
| Месяц | LCP, с | INP, мс | CLS |
|---|---|---|---|
| Апрель | 2,8 | 220 | 0,14 |
| Май | 2,6 | 210 | 0,10 |
| Июнь | 2,4 | 340 | 0,09 |
| Июль | 2,3 | 290 | 0,08 |
| Август | 2,2 | 210 | 0,07 |
Чтение по месяцам выглядит так. LCP улучшается пять месяцев подряд, каждая точка помечена зелёной стрелкой, а с июня метрика закрепилась в хорошей зоне ниже порога 2,5 секунды. CLS в апреле нарушал границу 0,1, в мае опустился точно к ней и дальше ушёл в устойчивую зелёную зону, значит смещения блоков при загрузке удалось поставить под контроль. INP живёт своей жизнью: в мае он приблизился к порогу 200 миллисекунд, в июне скакнул до 340, откатился к 290 в июле и к 210 в августе. Красные стрелки в июне и июле сигнализируют об ухудшении, и даже августовское снижение не переводит метрику в хорошую зону.
Итог по набору: origin не получает общую оценку "хорошо", потому что INP на 75-м перцентиле держится выше 200 миллисекунд. Одна неудачная метрика перечёркивает две успешные, и в этом самое полезное свойство тройки: она не даёт успокоиться после двух красивых графиков. Обратная ситуация тоже показательна: выросший с 0,07 до 0,12 CLS зажигает красную стрелку даже при положительной динамике остальных показателей. Дальнейшая логика понятна: приоритет за сокращением длинных задач в исполняемом коде, за выносом сторонних скриптов и оптимизацией обработчиков ввода, а ежемесячная проверка стрелок подтверждает или опровергает эффект каждого релиза.
История глубже месяца через BigQuery и свободные выборки в SQL
Дашборд удобен, но хранит ограниченную историю и жёсткие срезы. Когда нужен горизонт за два года или произвольный перцентиль вроде 95-го, очередь за BigQuery, где публичный набор CrUX лежит в открытом доступе. Таблицы устроены помесячно: набор all содержит версии вида all.202508, каждая соответствует 28-дневному окну своего месяца, а региональные варианты вида country.de.202508 фильтруют выборку по стране. Глубина архива тянется к 2017 году, поэтому на публичных данных можно восстановить полную хронику оптимизаций.
Каждая строка таблицы содержит origin, тип устройства, класс эффективного соединения и полные гистограммы метрик. Из гистограммы достаётся любой перцентиль, а не только 75-й, и считается доля загрузок в каждой цветовой зоне. Пример запроса, вытаскивающего p75 LCP для origin в срезе телефонов, выглядит так:
SELECT metrics.largest_contentful_paint.percentiles.p75 AS lcp_p75
FROM chrome-ux-report.all.202508
WHERE origin = "https://example.com" AND form_factor = "phone"
Подобные выборки открывают практичные сценарии: сравнение LCP до и после переезда на новый хостинг или сопоставление телефонов и десктопов по месяцам. Запросы к публичному набору укладываются в бесплатный месячный лимит BigQuery, поэтому разовый аналитический цикл не требует бюджета. Слабое место тоже есть: SQL требует навыка, поэтому для регулярного просмотра тренда дашборд остаётся основным инструментом, а BigQuery берут в дело для глубоких разовых расследований.
Чем CrUX дополняет Search Console и PageSpeed Insights
Три инструмента отвечают на разные вопросы, и путать их назначения невыгодно. Search Console в отчёте Core Web Vitals группирует страницы сайта по статусу: хорошая группа, группа требующая улучшений и проблемная группа. Это карта территорий: видно, какие шаблоны сайта страдают, сколько адресов в каждой категории и на чём сосредоточить силы. Внутри каждой группы сервис подсказывает типовую причину, например длинные задачи в скриптах или отсутствие размеров у изображений. Детального тренда по origin и гистограмм там нет, да и доступ открывается только владельцу подтверждённого ресурса.
PageSpeed Insights решает обратную задачу. Сервис прогоняет конкретный URL через лабораторный тест и попутно показывает полевые данные CrUX по этому адресу или по origin целиком. Это инструмент точечной диагностики: найдя в Search Console проблемный шаблон, оптимизатор прогоняет его типичного представителя и получает список конкретных рекомендаций. Ограничение то же: разовый срез за 28 дней без истории, поэтому два прогона подряд с разными числами ещё не означают тренд.
Дополняет картину CrUX API, который отдаёт ежедневный срез за 28 дней по origin и по отдельным URL и подходит для автоматизации: скрипт раз в сутки опрашивает ключевые адреса и сообщает, когда p75 пересекает порог. Складывается связка ролей. Search Console отвечает на вопрос, где проблемы. PageSpeed Insights отвечает, что именно чинить на конкретной странице. CrUX Dashboard показывает, улучшается ли сайт в целом из месяца в месяц. BigQuery закрывает глубину истории, API берёт на себя мониторинг.
Осталась дисциплина. Полезный ритуал выглядит просто: во второй половине месяца, когда обновляется набор, открывается дашборд, стрелки сравниваются с планом работ, и регресс любой метрики немедленно попадает в список задач. Полевые данные невозможно обмануть лабораторными ухищрениями, они отражают поведение настоящих людей, и сайт с устойчиво зелёным трендом получает не только поисковые преимущества, но и главное, посетителей, которые не уходят, не дождавшись ответа страницы.