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