Lighthouse CI: обеспечение бюджетов производительности фронтенда

Updated Jul 2026

Что такое бюджет производительности?

Бюджет производительности — это набор ограничений на метрики, которым должна соответствовать страница или API. При превышении бюджета CI-пайплайн завершается с ошибкой — точно так же, как при сломанном модульном тесте. Бюджеты производительности предотвращают проблему «смерти от тысячи порезов», когда каждая отдельная регрессия приемлема, но в совокупности они ухудшают пользовательский опыт.

Концепция проста: относитесь к производительности как к корректности. Если в вашем коде ошибка, CI падает. Если ваш код слишком медленный, CI тоже должен падать.

Почему Lighthouse CI?

Lighthouse — это open-source инструмент аудита качества веб-страниц от Google. Lighthouse CI (LHCI) оборачивает Lighthouse в удобный для CI пакет, который может:

• Запускать аудиты Lighthouse для нескольких URL
• Проверять, что оценки и метрики соответствуют заданным пороговым значениям
• Сравнивать результаты с базовой линией (предыдущие сборки)
• Загружать результаты на сервер для визуализации трендов
• Запускать несколько прогонов на URL и отчитываться по медианным результатам

Конфигурация Lighthouse CI

Основная конфигурация находится в файле lighthouserc.json в корне вашего проекта:

{
  "ci": {
    "collect": {
      "url": [
        "https://staging.example.com/",
        "https://staging.example.com/products/1",
        "https://staging.example.com/checkout"
      ],
      "numberOfRuns": 3,
      "settings": {
        "chromeFlags": "--no-sandbox --headless",
        "throttling": {
          "cpuSlowdownMultiplier": 4,
          "downloadThroughputKbps": 1600,
          "uploadThroughputKbps": 768,
          "rttMs": 150
        }
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }],
        "first-contentful-paint": ["error", { "maxNumericValue": 1800 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "interactive": ["error", { "maxNumericValue": 3800 }],
        "total-blocking-time": ["warn", { "maxNumericValue": 300 }],
        "speed-index": ["warn", { "maxNumericValue": 3400 }]
      }
    },
    "upload": {
      "target": "lhci",
      "serverBaseUrl": "https://lhci.internal.example.com"
    }
  }
}

Разбор конфигурации

collect: Определяет, что измерять.

• url: Список страниц для аудита. Всегда включайте наиболее критичные пользовательские сценарии.
• numberOfRuns: Запуск каждого URL несколько раз. Lighthouse CI отчитывается по медиане, что уменьшает разброс из-за сетевого джиттера.
• settings.throttling: Моделирование реалистичных сетевых условий. По умолчанию моделируется мобильное устройство среднего уровня на подключении 4G.

assert: Определяет, что должно пройти проверку.

• Утверждения уровня "error" приводят к ошибке пайплайна.
• Утверждения уровня "warn" генерируют предупреждения, но не блокируют деплой.
• Утверждения могут быть нацелены на оценки категорий (шкала 0-1) или конкретные метрики (миллисекунды).

upload: Опционально — сохраняет результаты для исторического сравнения.

Понимание Core Web Vitals

Утверждения в вашей конфигурации Lighthouse CI должны быть привязаны к Core Web Vitals от Google, которые измеряют реальный пользовательский опыт:

Дополнительные метрики, которые стоит отслеживать:

Установка бюджетов для разных типов страниц

Не все страницы имеют одинаковые требования к производительности. Устанавливайте бюджеты для каждой страницы на основе бизнес-значимости:

