Lighthouse CI: автоматизируем проверку производительности сайта

Проверить производительность веб-приложения через Lighthouse несложно. Но после очередного изменения в коде показатели могут ухудшиться, и если запускать аудит только вручную, такие изменения легко пропустить.

При этом производительность влияет не только на скорость загрузки страниц, но и на пользовательский опыт, вовлечённость и конверсию. Она имеет значение и для SEO, например Google использует Core Web Vitals в своих системах ранжирования, хотя хорошие показатели сами по себе не гарантируют высоких позиций в поиске.

При работе над одним из своих проектов я столкнулся с необходимостью регулярно проверять производительность приложения. Lighthouse в Chrome DevTools позволял проводить отдельные замеры, но мне хотелось автоматизировать этот процесс, чтобы отслеживать изменения показателей и вовремя замечать регрессии.

Для этого я решил использовать Lighthouse CI - инструмент, позволяющий запускать Lighthouse из командной строки, проверять метрики по заданным порогам и сохранять отчёты. Его можно интегрировать в GitHub Actions или практически любую другую CI/CD-систему.

В статье разберём, как работает Lighthouse CI, какие метрики он позволяет контролировать и как автоматизировать проверки производительности на примере GitHub Actions. Также покажу, как использовал этот инструмент для анализа производительности реального веб-приложения.

Что измеряет Lighthouse

Lighthouse - инструмент для автоматизированного аудита веб-страниц. Он анализирует производительность, доступность, соблюдение лучших практик и другие аспекты качества сайта.

В контексте производительности нас прежде всего интересуют метрики загрузки и отображения страницы.

Google выделяет три основные метрики Core Web Vitals:

• LCP - время до отображения крупнейшего видимого элемента страницы. Хорошим считается значение не более 2,5 секунды.

• INP - отзывчивость интерфейса при взаимодействии пользователя со страницей. Хорошее значение не более 200 мс.

• CLS - визуальная стабильность страницы. Хорошее значение не более 0,1.

При оценке Core Web Vitals по данным реальных пользователей обычно используется 75-й процентиль измерений. В отчёте можно увидеть LCP, CLS и другие показатели, например FCP (First Contentful Paint), Speed Index и TBT (Total Blocking Time).

Здесь есть нюанс, что стандартный Lighthouse-аудит не измеряет INP так, как это происходит при реальном взаимодействии пользователей. Вместо этого для оценки потенциальных проблем с отзывчивостью используется в том числе TBT.

Подробно разбирать каждую метрику не будем, это отдельная большая тема. Для понимания дальнейшей настройки достаточно знать, что Lighthouse позволяет оценивать производительность страницы и обнаруживать потенциальные проблемы.

В каких условиях запускается Lighthouse

Lighthouse может выполнять аудит в режимах Mobile и Desktop.

В мобильном режиме он эмулирует характеристики смартфона, включая размер экрана. Это важно, поскольку страница, которая быстро загружается на мощном компьютере с хорошим интернетом, может вести себя иначе на мобильном устройстве.

Помимо выбора типа устройства, инструмент позволяет моделировать ограничения сети и процессора. По умолчанию Lighthouse использует режим simulated throttling, он анализирует фактическую загрузку страницы и выполнение JavaScript, а затем рассчитывает, как изменились бы показатели при более медленном интернет-соединении и менее производительном процессоре.

Поддерживаются и другие режимы throttling, подробнее о них можно прочитать в документации по throttling.

Результаты такого тестирования следует воспринимать как лабораторные измерения, а не как данные о производительности у реальных пользователей. Они полезны для диагностики и отслеживания изменений, но не заменяют Real User Monitoring.

Что такое Lighthouse CI

Lighthouse CI (LHCI) - набор инструментов, позволяющий автоматизировать запуск Lighthouse и проверку результатов. Вместо того чтобы открывать Chrome DevTools, вводить адрес страницы и запускать аудит вручную, можно поручить это CI/CD.

В общем случае процесс выглядит следующим образом:

1. CI запускает браузер и открывает указанный URL.

2. Lighthouse собирает метрики производительности.

