Мониторинг производительности сайта: синтетический мониторинг, RUM, пороги алертов и реакция
I. Почему «у меня открывается быстро» ничего не значит
Самая частая ошибка владельца сайта: главная открывается на его компьютере за две секунды — значит, с производительностью всё в порядке. Для зарубежного сайта это почти всегда заблуждение. Вы находитесь в Китае, идёте через домашний интернет, возможно, ещё и через ближайший кэш CDN. Ваши покупатели — в Европе, на Ближнем Востоке, в Латинской Америке: они идут через местные сети и обращаются к серверу через океан. Одна и та же страница у вас грузится за 1 секунду, а у них может грузиться 6.
Контринтуитивный вывод здесь такой:Мониторинг производительности должен измерять сеть и регион покупателя, а не ваши собственные. Измерение скорости с домашнего компьютера в Китае — это измерение канала «между вами и вашим сервером», и этот канал не даёт никакой информации о зарубежных покупателях.
Правильный подход — разместить пробы мониторинга в регионах, где действительно находятся покупатели, и обращаться к сайту через местные сети. Только такие цифры можно использовать для решений. О порогах метрик см.Core Web Vitals.
| Способ мониторинга | Как измерять | Плюсы | Ограничения |
|---|---|---|---|
| Замер с домашнего компьютера | Открыть в локальном браузере | Видно сразу | Не отражает зарубежных пользователей, нет статистической значимости |
| Синтетический мониторинг | Регулярные проверки с фиксированных проб | Быстро, стабильно, можно настроить оповещения | Проверяет только фиксированные пути, без длинного хвоста |
| Мониторинг реальных пользователей | Сбор данных реальных посетителей | Отражает реальные регионы и устройства | Медленно выявляет, нужна база трафика |
II. Синтетический мониторинг: фиксированные пробы для «раннего обнаружения»
Синтетический мониторинг (Synthetic Monitoring) — это фиксированный скрипт, который с заданных локаций и с заданной частотой открывает указанные вами ключевые страницы и записывает время отклика и доступность. Это как плановый обход: раз в минуту проверяются главная, страница списка товаров, страница заявки — если страница не открывается или слишком медленная, приходит алерт.
Его ценность в том, что он срабатывает рано и работает стабильно: среда проверок фиксирована, поэтому цифры сегодня и завтра сопоставимы и не меняются от того, что зашёл другой пользователь. Если сайт упал, истёк сертификат или отвалился какой-то API, синтетический мониторинг заметит это в течение минуты.
Но он проверяет фиксированный маршрут и не увидит такие редкие проблемы, как «в одном регионе с телефона особенно медленно открывается какая-то глубокая страница» — это уже задача мониторинга реальных пользователей. Как выбрать ключевые страницы и как всё это связать с мониторингом доступности, читайте в Мониторинг сайта и оповещения.
Пример из практики: Проверки идут из трёх точек — Франкфурт, Сингапур и Кремниевая долина, каждая раз в минуту открывает главную страницу. В один день узел во Франкфурте трижды подряд уходит в таймаут, и вам на телефон приходит оповещение. Вы смотрите логи и видите, что канал из Европы до сервера барахлит, а в Азии и США всё в порядке, — такую региональную проблему изнутри страны вы бы вообще не заметили.
| Проверка | Рекомендуемая настройка | Что измеряет | Что даёт |
|---|---|---|---|
| Частота проверок | Раз в 1 минуту | Фиксированный список URL | Быстро выявить сбой |
| Регион проверки | Выбирайте по основным регионам покупателей | Франкфурт / Сингапур / Кремниевая долина | Отражает реальный опыт в регионе |
| Страницы для мониторинга | 3–5 ключевых страниц | Главная / страница товара / страница заявки | Охватывает основной путь к конверсии |
| Какие метрики снимать | Время отклика + код состояния | TTFB, код 200 или нет | Показывает, на каком этапе тормозит |
III. Мониторинг реальных пользователей: собираем настоящие данные и отвечаем за точность
Мониторинг реальных пользователей (RUM, Real User Monitoring) — это скрипт, встроенный в страницу, который передаёт время загрузки, устройство, регион и сеть каждого реального посетителя. Он измеряет не «смоделированного пользователя», а реальный опыт ваших настоящих покупателей. Данные нужно смотреть по перцентилям, а не по среднему.
Почему нельзя смотреть среднее? Потому что его перекашивают несколько крайне быстрых или крайне медленных замеров, и оно скрывает реальный опыт большинства. Правильно смотреть на P75: выстроить время загрузки всех пользователей от меньшего к большему и взять значение на отметке 75%.
Если P75 превышает 4 секунды, значит четверть пользователей медленнее этого уровня. Для зарубежных сайтов нужно смотреть ещё и в разрезе регионов: общий P75 может быть в норме, но на Ближнем Востоке отдельно он составляет 6 секунд — проблема прячется внутри региона. Как CDN ускоряет работу в разных регионах, читайте в Глобальное ускорение CDN.
| Показатель | Порог нормы (P75) | Порог, требующий оптимизации | Значение |
|---|---|---|---|
| LCP, отрисовка самого крупного элемента | ≤ 2,5 с | Больше 4 секунд | Как быстро появляется основной контент |
| INP, отклик на взаимодействие | ≤ 200 мс | Больше 500 миллисекунд | Как быстро страница отвечает на клик |
| CLS, совокупный сдвиг макета | ≤ 0,1 | Больше 0,25 | Прыгает ли страница |
| TTFB, время до первого байта | ≤ 600 миллисекунд | Больше 1 секунды | Как быстро сервер начинает отдавать данные |
IV. Пороги оповещений и реакция по уровням
Мониторинг без оповещений — это не мониторинг: данные лежат на панели, а если их никто не смотрит, их как будто нет. Но и оповещений не должно быть слишком много, иначе через три дня их начнут игнорировать как «волки, волки». Решение — разделить их по серьёзности и реагировать с разной скоростью в зависимости от уровня.
Пороги — конкретные цифры: доступность (открывается ли страница) — 3 сбоя подряд, сразу алерт, реакция в течение 5 минут; деградация производительности (LCP P75 вырос с 2 до более чем 4 секунд) — разбираем в тот же день; долгосрочные тренды (медленное замедление каждую неделю) — смотрим раз в неделю на созвоне. Не поднимайте тревогу из-за «одного случайного сбоя» — это шум; алерт должен срабатывать только на серию сбоев.
Пример из практики: Настройте три правила алертов. Правило первое: любая ключевая страница — 3 сбоя пробы подряд, звонок — это уровень простоя. Правило второе: LCP P75 выше 4 секунд 2 дня подряд, письмо — это уровень деградации производительности. Правило третье: доля ошибок 5xx выше 1% за 10 минут, мгновенный алерт — это уровень сбоя бэкенда. Три правила соответствуют трём скоростям реакции: ничего не пропустите и не утонете в уведомлениях.
| Уровень | Условие | Сроки ответа | Способ оповещения |
|---|---|---|---|
| Критично (простой) | 3 сбоя пробы ключевой страницы подряд | Реакция в течение 5 минут | Звонок/SMS |
| Серьёзно (сбой бэкенда) | Доля ошибок 5xx выше 1% за 10 минут | В течение 30 минут | Мгновенное сообщение |
| Деградация производительности | LCP P75 выше 4 секунд 2 дня подряд | Разбираем в тот же день | Почта |
| Наблюдение за трендом | Медленное замедление каждую неделю, но без превышения порога | Смотрим на недельном созвоне | Недельный отчёт |
Пять. Чего избегать: четыре самые частые ошибки в мониторинге производительности
Первая ошибка — смотреть только на синтетику, а не на реальных пользователей. Пробы в норме, но в каком-то регионе мобильные пользователи ждут вечность, потому что проба измеряет десктоп и фиксированный путь. Вторая ошибка — смотреть только на среднее. Среднее в норме не значит, что большинство пользователей быстро: обязательно смотрите P75 и разбивайте по регионам и устройствам.
Третья ошибка — слишком много алертов, они топят настоящие. Двадцать срабатываний в день — и человек тупеет, а реальный простой остаётся незамеченным. Четвёртая ошибка — тестировать только главную. Главная часто хорошо кэшируется CDN, но реальная конверсия происходит на страницах товаров и страницах запросов — именно их медлительность стоит заказов. Критический путь нужно покрывать целиком. Ритм повседневного обслуживания можно сверить с графиком обслуживания сайта.
| Ошибка | Внешнее проявление | Реальная проблема | Как исправить |
|---|---|---|---|
| Тестируем только главную | Главная быстрая | Медленные страницы конверсии теряют заказы | Покрываем страницы товаров и запросов |
| Смотрим на среднее | Среднее 2 секунды — норма | У четверти пользователей больше 4 секунд | Смотрим P75, разбиваем по регионам |
| Шквал алертов | Двадцать срабатываний в день | Настоящие алерты игнорируются | Алерт только на серию сбоев, с уровнями |
| Тестируем только из своей страны | Локально быстро | Зарубежные покупатели ждут вдвое дольше | Пробы размещены в регионах покупателей |
FAQ: частые вопросы
Синтетический мониторинг или мониторинг реальных пользователей — что выбрать?
Почему в метриках производительности смотрят на P75, а не на среднее?
Какие пороговые значения у трёх метрик Core Web Vitals?
Из каких регионов разворачивать пробы?
Как настроить алерты, чтобы их не было слишком много и при этом ничего не пропустить?
У моего сайта мало трафика — стоит ли вообще делать мониторинг реальных пользователей?
В заключение
Суть мониторинга производительности — «измерять у нужных людей, смотреть нужные метрики, слать алерты по делу». Для одиночного зарубежного сайта достаточно: настроить синтетический мониторинг в регионах покупателей для раннего предупреждения, поставить RUM для реального опыта и настроить алерты по уровням на основе P75 и порогов Core Web Vitals. Такой набор стоит недорого, но превращает расплывчатую жалобу «у пользователей всё медленно» в конкретные цифры: какой регион, какая страница, насколько медленно.
Три шага к запуску. Первый: разместите пробы во Франкфурте, Сингапуре и Кремниевой долине и проверяйте главную страницу, страницы товаров и страницу с формой заявки каждую минуту. Второй: установите RUM на страницах и смотрите LCP, INP и CLS по P75, с разбивкой по регионам. Третий: телефонные оповещения при сбоях, письма при ухудшении производительности и еженедельный отчёт о трендах. После этих трёх шагов вы будете судить о скорости сайта не по принципу «вроде работает», а по тому, сколько секунд реально ждёт покупатель.
Запомните одну фразу: мониторинг производительности — это не проверка вашего сайта, а проверка опыта покупателя. Пробы внутри страны — всё равно что сдавать экзамен за зарубежных клиентов с закрытыми глазами.