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

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

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Настройка автоматического мониторинга Core Web Vitals сайта
Средний
от 1 дня до 3 дней

Наши компетенции:

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1419
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1287
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    983
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1245
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    983
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    998

Настройка автоматического мониторинга 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 день.

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