Налаштування автоматичного моніторингу 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' 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 день.

Зв'яжіться з нами — обговоримо деталі вашого проекту та підберемо оптимальну конфігурацію моніторингу. Замовте консультацію, щоб отримати оцінку для вашого сайту.