{
  "ci": {
    "collect": {
      "url": [
        "https://staging.example.com/",
        "https://staging.example.com/products/1",
        "https://staging.example.com/checkout"
      ]
    },
    "assert": {
      "assertMatrix": [
        {
          "matchingUrlPattern": ".*/$",
          "assertions": {
            "largest-contentful-paint": ["error", { "maxNumericValue": 2000 }],
            "categories:performance": ["error", { "minScore": 0.95 }]
          }
        },
        {
          "matchingUrlPattern": ".*/products/.*",
          "assertions": {
            "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
            "categories:performance": ["error", { "minScore": 0.9 }]
          }
        },
        {
          "matchingUrlPattern": ".*/checkout",
          "assertions": {
            "largest-contentful-paint": ["error", { "maxNumericValue": 3000 }],
            "total-blocking-time": ["error", { "maxNumericValue": 200 }],
            "categories:performance": ["error", { "minScore": 0.85 }]
          }
        }
      ]
    }
  }
}

Бюджеты размера бандлов

Lighthouse CI покрывает производительность во время выполнения. Для бюджетов на этапе сборки добавьте проверки размера бандлов:

// bundlesize.config.json
{
  "files": [
    {
      "path": "dist/js/main.*.js",
      "maxSize": "150 kB",
      "compression": "gzip"
    },
    {
      "path": "dist/js/vendor.*.js",
      "maxSize": "200 kB",
      "compression": "gzip"
    },
    {
      "path": "dist/css/main.*.css",
      "maxSize": "30 kB",
      "compression": "gzip"
    },
    {
      "path": "dist/js/chunk-*.js",
      "maxSize": "50 kB",
      "compression": "gzip"
    }
  ]
}

Запускайте вместе с Lighthouse CI:

npx bundlesize --config bundlesize.config.json

Сервер Lighthouse CI: отслеживание трендов

Сервер LHCI обеспечивает историческое отслеживание, позволяя видеть тренды производительности во времени и выявлять постепенную деградацию, которую проверки отдельных коммитов могут пропустить:

# Install and start the LHCI server
npm install -g @lhci/cli @lhci/server
lhci server --storage.storageMethod=sql \
  --storage.sqlDialect=postgres \
  --storage.sqlConnectionUrl=postgresql://user:pass@db:5432/lhci

Панель управления сервера показывает:

• Тренды оценок во времени (по URL, по метрике)
• Сравнение между ветками (PR vs. main)
• Различия между сборками с выделением изменений
• Отмеченные регрессии с атрибуцией коммитов

Распространённые ошибки

1. Нестабильные результаты из CI-сред. CI-раннеры имеют переменную производительность. Используйте numberOfRuns: 3 (или 5) и проверяйте медиану, а не результат одного прогона.

2. Слишком жёсткие бюджеты. Начните с достижимых бюджетов и ужесточайте их со временем. Бюджет, который проваливается при каждом PR, будет отключён, что сведёт на нет весь смысл.

3. Игнорирование мобильных устройств. Настройки Lighthouse по умолчанию моделируют мобильное устройство. Не меняйте throttling на быстрый десктоп, чтобы цифры выглядели лучше. Мобильные устройства — там, где находится большинство пользователей.

4. Нетестирование аутентифицированных страниц. Lighthouse CI поддерживает puppeteerScript для потоков авторизации. Не пропускайте самые важные страницы только потому, что они требуют аутентификации.

5. Дрейф бюджетов. Пересматривайте и обновляйте бюджеты ежеквартально. То, что было приемлемо в прошлом году, может не соответствовать текущим ожиданиям пользователей или конкурентным стандартам.

Практические советы для QA-архитекторов

• Начните с трёх страниц: главная, одна страница товара/контента и самая критичная страница конверсии (оформление заказа, регистрация). Расширяйте покрытие постепенно.
• Согласуйте бюджеты с бизнес-целями. Улучшение LCP на 100 мс может измеримо повысить конверсию. Используйте опубликованные кейсы (Google, Walmart, BBC) для обоснования инвестиций в бюджеты.
• Сделайте результаты видимыми. Публикуйте оценки Lighthouse в комментариях к PR, чтобы разработчики видели влияние своих изменений до мержа.
• Сочетайте с Real User Monitoring (RUM). Lighthouse CI измеряет синтетическую производительность. Инструменты RUM (Google Analytics, Datadog RUM) измеряют реальный пользовательский опыт. Используйте оба для проверки того, что синтетические бюджеты отражают реальную производительность.