Налаштування автоматичного моніторингу Core Web Vitals сайту
Ми спеціалізуємося на налаштуванні безперервного моніторингу Core Web Vitals — метрик LCP, INP та CLS, які входять до сигналів ранжування Google. Але важливіше SEO-аспекту те, що вони прямо корелюють з конверсією: кожні 100ms затримки LCP знижують конверсію приблизно на 1% Google Web Vitals. Для магазину з обігом $1M/міс це $10k втрат. Аналогічно, високий CLS збільшує відсоток відмов на 15-20%. Моніторинг потрібен постійний, а не разовий аудит. Нижче — наш підхід до побудови системи, яка включає як лабораторні, так і польові дані, автоматичні перевірки в CI/CD та візуалізацію трендів.
Два рівні даних: лабораторні vs польові
Лабораторні — Lighthouse, симульований користувач, стабільне середовище. Запускаються після кожного деплою, дають миттєвий зворотній зв'язок. Польові — CrUX (Chrome UX Report), реальні дані Chrome-користувачів за 28 днів. Доступні через PSI API та CrUX API. Відображають реальний досвід — враховують повільні пристрої, погані мережі, кешовані/некешовані завантаження.
Розрив між ними — норма. Лабораторний LCP = 1.8s, польовий = 3.1s. Це не означає, що вимірювання невірні: реальні користувачі прийшли з повільних з'єднань на дешевих телефонах. Польові дані точніше відображають реальний досвід — різниця може досягати 2-3 разів, тому покладатися лише на лабораторні тести ризиковано.
Чому польові дані важливіші за лабораторні?
Лабораторні тести передбачувані, але вони не враховують варіативність реальних пристроїв та мереж. Польові дані CrUX надають статистику по p75 — 75% користувачів відчувають кращий досвід. Це єдине джерело, яке враховує всіх користувачів, включаючи тих, хто заходить з повільних 3G-з'єднань. Наші інженери налаштовують збір польових даних як основу для алертів та трендів, а лабораторні тести використовуємо для швидкого зворотного зв'язку при розробці.
CrUX API — польові дані без посередників
Google надає CrUX API безкоштовно з ключем Cloud Console. Приклад отримання даних на Python:
import requests
CRUX_API_URL = 'https://chromeuxreport.googleapis.com/v1/records:queryRecord'
def fetch_crux(url: str, api_key: str, form_factor: str = 'PHONE') -> dict:
payload = {
'url': url,
'formFactor': form_factor, # PHONE, DESKTOP, TABLET
'metrics': [
'largest_contentful_paint',
'cumulative_layout_shift',
'interaction_to_next_paint',
'first_contentful_paint',
'experimental_time_to_first_byte',
],
}
resp = requests.post(
f'{CRUX_API_URL}?key={api_key}',
json=payload,
timeout=30,
)
if resp.status_code == 404:
return {'error': 'insufficient_data', 'url': url}
resp.raise_for_status()
return resp.json()
def parse_crux_metrics(crux_data: dict) -> dict:
record = crux_data.get('record', {})
metrics = record.get('metrics', {})
def extract(key):
m = metrics.get(key, {})
histo = m.get('histogram', [])
p75 = m.get('percentiles', {}).get('p75')
return {'p75': p75, 'histogram': histo}
return {
'lcp': extract('largest_contentful_paint'),
'cls': extract('cumulative_layout_shift'),
'inp': extract('interaction_to_next_paint'),
'fcp': extract('first_contentful_paint'),
'ttfb': extract('experimental_time_to_first_byte'),
}
Lighthouse через Node.js для лабораторних даних
Для автоматизації після деплою використовуємо Node.js CLI або programmatic API:
// monitor.js
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');
const fs = require('fs');
async function runLighthouse(url, options = {}) {
const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });
const opts = {
port: chrome.port,
onlyCategories: ['performance'],
formFactor: options.formFactor || 'mobile',
throttlingMethod: 'simulate',
...options,
};
const runnerResult = await lighthouse(url, opts);
await chrome.kill();
const { lhr } = runnerResult;
const audits = lhr.audits;
return {
score: lhr.categories.performance.score,
lcp: audits['largest-contentful-paint'].numericValue,
fcp: audits['first-contentful-paint'].numericValue,
tbt: audits['total-blocking-time'].numericValue,
cls: audits['cumulative-layout-shift'].numericValue,
tti: audits['interactive'].numericValue,
speed_index: audits['speed-index'].numericValue,
server_response_time: audits['server-response-time'].numericValue,
};
}
// Запуск для кількох сторінок
const pages = [
'https://example.com/',
'https://example.com/catalog/',
'https://example.com/product/1/',
];
(async () => {
const results = [];
for (const url of pages) {
const mobile = await runLighthouse(url, { formFactor: 'mobile' });
const desktop = await runLighthouse(url, { formFactor: 'desktop' });
results.push({ url, mobile, desktop, timestamp: new Date().toISOString() });
}
fs.writeFileSync('cwv_results.json', JSON.stringify(results, null, 2));
})();
Як інтегрувати перевірки в CI/CD?
Після деплою — автоматична перевірка з провалом pipeline при деградації:
# .github/workflows/cwv-check.yml
name: Core Web Vitals Check
on:
deployment_status:
jobs:
cwv:
if: github.event.deployment_status.state == 'success'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install lighthouse chrome-launcher
- name: Run CWV check
run: |
node scripts/cwv-check.js \
--url ${{ github.event.deployment_status.environment_url }} \
--budget '{"performance": 0.7, "lcp": 4000, "cls": 0.1, "tbt": 600}'
env:
FAIL_ON_REGRESSION: 'true'
// scripts/cwv-check.js
const args = require('minimist')(process.argv.slice(2));
const budget = JSON.parse(args.budget);
runLighthouse(args.url).then(result => {
const failures = [];
if (result.score < budget.performance)
failures.push(`Performance score ${result.score} < ${budget.performance}`);
if (result.lcp > budget.lcp)
failures.push(`LCP ${result.lcp}ms > ${budget.lcp}ms`);
if (result.cls > budget.cls)
failures.push(`CLS ${result.cls} > ${budget.cls}`);
if (result.tbt > budget.tbt)
failures.push(`TBT ${result.tbt}ms > ${budget.tbt}`);
if (failures.length > 0) {
console.error('CWV check FAILED:\n' + failures.join('\n'));
if (process.env.FAIL_ON_REGRESSION === 'true') process.exit(1);
} else {
console.log('CWV check passed.');
}
});
Зберігання та тренди
Усі результати складаються в PostgreSQL з прив'язкою до деплою:
CREATE TABLE cwv_snapshots (
id SERIAL PRIMARY KEY,
url TEXT NOT NULL,
source VARCHAR(20) NOT NULL, -- 'lighthouse' or 'crux'
form_factor VARCHAR(10) NOT NULL, -- 'mobile', 'desktop'
measured_at TIMESTAMP NOT NULL,
-- Core Web Vitals
lcp_ms INTEGER,
cls NUMERIC(6,4),
inp_ms INTEGER,
fcp_ms INTEGER,
ttfb_ms INTEGER,
-- Lighthouse-only
performance_score NUMERIC(4,2),
tbt_ms INTEGER,
tti_ms INTEGER,
speed_index_ms INTEGER,
-- Метадані
deploy_id TEXT,
commit_sha TEXT
);
Зберігати commit SHA разом з виміром — дозволяє точно визначити, який деплой зламав метрики.
Візуалізація трендів у Grafana
Ми будуємо Grafana-дашборд на основі PostgreSQL з відображенням тижневого тренду по кожній метриці та маркерами деплоїв. Замовник отримує доступ до дашборду і може самостійно відстежувати динаміку.
Порогові значення Core Web Vitals
Орієнтири Google (p75 польових даних):
| Метрика | Добре | Потребує покращень | Погано |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| INP | ≤ 200ms | 200–500ms | > 500ms |
Для лабораторного моніторингу використовуємо більш жорсткі пороги (LCP ≤ 3.0s, TBT ≤ 500ms) з урахуванням розриву між лаб і польовими даними.
Детальніше про вибір порогів для CI/CD
Для автоматичного провалу пайплайну ми рекомендуємо встановлювати пороги на 10-20% вище польових, щоб уникнути хибних спрацювань через різницю між лабораторними та польовими даними. Наприклад, якщо польовий LCP p75 = 3.0s, в CI/CD можна поставити поріг 3.5s.Що входить у роботу?
Ми надаємо:
- Документацію з архітектури моніторингу та інструкції для розробників.
- Доступ до Grafana-дашборду та історичних даних.
- Навчання команди: як інтерпретувати метрики, як реагувати на алерти.
- Підтримку протягом 2 тижнів після впровадження — коригування порогів, дашбордів, алертів.
Порівняння підходів: лабораторні vs польові дані
| Параметр | Лабораторні (Lighthouse) | Польові (CrUX) |
|---|---|---|
| Швидкість отримання | Секунди | До 28 днів |
| Врахування реальних умов | Ні | Так |
| Повторюваність | Висока | Середня |
| Використання | CI/CD, швидкий зворотній зв'язок | Тренди, алерти для продакшену |
Польові дані краще відображають реальний досвід, але лабораторні тести в 100 разів швидші. Оптимальна стратегія — використовувати обидва джерела в комбінації.
Строки
Налаштування CrUX API + Lighthouse + зберігання в PostgreSQL + Grafana-дашборд — 3–4 робочих дні. Інтеграція в CI/CD з провалом по бюджету — 1 додатковий день. Алерти в Telegram/Slack при погіршенні польових метрик — ще 0.5–1 день.
Зв'яжіться з нами — обговоримо деталі вашого проекту та підберемо оптимальну конфігурацію моніторингу. Замовте консультацію, щоб отримати оцінку для вашого сайту.