RUM для веб-приложений: настройка Core Web Vitals и алертинг

Почему real user monitoring без Core Web Vitals вводит в заблуждение

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

Real user monitoring без core web vitals даёт поток сырых замеров, из которых трудно вывести решение. Медиана времени загрузки выглядит ровной, потому что её вытягивают быстрые визиты, а медленный хвост на конкретной модели устройства или в конкретной сети в неё не попадает. Цифры есть, а где именно пользователь теряет терпение — не видно.

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

Связка real user monitoring и core web vitals закрывает пробел: метрики фронтенда собираются с настоящих сессий, разбиваются по типу страницы, устройству и географии, а алертинг по метрикам реагирует на деградацию хвоста, а не среднего. Ниже — как настроить сбор и пороги так, чтобы это стало рабочим сигналом, а не ещё одной панелью наблюдения.

Что даёт сбор метрик с реальных сессий пользователей

Жалобы на «тормозит» появляются, когда проблема уже разрослась, а проверки на быстрой машине всё это время показывают норму. Причина в разрыве: синтетические прогоны идут с одного узла, а посетители — с сотен моделей устройств, разных сетей и на пике нагрузки. Сбор метрик с пользователей, или real user monitoring, этот разрыв закрывает: браузер каждого гостя отдаёт полевые значения Core Web Vitals — время отрисовки основного контента, отзывчивость на действие, сдвиги вёрстки — с привязкой к странице, устройству, региону и версии релиза.

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

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

Итог для мониторинга веб-приложений — регрессия ловится до обращений, а не после. Разбираем, как разворачивается сбор и где ставятся пороги оповещений.

Варианты сбора данных: агент, синтетика, гибридный режим

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

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

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

Этапы внедрения: от инвентаризации страниц до регламентов

Внедрение мониторинга реальных пользователей (RUM) начинается не с панели с графиками, а с инвентаризации: какие шаблоны страниц несут нагрузку, какие сценарии ведут к цели и где Core Web Vitals проседают на реальных устройствах. Дальше выстраиваем работы так, чтобы к первому оповещению уже были готовы пороги, маршруты и регламент реакции.

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

2. Схема сбора. Определяем срезы для разбора: тип устройства, регион, канал связи, версия клиентской части. Так деградация у всех пользователей отделяется от проблемы одного сегмента.

3. Пороги оповещений. Считаем по перцентилям, а не по среднему — среднее скрывает медленные сессии. Для каждого показателя фиксируем окно наблюдения, чтобы короткий всплеск не поднимал на ноги всю команду.

4. Дедупликация оповещений. Сигналы одной аварии схлопываем по шаблону страницы, типу сбоя и времени: иначе один промах в разметке даёт сотни тревог, и мониторинг перестают читать.

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

6. Проверка на реальном трафике. Наблюдаем первые недели, сверяем показания с внешними источниками, прогоняем учебные тревоги и снимаем ложные срабатывания.

7. Передача. Отдаём схему сбора, настроенные пороги, маршруты и инструкции по разбору инцидентов — мониторинг живёт дальше без нас.

Конфигурации сбора, дашборды и регламенты реагирования

Каждое правило сбора и каждый алерт остаются у вас как рабочий артефакт, а не устная договорённость. Комплект ниже мы передаём по завершении настройки real user monitoring — его достаточно, чтобы вести наблюдение и развивать его своей командой.

• Конфигурации сбора: доля сэмплирования, перечень метрик, разбивка по маршрутам и типам устройств — с пояснением, почему пороги выбраны именно такими.
• Дашборды: сводка по Core Web Vitals в разрезе страниц и групп пользователей, отдельные панели под мобильный трафик; у каждой — подпись с нормой и владельцем.
• Политики доступа: роли наблюдателя, дежурного и администратора, список получателей уведомлений, права на смену порогов; ключи лежат в вашем хранилище секретов.
• Регламент реагирования: при каком отклонении кто поднимается и за какое время, что фиксируется в разборе, когда алерт возвращается в режим наблюдения.
• Документация по мониторингу: схема пути данных от браузера до панели, словарь метрик, порядок подключения новых страниц и проверка, что датчик жив.
• Порядок отката конфигурации к предыдущей версии и разбора ложных срабатываний, чтобы правки не теряли историю.
• Журнал изменений порогов и правило их пересмотра — алерты не замыливаются и остаются значимыми после запуска.

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

