RUM-моніторинг продуктивності: Core Web Vitals, Grafana, алерти
Відвідувачі йдуть, якщо сайт довго завантажується. Google штрафує за погані Core Web Vitals. Як заявляє Google Search Central, ці метрики — прямий фактор ранжування. Ми налаштовуємо RUM-моніторинг, щоб ви бачили реальні метрики з реальних користувачів, а не синтетику. За 7+ років ми провели оптимізацію для 40+ проєктів — кожного разу LCP знижувався щонайменше на 30%, INP покращувався на 25%, CLS стабілізувався до зеленої зони. Один із кейсів — інтернет-магазин електроніки з LCP 4.5 сек та CLS 0.3. Після впровадження моніторингу та подальшої оптимізації (ліниве завантаження, попереднє завантаження критичних ресурсів, усунення layout shift) LCP впав до 1.8 сек, CLS до 0.05. Трафік з Google виріс на 25% за місяць. Економія на залученні трафіку: ROI від впровадження RUM перевищує 5x за рахунок скорочення втрат на повільних сторінках. Зниження рекламного бюджету до 30% — реальний результат для наших клієнтів.
Чому Core Web Vitals критичні для SEO?
Це три метрики, що безпосередньо впливають на ранжування: LCP (Largest Contentful Paint — швидкість відображення основного контенту), INP (Interaction to Next Paint — чуйність на дії користувача) та CLS (Cumulative Layout Shift — стабільність верстки). Якщо хоча б одна в червоній зоні, сайт втрачає позиції. За даними наших проєктів, покращення Core Web Vitals корелює з ростом трафіку на 20–40% та зниженням відмов на 15% у середньому. Помилки на сайті коштують бізнесу до 30% трафіку — моніторинг допомагає їх виявити.
Проблема в тому, що браузери та пристрої різні. На MacBook з гігабітом метрики чудові, а на мобільному 3G в Індії — жахливі. Синтетика не покаже реальної картини. Тільки RUM (Real User Monitoring) дає правду.
Як налаштувати RUM-моніторинг за годину?
Встановіть бібліотеку web-vitals та надсилайте метрики на свій ендпоінт. Приклад коду:
<script type="module"> import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js'; function sendToAnalytics({ name, value, rating, navigationType }) { navigator.sendBeacon('/api/vitals', JSON.stringify({ metric: name, value: Math.round(name === 'CLS' ? value * 1000 : value), rating, // 'good' | 'needs-improvement' | 'poor' url: location.pathname, connection: navigator.connection?.effectiveType ?? 'unknown', deviceMemory: navigator.deviceMemory ?? 0, ts: Date.now(), })); } onLCP(sendToAnalytics); onsINP(sendToAnalytics); onCLS(sendToAnalytics); onFCP(sendToAnalytics); onTTFB(sendToAnalytics); </script> Це база. Але ще потрібно: endpoint для прийому, зберігання в ClickHouse, дашборди в Grafana, алерти при деградації. Все це ми робимо під ключ.
Деталі зберігання метрик
ClickHouse відмінно підходить для timeseries-даних. Ми використовуємо двигун MergeTree з партиціонуванням по днях. Приклад схеми: ```sql CREATE TABLE vitals ( metric String, value Float32, rating String, url String, connection String, deviceMemory UInt8, ts DateTime ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(ts) ORDER BY (metric, ts); ``` Індекси по метриці та часу дозволяють швидко будувати p95 та p75.Які проблеми вирішує моніторинг?
- Повільний сервер — TTFB > 800ms. RUM покаже, де сервер гальмує.
- Неоптимізовані зображення — головна причина поганого LCP.
- Сторонні скрипти — аналітика, карти, віджети блокують рендеринг.
- Витоки при ререндері — зайві оновлення DOM псують INP.
- Зсуви макету — зображення без розмірів, динамічне завантаження контенту.
Порівняння методів моніторингу
| Характеристика | RUM (Real User) | Синтетичний (Lighthouse) |
|---|---|---|
| Дані | Від реальних користувачів | Імітація в контрольованому середовищі |
| Охоплення | Всі пристрої/з'єднання | Обмежений налаштуваннями |
| Актуальність | Поточний стан у продакшені | Моментальний зріз |
| Деталізація | За URL, сегментами, часом | Одна метрика за прогін |
| Мета | Моніторинг та алерти | Дебаг та аудит |
RUM у 5 разів точніше відображає фактичний досвід користувачів, тому алерти на основі RUM дозволяють швидше реагувати на проблеми.
Що входить в роботу?
- Документація по архітектурі моніторингу та інструкція для команди.
- Доступи до дашбордів та системи алертів.
- Навчання співробітників роботі з метриками та реакціям на інциденти.
- Підтримка протягом місяця після впровадження: коригування порогів, додавання сегментів.
Процес впровадження моніторингу під ключ
- Аудит поточної архітектури та метрик.
- Встановлення RUM-скрипту з сегментацією по сторінках.
- Розробка API-ендпоінту збору в ClickHouse (або іншу БД).
- Створення дашбордів у Grafana з p75, p95, сегментацією по пристрою/з'єднанню.
- Налаштування алертів (Grafana Alerting) при виході метрик за пороги.
- Інтеграція сповіщень (Telegram, Slack, PagerDuty).
- Документація та навчання команди.
- Підтримка протягом місяця.
Порогові значення метрик:
| Метрика | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2500ms | 2500–4000ms | > 4000ms |
| INP | ≤ 200ms | 200–500ms | > 500ms |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| FCP | ≤ 1800ms | 1800–3000ms | > 3000ms |
| TTFB | ≤ 800ms | 800–1800ms | > 1800ms |
Типові помилки та як їх уникнути
Багато хто фокусується тільки на LCP, забуваючи про CLS та INP. Інша часта помилка — відсутність сегментації по сторінках: дані змішуються, і незрозуміло, де проблема. Налаштовуйте алерти на p75 та p95, а не тільки на середні значення — так ви швидше помітите деградацію.
Зв'яжіться з нами для безкоштовного аудиту — ми покажемо, які метрики зіпсовані та як їх виправити. Замовте впровадження RUM-моніторингу з гарантією покращення Core Web Vitals. Отримайте консультацію з оптимізації — розберемо ваш поточний стек та запропонуємо план дій.