3. Lighthouse CI сравнивает результаты с заданными порогами.

4. Отчёты сохраняются, а проверка может завершиться ошибкой, если показатели не соответствуют требованиям.

Важная возможность Lighthouse CI - запускать несколько измерений и агрегировать результаты. Это помогает уменьшить влияние случайных колебаний, хотя полностью их не устраняет. Например, можно установить минимальный Performance Score или максимально допустимое значение LCP. При нарушении порога CI сообщит о несоответствии заданным требованиям.

Официальный репозиторий Lighthouse CI содержит документацию, примеры конфигурации и описание доступных команд.

Настраиваем Lighthouse CI в GitHub Actions

Рассмотрим настройку Lighthouse CI на упрощённом примере из моего проекта. Для наглядности оставим только основные параметры, без авторизации и дополнительных скриптов.

Наша задача запускать мобильный аудит опубликованного приложения, проверять LCP и Performance Score, а затем сохранять отчёты в GitHub Actions. Для этого понадобятся конфигурационный файл Lighthouse CI и небольшой workflow.

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

В корне проекта создадим файл lighthouserc.json:

{
  "ci": {
    "collect": {
      "url": ["https://example.com/"],
      "numberOfRuns": 3,
      "settings": {
        "formFactor": "mobile"
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": [
          "warn",
          { "minScore": 0.8, "aggregationMethod": "median" }
        ],
        "largest-contentful-paint": [
          "error",
          { "maxNumericValue": 4000, "aggregationMethod": "median" }
        ]
      }
    },
    "upload": {
      "target": "filesystem",
      "outputDir": "./lhci-results"
    }
  }
}

Разберём основные параметры.

collect.url определяет адрес страницы, которую нужно проверить. Можно указать несколько URL.

numberOfRuns задаёт количество прогонов. В нашем примере Lighthouse выполнит три измерения.

assert описывает пороговые значения. Для Performance Score мы указали минимум 80 баллов, а для LCP максимум 4000 мс. При warn Lighthouse CI сообщает о нарушении порога, но не завершает проверку с ошибкой, а при error приводит к падению CI.

aggregationMethod: "median" указывает, что при проверке используется медианное значение результатов.

upload.target: "filesystem" позволяет сохранить отчёты локально, без публикации на внешнем сервере Lighthouse CI.

Приведённые пороги это только пример конфигурации, а не универсальные рекомендации. Для конкретного приложения их нужно выбирать с учётом измерений и целей проекта.

В примере используются только две проверки: Performance Score и LCP. Lighthouse CI позволяет задавать пороги и для других метрик, например FCP, TBT и CLS, а также контролировать оценки доступности и соблюдения лучших практик.

Полный перечень доступных проверок и параметры их настройки приведены в официальной документации Lighthouse CI - Assertions.

Создаём GitHub Actions workflow

Добавим файл .github/workflows/lighthouse.yml:

name: Lighthouse

on:
  workflow_dispatch:

jobs:
  lighthouse:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Run Lighthouse CI
        run: |
          npm install --global @lhci/cli@0.16.0
          lhci autorun --config=lighthouserc.json

      - name: Save reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: lighthouse-report
          path: lhci-results/
          if-no-files-found: ignore

Это упрощённый пример для GitHub-hosted runner с доступным Chrome. В собственном окружении может потребоваться отдельно установить браузер и указать путь к нему. Здесь используется workflow_dispatch, поэтому проверку можно запустить вручную через вкладку Actions в GitHub.

После запуска Lighthouse CI выполнит аудит, проверит заданные пороги и сохранит отчёты в артефактах workflow.

Как сделать запуск автоматическим

Ручной запуск удобен на этапе настройки и диагностики. Но Lighthouse CI можно запускать и автоматически. Например, для ежедневной проверки достаточно изменить триггер:

on:
  workflow_dispatch:
  schedule:
    - cron: "0 6 * * *"

Теперь workflow можно запускать вручную, а GitHub Actions также будет пытаться выполнять его ежедневно по расписанию.

Можно запускать при создании или обновлении Pull Request:

on:
  pull_request:

