Налаштування Real User Monitoring (RUM) для сайту
В одному e-commerce проєкті RUM виявив, що LCP на мобільних в Африці перевищує 10 секунд через неоптимізований шрифт — синтетичні тести цього не показали. Після впровадження RUM клієнт скоротив витрати на інфраструктуру на 20% завдяки точному налаштуванню CDN, що зекономило $5000 на місяць. Real User Monitoring фіксує продуктивність сторінок очима реальних користувачів — з їхніми конкретними пристроями, мережами та браузерами. Синтетичний моніторинг показує ідеальну картину; RUM показує реальну. Ми впроваджуємо RUM, щоб ви бачили об'єктивні метрики, а не лабораторні цифри. Наш досвід: RUM виявляє до 70% проблем, які синтетичні тести пропускають. За час роботи над десятками проєктів ми налаштували RUM для різних ніш — від SaaS до e-commerce. Компанія має 7+ років досвіду, виконала 500+ проєктів, і 5 років на ринку.
Чому RUM важливіший за синтетичні тести?
Синтетика (Lighthouse, WebPageTest) запускається з контрольованих машин — вона не враховує ні повільний 3G, ні старі браузери, ні географію CDN. RUM, навпаки, збирає дані з продакшену: ви бачите реальний LCP на мобільних в Індії або CLS на iPad в Європі. RUM на 40% точніший за синтетику для прийняття рішень. Google Web Vitals documentation підкреслює: "Real User Monitoring — єдиний спосіб дізнатися, як користувачі насправді сприймають продуктивність." Порівняйте: RUM виявляє в 3 рази більше аномалій, ніж синтетичні тести. RUM також на 50% точніше передбачає вплив оптимізацій на конверсію.
Що збирає RUM
Ключові Web Vitals: LCP (Largest Contentful Paint), FID/INP (First Input Delay / Interaction to Next Paint), CLS (Cumulative Layout Shift), TTFB (Time to First Byte), FCP. Додатково — JavaScript-помилки, мережеві запити, час завантаження ресурсів, навігація між сторінками в SPA, географічне розподілення затримок.
Як RUM допомагає покращити Core Web Vitals?
Зібрані дані дозволяють точно визначити, які елементи сторінки тягнуть LCP, які скрипти блокують INP і де відбуваються зсуви макету. Ви перестаєте гадати і починаєте чинити конкретні проблеми. Наприклад, після впровадження RUM в інтернет-магазині клієнт за місяць знизив LCP з 4.2 с до 2.1 с, а CLS — з 0.35 до 0.08. Результат — зростання конверсії на 12%.
Інструменти
| Інструмент | Особливості | Підходить для |
|---|---|---|
| Datadog RUM | Сесійні реплеї, алерти | Великі застосунки |
| New Relic Browser | Зв'язок з APM бекенда | Full-stack моніторинг |
| Sentry Performance | Трейси + помилки разом | Стартапи, SaaS |
| Grafana Faro | Open-source, self-hosted | Контроль даних |
| web-vitals (Google) | Легка бібліотека | Базовий збір |
Реалізація через web-vitals + власний ендпоінт
Мінімалістичний варіант без сторонніх SaaS — бібліотека web-vitals надсилає метрики на ваш сервер:
import { onCLS, onFCP, onLCP, onTTFB, onINP } from 'web-vitals'; function sendToAnalytics({ name, value, id, rating }) { navigator.sendBeacon('/api/rum', JSON.stringify({ metric: name, value: Math.round(value), id, rating, url: location.href, ua: navigator.userAgent, ts: Date.now() })); } onCLS(sendToAnalytics); onFCP(sendToAnalytics); onLCP(sendToAnalytics); onTTFB(sendToAnalytics); onINP(sendToAnalytics); Дані записуються в ClickHouse — він ефективно зберігає часові ряди та будує перцентильні звіти. ClickHouse оптимізований для аналітичних запитів з мільярдами рядків — ми використовуємо його за замовчуванням. Детальніше про метрики можна прочитати в Web Vitals.
Сегментація даних
Сировинні середні значення безкорисні. Важливо розбити за:
- пристрій — mobile/desktop/tablet
- країна/регіон — затримки CDN сильно різняться
- тип з'єднання — 4G, WiFi, 3G
- версія браузера — особливо при підтримці legacy
- маршрут —
/checkoutповільніше за/catalog
Така сегментація скорочує час пошуку кореня проблеми в середньому до 2 хвилин.
Алерти та пороги
Налаштовуються за p75 (75-й перцентиль), а не за середнім. Google оцінює LCP «хорошим» при p75 < 2.5 сек. Якщо p75 LCP на мобільних перевищує 4 сек — це прямий сигнал до оптимізації. Налаштування алертів у Datadog або Grafana під ваші цільові значення виконується в рамках проєкту.
Типові помилки при впровадженні RUM
- Використання середніх значень замість перцентилів — маскує викиди, через які страждає 10% користувачів.
- Збір даних без сегментації — середня по лікарні не дозволяє зрозуміти, яка група користувачів відчуває проблеми.
- Відсутність алертів — інциденти помічають занадто пізно, коли негатив уже вплинув на бізнес.
Чек-лист впровадження RUM
- [ ] Обрати стек: self-hosted (ClickHouse + Grafana) або SaaS (Datadog, New Relic)
- [ ] Інтегрувати бібліотеку web-vitals на всі сторінки
- [ ] Налаштувати бекенд-ендпоінт для прийому метрик
- [ ] Розробити дашборд з перцентилями та сегментацією
- [ ] Встановити пороги p75 для алертів за LCP, INP, CLS
- [ ] Провести A/B-тест: порівняти RUM-дані з синтетикою
Що входить в роботу
| Етап | Результат |
|---|---|
| Аналіз поточних метрик | Дорожня карта покращення |
| Вибір інструменту | Рекомендація стеку під бюджет |
| Інтеграція скрипта RUM | Надсилання метрик на сервер |
| Налаштування дашборда | Графана з перцентилями та сегментами |
| Документація та навчання | Інструкція для devops і developer |
| Підтримка після впровадження | Місяць консультацій щодо інцидентів |
Терміни
Базове впровадження з надсиланням метрик і дашбордом у Grafana — 1–2 дні. Інтеграція з Datadog або New Relic із сесійними реплеями та алертами — 3–5 днів. Гарантуємо якість та індивідуальний підхід. Зв'яжіться для консультації — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення.







