Настройка автоматического мониторинга Core Web Vitals сайта

Настройка автоматического мониторинга 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 ≤ 3.0s, TBT ≤ 500ms) с учётом разрыва между лаб и полевыми данными.

Что входит в работу?

Мы предоставляем:

• Документацию по архитектуре мониторинга и инструкции для разработчиков.
• Доступ к Grafana-дашборду и историческим данным.
• Обучение команды: как интерпретировать метрики, как реагировать на алерты.
• Поддержку в течение 2 недель после внедрения — корректировка порогов, дашбордов, алертов.

Сравнение подходов: лабораторные vs полевые данные

Полевые данные лучше отражают реальный опыт, но лабораторные тесты в 100 раз быстрее. Оптимальная стратегия — использовать оба источника в комбинации.

Сроки

Настройка CrUX API + Lighthouse + хранение в PostgreSQL + Grafana-дашборд — 3–4 рабочих дня. Интеграция в CI/CD с провалом по бюджету — 1 дополнительный день. Алерты в Telegram/Slack при ухудшении полевых метрик — ещё 0.5–1 день.

Свяжитесь с нами — обсудим детали вашего проекта и подберём оптимальную конфигурацию мониторинга. Закажите консультацию, чтобы получить оценку для вашего сайта.