Настройка автоматического мониторинга 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' или '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 день.
Свяжитесь с нами — обсудим детали вашего проекта и подберём оптимальную конфигурацию мониторинга. Закажите консультацию, чтобы получить оценку для вашего сайта.