Заявка
Mobile · CWV

RUM

Real User Monitoring · Мониторинг реальных пользователей

RUM (Real User Monitoring) — это метод сбора метрик производительности прямо с браузеров реальных посетителей сайта. Показывает, как быстро страница грузится и отвечает у живых людей, а не в лаборатории.

RUM (Real User Monitoring) — это способ измерять скорость сайта по данным, которые браузеры реальных посетителей отправляют во время обычных визитов. Что это значит на практике: вместо одного тестового прогона на выделенной машине собирается статистика с разных устройств, сетей и версий браузеров.

Полевые данные показывают картину, которую не увидеть в лаборатории: дешёвый смартфон на медленном мобильном интернете грузит страницу иначе, чем ноутбук инженера. Именно такие замеры Google берёт для оценки Core Web Vitals — LCP, INP и CLS собираются в отчёте CrUX по живому трафику Chrome.

§ 01Что показывает

Мониторинг живых посетителей фиксирует три ключевых показателя загрузки: LCP (отрисовка крупного элемента), INP (отклик на действие) и CLS (сдвиг вёрстки). К ним добавляются TTFB, время до интерактивности и разбивка по типу устройства, стране и браузеру. Каждое значение привязано к конкретной сессии, поэтому видно не среднее по больнице, а распределение — например, 75-й перцентиль, по которому Google относит страницу к зоне Хорошо или Плохо.

§ 02Как измерить

Сбор полевых данных запускается двумя путями. Первый — готовый источник CrUX: агрегированные метрики Chrome доступны в PageSpeed Insights и Search Console в блоке Основные интернет-показатели. Второй — свой скрипт на базе браузерного API PerformanceObserver и библиотеки web-vitals, который отправляет замеры в аналитику. Такой вариант ловит данные всех браузеров, а не только Chrome, и позволяет размечать сессии по своим сегментам.

Кейс e-commerce

LCP 4.1 → 2.3 c — Интернет-магазин косметики на Shopify подключил RUM через web-vitals.js и слил данные в BigQuery. По 75-му перцентилю живого трафика LCP упал с 4.1 до 2.3 с за 8 недель, отказы снизились на 11%. Замер по CrUX и GA4 Web Vitals.

Кейс SaaS

INP 320 → 180 мс — B2B SaaS-платформа для HR с MRR $210k внедрила RUM на SpeedCurve и поймала медленный INP на дашборде реальных клиентов. После оптимизации обработчиков INP упал с 320 до 180 мс за 3 месяца. Динамика по 75-th перцентилю SpeedCurve и CrUX.

§ 03Что искажает замер

Измерение у реальных пользователей зависит от объёма трафика: на странице с десятком визитов в месяц перцентили скачут случайно. CrUX вообще не покажет отчёт, пока сайт не наберёт порог посещаемости. Замер смещают роботы и превью-запросы, кэширование на повторных заходах и расширения в браузере. Отдельная ловушка — усреднение: одно медленное устройство теряется в общем среднем, поэтому смотреть нужно 75-й перцентиль, а не арифметику.

§ 04С чем смотреть в связке

Field data отвечает на вопрос сколько у пользователей, но не объясняет почему. Для причин к нему подключают лабораторный аудит: Lighthouse и трассировку в PageSpeed Insights, которые разбирают конкретный прогон по этапам. Чем отличается один подход от другого: лаборатория стабильна и повторяема, поле отражает реальность. Пара из них закрывает цикл — поле ловит проседание метрики, синтетика показывает узкое место, а Looker Studio сводит динамику по датам.

Частые ошибки
01
Подмена RUM синтетическими лабораторными прогонами. Команда меряет скорость только в Lighthouse на быстром канале и считает это RUM. Реальные сессии на мобильном 4G игнорируются — страдает объективность оценки и доверие к отчётам. Как правильно: Разделяйте lab и field. Внедрите сбор реальных сессий через web-vitals.js и отправляйте данные в аналитику.
02
Усреднение метрик вместо анализа перцентилей. Смотрят на средний LCP, а он маскирует хвост медленных сессий. Google в CrUX оценивает 75-й перцентиль — половина реальных пользователей с проблемами остаётся вне поля зрения, позиции проседают. Как правильно: Считайте p75 и p95, а не среднее. Сравнивайте свои RUM-данные с порогами CrUX по каждой Core Web Vital.
03
Сбор RUM без сегментации по устройствам и сети. Все сессии сваливают в одну кучу — десктоп на оптике и смартфон на 3G. Реальная картина по мобайлу размывается, бюджет на оптимизацию уходит не туда, где теряется трафик. Как правильно: Сегментируйте RUM по типу устройства, стране и типу соединения. Стройте отдельные дашборды под mobile и desktop.
Часто спрашивают

RUM — частые вопросы про мониторинг реальных пользователей

RUM простыми словами — что это и зачем нужно?

+

RUM — это метод сбора метрик производительности прямо из браузеров живых посетителей сайта. Показывает реальную скорость загрузки и отклика страниц, а не результат тестового прогона. Данные собираются через JavaScript-скрипт на каждой сессии.

Field data отражают опыт настоящих людей на их устройствах и сетях, а лабораторный тест (например, Lighthouse) гоняет одну эмуляцию в стабильных условиях. Первый способ ловит разброс по 4G, слабым телефонам и географии — синтетика этого не видит.

Хорошими считаются LCP до 2,5 секунды, INP до 200 мс и CLS до 0,1 по 75-му перцентилю. Именно перцентиль реального пользовательского мониторинга Google берёт для оценки, а не среднее значение по всем визитам.

Обычно стартуют с бесплатного отчёта CrUX в PageSpeed Insights или Search Console — он уже агрегирует статистику Chrome за 28 дней. Для детализации по URL подключают web-vitals.js либо коммерческие платформы вроде SpeedCurve и Sentry.

Зависит от посещаемости: при трафике ниже порога CrUX просто не покажет отчёт, поэтому field-подход даст мало пользы. По опыту GUSAROV, на старте достаточно синтетики, а к сбору живых метрик переходят после 1000–2000 визитов в месяц.

Не нашли ответ?

Спросите Андрея Гусарова — отвечаю в течение 1-2 рабочих дней.

Нажимая, вы соглашаетесь с обработкой данных.