Кейс интернет-магазина: доля медленных сессий упала втрое

До проекта фронтенд проверяли синтетическими замерами с одной точки: скрипт открывал главную и отдавал ровный результат. Реальная картина расходилась с ним — доля медленных сессий в пиковые часы держалась около 21%, а узнавали об этом из обращений в поддержку через несколько часов после начала деградации.

Что показал замер по живым сессиям

Замер по реальным сессиям (real user monitoring) разбили по типу страницы, устройству, региону и номеру релиза. Основной вклад давали карточки товара на мобильных: скорость отрисовки основного контента там была втрое хуже, чем на десктопе, а сдвиг вёрстки на листинге приходился на момент подгрузки баннеров. Часть деградаций приезжала вместе с релизом и жила до следующего — сравнить версии между собой было нечем.

Что изменили

Сбор метрик привязали к релизу и к странице, задали бюджеты по 75-му перцентилю отдельно для мобильных и настроили правила оповещений в Grafana с окном в 15 минут: короткий всплеск не будит дежурного, устойчивое отклонение поднимает инцидент. Сторонние скрипты вынесли за пределы критического пути отрисовки, карточка перестала блокировать контент подборками.

Доля медленных сессий снизилась с 21% до 7% — втрое, время реакции на инцидент сократилось с нескольких часов до 10-15 минут. Метрика перестала быть отчётом для галочки: регрессия видна на выкате и откатывается раньше, чем её заметят покупатели.

Чем real user monitoring отличается от синтетических проверок?

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

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

Сравнение подходов удобно свести к одной таблице:

Точки отказа у подходов разные. Синтетика не знает о сценарии, который не описали, а полевые данные без разметки не показывают, какой именно запрос съел время. Поэтому в отчёт кладут и распределение по страницам, и разбивку по этапам загрузки, а разбор ведут на выборке сессий с сохранённым контекстом.

В дежурном контуре роли расходятся ещё сильнее. Синтетика даёт бинарный сигнал и срабатывает мгновенно — на ней держат алертинг по доступности. Для полевых метрик порог ставят по скользящему окну и доле затронутых сессий: иначе один пользователь в плохой сети поднимает тревогу на всю команду.

Технические сомнения перед запуском сбора метрик

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

Нужны ли правки в коде приложения?

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

Как фильтруете ботов и выбросы в метриках?

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

Что с требованиями к данным и хранению?

Собираем обезличенные измерения: без содержимого полей и идентификаторов в открытом виде. Срок и регион хранения задаются политикой, согласие на аналитику связывается с баннером. Для проверки со стороны службы безопасности этого достаточно.

Обсудим задачу: что прислать и как начнём работу

Чтобы вернуться с оценкой внедрения, а не с уточняющими вопросами, нам нужен минимум вводных. Ниже — то, что заметно ускоряет старт: часть пунктов у команды обычно уже есть, остальное восстанавливаем на коротком созвоне.

• Список ключевых страниц и сценариев — оформление заказа, каталог, оплата: по ним снимаем показатели real user monitoring в первую очередь, а не «по всему сайту».
• Целевые пороги по метрикам: скорость отрисовки основного контента, отзывчивость на нажатие, визуальная стабильность. Достаточно сформулировать бизнес-требование («укладывается доля сессий не ниже заданной»), точные значения подберём вместе.
• Что уже настроено: синтетические проверки, лабораторные замеры, счётчики аналитики — чтобы не дублировать сбор и не спорить с существующими отчётами.
• Доступы: чтение к аккаунту мониторинга и аналитики, тестовый контур для проверки разметки, контакт ответственного за фронтенд.
• Каналы оповещений и дежурства: куда приходит сигнал о просадке (мессенджер, почта, система дежурств) и кто по нему реагирует в рабочее и нерабочее время.
• Срезы, которые важны для разбора: устройства, браузеры, регионы, тип соединения — от них зависит, где искать причину деградации.
• Календарь выкатов и крупных изменений на фронтенде — чтобы отличать регресс релиза от фонового шума сети.

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