Синтетический мониторинг и RUM: в чём разница и что нужно вам

Один подход проверяет сайт роботами по расписанию, другой — собирает данные с браузеров живых посетителей. Их постоянно противопоставляют, хотя отвечают они на разные вопросы. Разбираем без маркетинга: что умеет каждый, где их слепые зоны и почему для контроля доступности выбор на самом деле безальтернативен.

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

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

Ключевое различие — не технология, а вопрос

Синтетика отвечает на вопрос «работает ли сайт прямо сейчас?» — и отвечает всегда, даже в четыре утра, когда посетителей нет. RUM отвечает на вопрос «как сайт ощущается людьми?» — и отвечает только тогда, когда люди есть. Это различие тянет за собой всё остальное:

Для доступности выбор безальтернативен

Ответ на вопрос «упал ли сайт» может дать только синтетика: регулярные проверки снаружи, из нескольких точек, независимо от наличия посетителей. Проверка доступности (GET) — классическая синтетика: запрос страницы как от посетителя, контроль кода ответа и времени, из 13 точек мониторинга по расписанию. Ей не нужен ни трафик, ни доступ к коду сайта — и она одинаково зорко смотрит и в час пик, и ночью.

Есть и второй аргумент, специфичный для России: RUM показывает только тех, кто смог дойти до сайта. Если сайт недоступен из части регионов — из-за сбоя магистрали или блокировки, — эти посетители в RUM-данных просто не появятся, и картина останется благополучной. Синтетика из распределённых по стране точек ловит ровно этот класс проблем; мы разбирали его в статье о проверке доступности из России.

А зачем тогда RUM вообще?

Затем, что скорость — не доступность. Сайт может стабильно отвечать 200 и при этом мучительно грузиться у половины аудитории на мобильных. Вот это — территория полевых данных: они показывают реальный разброс по устройствам, сетям и регионам, и именно по ним Google считает Core Web Vitals для ранжирования.Что означают LCP, INP и CLS — в нашем разборе Core Web Vitals.

Хорошая новость: базовые полевые данные у вас, скорее всего, уже есть без всяких скриптов. Яндекс Метрика показывает скорость загрузки у реальных посетителей, а Google собирает CrUX-статистику по популярным сайтам автоматически. Ставить отдельный RUM-скрипт ради того, что уже собирают два бесплатных источника, — сомнительная сделка: лишний скрипт — это лишний вес страницы и лишняя зависимость. Мониторинг и веб-аналитика вообще отвечают на разные вопросы — об этом у нас есть отдельная статья.

Лаборатория против поля: почему цифры не сходятся

Классическое недоумение владельца сайта: синтетический тест скорости показывает 90 баллов, а полевые Core Web Vitals в жёлтой зоне — или наоборот. Это не ошибка одного из инструментов, а разные условия измерения. Синтетика меряет из хороших условий контрольной точки — стабильная сеть, одинаковое «устройство»; поле — со всех реальных устройств, включая пятилетние телефоны в переполненной сети метро. Лабораторная цифра отвечает «на что способен сайт», полевая — «что получают люди».

Расхождения читаются как диагноз. Лаборатория отличная, поле плохое — у вашей аудитории условия хуже лабораторных: тяжёлая страница добивает слабые устройства, дальние регионы упираются в сеть. Лаборатория плохая, поле приличное — аудитория лояльнее теста: сидит на быстрых устройствах, ходит по кэшированным страницам. Первый случай требует оптимизации, второй — обычно нет. И ещё одна особенность: полевые данные инертны, они агрегируются за 28 дней — деградацию после вчерашнего релиза поле покажет через недели, синтетика — следующим же замером. Поэтому ловить регрессии нужно синтетикой, а оценивать реальный опыт — полем.

Кому что: три типовых профиля

Практический итог

Не выбирайте между подходами — распределите роли. Доступность — только синтетика: внешние проверки по расписанию, из нескольких городов, с уведомлениями. Скорость у реальных людей — полевые данные, которые уже есть в Метрике и CrUX. Регулярный контроль скорости — синтетический замер по расписанию (интервал подбирается от 12 часов — чаще скорость мерить незачем): он даёт сравнимые от недели к неделе цифры и ловит деградацию после обновлений, до того как она отразится на полевых данных — они инертны и реагируют с задержкой в недели.