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







