Чому 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 та помилки приходять від живих користувачів — з їхньою мережею, пристроями, розширеннями.
Синтетичні перевірки йдуть із фіксованих точок і дають еталонну базу: деградація за ними видна, а поведінка людей на слабкому каналі — ні.
Розмітка метрик тут важливіша за саме джерело. Якщо одним і тим самим іменам з агента й із синтетики не задати спільні виміри, ряди не сходяться і порівняння розпадається на два незв'язані графіки.
Гібридний моніторинг зводить потоки в спільну панель, а серверні логи закривають те, чого браузер не бачить: час відповіді бекенду, коди помилок, черги запитів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Агент у браузері | Живий трафік, важливо бачити Core Web Vitals на реальних пристроях і в реальних мережах | Блокувальники та відмови від згоди вирізають частину вибірки; без серверного контексту причина збою не видна |
| Синтетичні перевірки | Критичні сценарії — вхід, оплата, пошук: потрібен відтворюваний еталон і контроль доступності | Не відображають профіль реальних пристроїв; перевіряють лише заздалегідь описані кроки |
| Гібридний моніторинг | Зрілий продукт: потрібно пов'язати скаргу користувача з деградацією бекенду | Потребує єдиної розмітки метрик і дисципліни в іменах; складніший у підтримці |
| Серверні логи | Діагностика причин: вузькі місця бекенду, помилки інтеграцій | Нічого не кажуть про те, що відбувалося в браузері до запиту |
На практиці режими не конкурують: вибираємо провідний під задачу і додаємо другий там, де сліпа зона заважає розбору інциденту. Зводимо все в Grafana — одна панель замість трьох вкладок, і оповіщення спрацьовує на деградацію, а не на випадковий викид.
Етапи впровадження: від інвентаризації сторінок до регламентів
Впровадження моніторингу реальних користувачів (RUM) починається не з панелі з графіками, а з інвентаризації: які шаблони сторінок несуть навантаження, які сценарії ведуть до мети і де Core Web Vitals просідають на реальних пристроях.
Далі вибудовуємо роботи так, щоб до першого оповіщення вже були готові пороги, маршрути і регламент реакції.
-
Інвентаризація сторінок і сценаріїв. Складаємо список шаблонів, точок входу і критичних переходів, відзначаємо, де метрики знімаються штатною розміткою, а де потрібні окремі вимірювання швидкості ключових блоків.
-
Схема збору. Визначаємо зрізи для розбору: тип пристрою, регіон, канал зв'язку, версія клієнтської частини. Так деградація в усіх користувачів відокремлюється від проблеми одного сегмента.
-
Пороги оповіщень. Рахуємо за перцентилями, а не за середнім — середнє приховує повільні сесії. Для кожного показника фіксуємо вікно спостереження, щоб короткий сплеск не піднімав на ноги всю команду.
-
Дедуплікація оповіщень. Сигнали однієї аварії згортаємо за шаблоном сторінки, типом збою і часом: інакше одна помилка в розмітці дає сотні тривог, і моніторинг перестають читати.
-
Маршрутизація. Критичні сигнали йдуть у чергову зміну, метрики якості — у плановий розбір, інфраструктурні — профільним інженерам.
-
Перевірка на реальному трафіку. Спостерігаємо перші тижні, звіряємо показання із зовнішніми джерелами, проганяємо навчальні тривоги і знімаємо хибні спрацювання.
-
Передача. Віддаємо схему збору, налаштовані пороги, маршрути та інструкції з розбору інцидентів — моніторинг живе далі без нас.
Конфігурації збору, дашборди та регламенти реагування
Кожне правило збору і кожен алерт залишаються у вас як робочий артефакт, а не усна домовленість. Комплект нижче ми передаємо після завершення налаштування 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 насамперед, а не «по всьому сайту».
- Цільові пороги за метриками: швидкість відображення основного контенту, відзивчивість на натискання, візуальна стабільність. Достатньо сформулювати бізнес-вимогу («укладається частка сесій не нижче заданої»), точні значення підберемо разом.
- Що вже налаштовано: синтетичні перевірки, лабораторні вимірювання, лічильники аналітики — щоб не дублювати збір і не сперечатися з наявними звітами.
- Доступи: читання до акаунта моніторингу й аналітики, тестовий контур для перевірки розмітки, контакт відповідального за фронтенд.
- Канали оповіщень і чергування: куди надходить сигнал про просідання (месенджер, пошта, система чергувань) і хто на нього реагує в робочий і неробочий час.
- Зрізи, які важливі для розбору: пристрої, браузери, регіони, тип з'єднання — від них залежить, де шукати причину деградації.
- Календар випусків і великих змін на фронтенді — щоб відрізняти регрес релізу від фонового шуму мережі.
Якщо чогось зі списку немає — приходьте з тим, що є: відсутні ввідні зберемо разом, а перші вимірювання поставимо на тестовому контурі. Опишіть задачу — повернемося з оцінкою впровадження і планом робіт, з відповідальними і строками етапів.
