Налаштування автоматичного запуску Lighthouse CI при кожному деплої

Ви пушите фічу, все зелене, через тиждень LCP на мобільних підскакує з 2.5с до 6с. Регресія пішла в прод — знайомо? Ми бачили такі випадки десятки разів. Рішення — автоматичний запуск Lighthouse CI при кожному деплої. Ви ловите падіння метрик на етапі CI, а не в проді, і точно знаєте, який комміт ініціював деградацію. Наш досвід — більше 50 успішних інтеграцій.

Автоматизація виявляє регресії в 3 рази швидше ручних перевірок та виключає людський фактор. Замість щотижневого аудиту — перевірка кожної зміни з блокуванням збірки при виході за пороги. Час виявлення проблеми скорочується з 2 днів до 2 годин. Lighthouse CI documentation рекомендує такий підхід для підтримки Core Web Vitals.

Як налаштувати автоматичний запуск Lighthouse при деплої?

Мінімальний стек: CI/CD (GitHub Actions, GitLab CI) + Lighthouse CI CLI + місце зберігання результатів. Ми використовуємо self-hosted LHCI сервер для історії та порівняння з baseline. Конфігурація описується в .lighthouserc.js.

module.exports = { ci: { collect: { url: [ 'http://localhost:3000/', 'http://localhost:3000/about', 'http://localhost:3000/catalog', 'http://localhost:3000/product/test-product', ], numberOfRuns: 3, startServerCommand: 'npm run start:ci', startServerReadyPattern: 'ready on', startServerReadyTimeout: 30000, }, assert: { assertions: { 'categories:performance': ['warn', { minScore: 0.8 }], 'categories:accessibility': ['error', { minScore: 0.9 }], 'categories:best-practices': ['warn', { minScore: 0.85 }], 'categories:seo': ['error', { minScore: 0.9 }], 'first-contentful-paint': ['warn', { maxNumericValue: 2000 }], 'largest-contentful-paint': ['error', { maxNumericValue: 2500 }], 'total-blocking-time': ['warn', { maxNumericValue: 300 }], 'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }], 'speed-index': ['warn', { maxNumericValue: 3400 }], }, }, upload: { target: 'temporary-public-storage', }, }, }; 

GitHub Actions workflow:

name: Lighthouse CI on: push: branches: [main, master] pull_request: branches: [main, master] jobs: lighthouse: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 cache: npm - name: Install dependencies run: npm ci - name: Build run: npm run build - name: Run Lighthouse CI run: | npm install -g @lhci/[email protected] lhci autorun env: LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }} LHCI_TOKEN: ${{ secrets.LHCI_TOKEN }} 

Що дає автоматизація Lighthouse?

Автоматизація перетворює Lighthouse з разової перевірки на процес. Таблиця порівняння:

Self-hosted LHCI сервер дає історію та порівняння з baseline. Інвестиції в налаштування варіюються від 20 000 до 40 000 ₽ залежно від складності.

Чому варто обрати self-hosted LHCI сервер?

Self-hosted сервер зберігає звіти у вашій інфраструктурі, дозволяє порівнювати PR з головною гілкою та будувати тренди. Жодної залежності від зовнішніх сервісів — всі дані під контролем. Додатково, ви можете налаштувати сповіщення при падінні Core Web Vitals нижче порогу.

Які метрики критично важливі для e-commerce?

Для інтернет-магазину ключові метрики — Largest Contentful Paint (LCP) має бути не більше 2.5 с, Cumulative Layout Shift (CLS) не більше 0.1, Total Blocking Time (TBT) не більше 200 мс. Автоматичний Lighthouse CI перевіряє їх кожний деплой, гарантуючи, що зміни не погіршать користувацький досвід. Наприклад, після додавання нового банеру LCP виросло на 0.5 с — CI заблокував збірку, і розробник виправив до прода. Завдяки такому моніторингу продуктивності в 95% випадків регресія виявляється протягом 10 хвилин.

Процес роботи над налаштуванням

1. Аналітика — визначаємо ключові сторінки та пороги метрик. Наприклад, для маркетплейсу це карточка товару, каталог і головна.
2. Проектування — обираємо стек (GitHub Actions, GitLab CI, self-hosted) та архітектуру зберігання.
3. Реалізація — налаштовуємо .lighthouserc.js, workflow CI, додаємо сповіщення в Slack або Telegram.
4. Тестування — прогоняємо на PR, коригуємо пороги, переконуємось, що хибні спрацювання виключені.
5. Документація та навчання — передаємо конфіги, пишемо інструкцію для команди та налаштовуємо дашборд.

Сповіщення про деградацію

LHCI не відправляє Slack-сповіщення вбудовано, але ми додаємо крок в CI:

- name: Check Lighthouse results and notify if: always() run: | RESULT=$(cat .lighthouseci/manifest.json | jq -r '.[0].summary.performance') SCORE=$(echo "$RESULT * 100" | bc | cut -d. -f1) if [ "$SCORE" -lt "80" ]; then curl -X POST ${{ secrets.SLACK_WEBHOOK }} \ -H 'Content-Type: application/json' \ -d "{\"text\": \":warning: Lighthouse Performance score dropped to ${SCORE}/100 on \`${{ github.ref_name }}\"",\"attachments\": [{\"color\": \"danger\",\"text\": \"Commit: ${{ github.sha }}\ Actor: ${{ github.actor }}\"}]}" fi 

Типові проблеми при налаштуванні

Перевірка конкретних аудитів

Окрім категорійних скорів, ми налаштовуємо перевірки конкретних аудитів, наприклад, render-blocking-resources, unsized-images, prioritize-lcp-image. Це дає більш точний контроль, ніж загальний скор. Також можна налаштувати перевірку окремих аудитів у конфігурації.

Строки та що входить

Базова налаштування в GitHub Actions з тимчасовим сховищем — 2–4 години. З self-hosted сервером та сповіщеннями — 1–2 робочих дні. Повна система з історією, порівнянням та інтеграцією в рев'ю — 3–5 робочих днів.

• Конфігурація Lighthouse CI для вашого репозиторію.
• Налаштування self-hosted LHCI серверу (якщо потрібна історія).
• Інтеграція з Slack/Telegram для сповіщень.
• Пороги для всіх метрик Core Web Vitals.
• Документація та навчання команди.

Економія бюджету на підтримку може становити до 15 000 ₽ на місяць. Наша команда займається Web Performance більше 5 років. Ми виконали 50+ інтеграцій Lighthouse CI для проектів різних масштабів — від лендінгів до маркетплейсів. Гарантуємо прозорість: ви отримуєте доступ до конфігів та історії змін.

Замовте налаштування Lighthouse CI — це займе від 2 годин. Отримайте консультацію з архітектури та економію часу до 3 годин на тиждень.