Однако здесь есть важный нюанс. Если Lighthouse проверяет Production URL, то запуск при создании PR не означает, что он измеряет изменения этого PR. Для проверки новой версии приложения нужно предварительно развернуть её, например на Preview Deployment, и передать соответствующий адрес Lighthouse CI.

Таким образом, Lighthouse CI не привязан к конкретному способу запуска. Можно проверять опубликованное приложение, Preview Deployment или локально поднятый сервер.

Практический пример: проверка производительности веб-приложения

В своём проекте я использовал Lighthouse CI для проверки производительности главной страницы веб-приложения, развёрнутого на Vercel.

Главная страница доступна только после авторизации. Для проверки таких страниц Lighthouse CI позволяет предварительно подготовить сессию браузера, например с помощью Puppeteer. После этого аудит выполняется так же, как для публичной страницы.

Для главной страницы я настроил три независимых мобильных прогона. Результаты собираются и отображаются в GitHub Actions, а для оценки показателей используются медианные значения. В текущей реализации проверки запускаются вручную отдельным workflow и не блокируют основной CI.

Для главной страницы установлены рекомендательные пороги: Performance Score не ниже 70 баллов, LCP не более 4 секунд, TBT не более 600 мс и CLS не более 0,1.

Что показали проверки

Одной из проблем, на которую я обратил внимание при анализе производительности главной страницы, оказался высокий LCP.

Как видно из отчёта, LCP составил 12 327 мс. Это означает, что крупнейший видимый элемент страницы отображался более чем через 12 секунд после начала загрузки, значительно превышая рекомендуемые 2,5 секунды.

Чтобы разобраться в причинах, я исследовал загрузку фонового изображения, шрифтов и JavaScript-модулей, которые могли задерживать отображение интерфейса.

В процессе оптимизации внёс несколько изменений. Изображения карточек были уменьшены: исходные файлы общим размером около 1,34 МБ заменены оптимизированными JPEG общим размером около 0,5 МБ. Также я изменил порядок загрузки изображений на главной странице, добавил предварительную загрузку фонового изображения при повторном посещении и пересмотрел загрузку шрифтов и JavaScript-модулей.

После этих изменений я повторно запустил Lighthouse CI, чтобы оценить результат.

Результаты повторных проверок

В повторном отчёте Lighthouse CI значение LCP снизилось с 12 327 до 3 022 мс, примерно на 75%. Теперь показатель укладывается в установленный для проекта порог 4 секунды, хотя всё ещё превышает рекомендуемые Google 2,5 секунды.

Lighthouse CI позволяет организовать повторяемые проверки и сделать показатели частью инженерного процесса. Можно анализировать конкретные метрики и отслеживать, как они меняются после обновлений приложения.

Что нужно учитывать при автоматизированных проверках

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

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

И Lighthouse CI не заменяет данные реальных пользователей. CI проверки позволяют воспроизводить определённые условия и диагностировать проблемы, но не показывают всё разнообразие устройств, сетей и пользовательских сценариев. Для оценки реального пользовательского опыта стоит дополнительно использовать Real User Monitoring.

Заключение

Lighthouse полезен не только как инструмент для разового аудита страницы в Chrome DevTools.

С помощью Lighthouse CI проверки производительности можно встроить в процесс разработки: запускать их по расписанию, после деплоя или при обновлении Pull Request и сохранять отчёты. Для этого не требуется сложная инфраструктура. Достаточно небольшого конфигурационного файла и workflow в GitHub Actions.

При этом Lighthouse CI помогает вовремя замечать проблемы, оценивать изменения и принимать технические решения на основе измерений.

Источники и документация

1. Google Chrome - Lighthouse overview - назначение Lighthouse и возможности аудита.

2. web.dev - Web Vitals - Core Web Vitals и рекомендуемые пороги.

3. Lighthouse - Throttling - моделирование сетевых и вычислительных ограничений.

4. Lighthouse CI - GitHub - исходный код, конфигурация и интеграция с CI/CD.

5. GitHub Docs - Workflow syntax - настройка GitHub Actions.

6. GitHub Docs - Workflow artifacts - сохранение результатов проверок.