Мониторинг производительности с помощью Lighthouse CI

Как добавить Lighthouse в систему непрерывной интеграции, например GitHub Actions.

Кэти Хемпениус
Katie Hempenius

Lighthouse CI — это набор инструментов для использования Lighthouse во время непрерывной интеграции. Lighthouse CI можно включить в рабочие процессы разработчиков разными способами. В этом руководстве рассматриваются следующие темы:

  • Использование интерфейса командной строки Lighthouse CI.
  • Настройка вашего провайдера CI для запуска Lighthouse CI.
  • Настройка действия GitHub и проверка статуса для Lighthouse CI. Это автоматически отобразит результаты Lighthouse по запросам на извлечение GitHub.
  • Создание панели мониторинга производительности и хранилища данных для отчетов Lighthouse.

Обзор

Lighthouse CI — это набор бесплатных инструментов, упрощающих использование Lighthouse для мониторинга производительности. Один отчет Lighthouse предоставляет моментальный снимок производительности веб-страницы на момент ее запуска; Lighthouse CI показывает, как эти результаты менялись с течением времени. Это можно использовать для определения влияния конкретных изменений кода или обеспечения соблюдения пороговых значений производительности в ходе процессов непрерывной интеграции. Хотя мониторинг производительности является наиболее распространенным вариантом использования Lighthouse CI, его можно использовать для мониторинга других аспектов отчета Lighthouse — например, SEO или доступности.

Основная функциональность Lighthouse CI обеспечивается интерфейсом командной строки Lighthouse CI. (Примечание. Это отдельный инструмент, отличный от интерфейса командной строки Lighthouse .) Интерфейс командной строки Lighthouse CI предоставляет набор команд для использования Lighthouse CI. Например, команда autorun выполняет несколько запусков Lighthouse, определяет медианный отчет Lighthouse и загружает отчет в хранилище. Это поведение можно сильно настроить, передав дополнительные флаги или настроив файл конфигурации Lighthouse CI, lighthouserc.js .

Хотя основные функции Lighthouse CI в основном инкапсулированы в интерфейсе командной строки Lighthouse CI, Lighthouse CI обычно используется одним из следующих подходов:

  • Запуск Lighthouse CI как часть непрерывной интеграции
  • Использование действия Lighthouse CI GitHub, которое запускается и комментирует каждый запрос на извлечение.
  • Отслеживание производительности с течением времени с помощью информационной панели Lighthouse Server.

Все эти подходы основаны на интерфейсе командной строки Lighthouse CI.

Альтернативы Lighthouse CI включают сторонние службы мониторинга производительности или написание собственного сценария для сбора данных о производительности в процессе CI. Вам следует рассмотреть возможность использования сторонней службы, если вы предпочитаете, чтобы кто-то другой управлял вашим сервером мониторинга производительности и тестовыми устройствами, или если вам нужны возможности уведомлений (например, электронная почта или интеграция со Slack) без необходимости создавать их. особенности себя.

Используйте Lighthouse CI локально

В этом разделе объясняется, как запустить и установить интерфейс командной строки Lighthouse CI локально и как настроить lighthouserc.js . Локальный запуск CLI Lighthouse CI — это самый простой способ убедиться, что ваш lighthouserc.js настроен правильно.

  1. Установите интерфейс командной строки Lighthouse CI.

    npm install -g @lhci/cli
    

    Lighthouse CI настраивается путем размещения файла lighthouserc.js в корне репозитория вашего проекта. Этот файл является обязательным и будет содержать информацию о конфигурации, связанную с Lighthouse CI. Хотя Lighthouse CI можно настроить для использования без репозитория git , инструкции в этой статье предполагают, что репозиторий вашего проекта настроен на использование git.

  2. В корне вашего репозитория создайте файл конфигурации lighthouserc.js .

    touch lighthouserc.js
    
  3. Добавьте следующий код в lighthouserc.js . Этот код представляет собой пустую конфигурацию Lighthouse CI. Вы добавите эту конфигурацию на последующих шагах.

    module.exports = {
      ci: {
        collect: {
          /* Add configuration here */
        },
        upload: {
          /* Add configuration here */
        },
      },
    };
    
  4. Каждый раз, когда запускается Lighthouse CI, он запускает сервер для обслуживания вашего сайта. Именно этот сервер позволяет Lighthouse загружать ваш сайт, даже если другие серверы не работают. Когда Lighthouse CI завершит работу, он автоматически завершит работу сервера. Чтобы обеспечить правильную работу обслуживания, необходимо настроить свойства staticDistDir или startServerCommand .

    Если ваш сайт статический, добавьте свойство staticDistDir к объекту ci.collect чтобы указать, где расположены ваши статические файлы. Lighthouse CI будет использовать собственный сервер для обслуживания этих файлов во время тестирования вашего сайта. Если ваш сайт не статический, добавьте свойство startServerCommand к объекту ci.collect , чтобы указать команду, запускающую ваш сервер. Lighthouse CI запустит новый серверный процесс во время тестирования и после этого завершит его.

    // Static site example
    collect: {
      staticDistDir: './public',
    }
    
    // Dynamic site example
    collect: {
      startServerCommand: 'npm run start',
    }
    
  5. Добавьте свойство url к объекту ci.collect , чтобы указать URL-адреса, по которым Lighthouse CI должен запускать Lighthouse. Значение свойства url должно быть предоставлено в виде массива URL-адресов; этот массив может содержать один или несколько URL-адресов. По умолчанию Lighthouse CI запускает Lighthouse три раза для каждого URL-адреса.

    collect: {
      // ...
      url: ['http://localhost:8080']
    }
    
  6. Добавьте свойство target к объекту ci.upload и установите значение 'temporary-public-storage' . Отчет(ы) Lighthouse, собранные Lighthouse CI, будут загружены во временное общедоступное хранилище. Отчет будет храниться там семь дней, а затем будет автоматически удален. В этом руководстве по настройке используется вариант загрузки «временное общедоступное хранилище», поскольку его можно быстро настроить. Информацию о других способах хранения отчетов Lighthouse можно найти в документации .

    upload: {
      target: 'temporary-public-storage',
    }
    

    Место хранения отчета будет примерно таким:

    https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html
    

    (Этот URL-адрес не будет работать, поскольку отчет уже удален.)

  7. Запустите интерфейс командной строки Lighthouse CI из терминала, используя команду autorun . При этом Lighthouse запустится три раза и загрузится средний отчет Lighthouse.

    lhci autorun
    

    Если вы правильно настроили Lighthouse CI, выполнение этой команды должно привести к выводу, подобному этому:

      .lighthouseci/ directory writable
    ✅  Configuration file found
    ✅  Chrome installation found
    ⚠️   GitHub token not set
    Healthcheck passed!
    
    Started a web server on port 65324...
    Running Lighthouse 3 time(s) on http://localhost:65324/index.html
    Run #1...done.
    Run #2...done.
    Run #3...done.
    Done running Lighthouse!
    
    Uploading median LHR of http://localhost:65324/index.html...success!
    Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html
    No GitHub token set, skipping GitHub status check.
    
    Done running autorun.
    

    Вы можете игнорировать сообщение GitHub token not set в выводе консоли. Токен GitHub необходим только в том случае, если вы хотите использовать Lighthouse CI с действием GitHub. Как настроить действие GitHub, описано далее в этой статье.

    Нажав на ссылку в выводе, которая начинается с https://storage.googleapis.com... вы перейдете к отчету Lighthouse, соответствующему среднему запуску Lighthouse.

    Значения по умолчанию, используемые autorun можно переопределить через командную строку или lighthouserc.js . Например, приведенная ниже конфигурация lighthouserc.js указывает, что пять запусков Lighthouse должны собираться каждый раз при выполнении autorun .

  8. Обновите lighthouserc.js , чтобы использовать свойство numberOfRuns :

    module.exports = {
        // ...
        collect: {
          numberOfRuns: 5
        },
      // ...
      },
    };
    
  9. Повторно запустите команду autorun :

    lhci autorun
    

    Вывод терминала должен показать, что Lighthouse запускался пять раз, а не три по умолчанию:

      .lighthouseci/ directory writable
    ✅  Configuration file found
    ✅  Chrome installation found
    ⚠️   GitHub token not set
    Healthcheck passed!
    
    Automatically determined ./dist as `staticDistDir`.
    Set it explicitly in lighthouserc.json if incorrect.
    
    Started a web server on port 64444...
    Running Lighthouse 5 time(s) on http://localhost:64444/index.html
    Run #1...done.
    Run #2...done.
    Run #3...done.
    Run #4...done.
    Run #5...done.
    Done running Lighthouse!
    
    Uploading median LHR of http://localhost:64444/index.html...success!
    Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html
    No GitHub token set, skipping GitHub status check.
    
    Done running autorun.
    

    Чтобы узнать о других вариантах конфигурации, обратитесь к документации по конфигурации Lighthouse CI.

Настройте процесс CI для запуска Lighthouse CI

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

Использование Lighthouse CI для сбора показателей производительности — хорошее место для начала мониторинга производительности. Однако опытные пользователи могут захотеть пойти еще дальше и использовать Lighthouse CI для неудачных сборок, если они не соответствуют заранее определенным критериям, таким как прохождение определенных аудитов Lighthouse или соответствие всем бюджетам производительности. Такое поведение настраивается с помощью свойства assert файла lighthouserc.js .

Lighthouse CI поддерживает три уровня утверждений:

  • off : игнорировать утверждения
  • warn : ошибки печати в stderr
  • error : ошибки печати в stderr и выход из Lighthouse CI с ненулевым кодом выхода.

Ниже приведен пример конфигурации lighthouserc.js , включающей утверждения. Он устанавливает утверждения для оценок категорий производительности и доступности Lighthouse. Чтобы попробовать это, добавьте утверждения, показанные ниже, в файл lighthouserc.js , а затем перезапустите Lighthouse CI.

module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', {minScore: 1}],
        'categories:accessibility': ['error', {minScore: 1}]
      }
    },
    upload: {
      // ...
    },
  },
};

Вывод консоли, который он генерирует, выглядит следующим образом:

Скриншот предупреждающего сообщения, созданного Lighthouse CI

Дополнительную информацию об утверждениях Lighthouse CI можно найти в документации .

Настройте действие GitHub для запуска Lighthouse CI.

Действие GitHub можно использовать для запуска Lighthouse CI. Это будет генерировать новый отчет Lighthouse каждый раз, когда изменение кода будет отправлено в любую ветку репозитория GitHub. Используйте это вместе с проверкой статуса , чтобы отображать эти результаты при каждом запросе на включение.

Скриншот проверки статуса GitHub
  1. В корне вашего репозитория создайте каталог с именем .github/workflows . Рабочие процессы вашего проекта будут находиться в этом каталоге. Рабочий процесс — это процесс, который запускается в заранее определенное время (например, при отправке кода) и состоит из одного или нескольких действий.

    mkdir .github
    mkdir .github/workflows
    
  2. В .github/workflows создайте файл с именем lighthouse-ci.yaml . Этот файл будет содержать конфигурацию нового рабочего процесса.

    touch lighthouse-ci.yaml
    
  3. Добавьте следующий текст в lighthouse-ci.yaml .

    name: Build project and run Lighthouse CI
    on: [push]
    jobs:
      lhci:
        name: Lighthouse CI
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v1
          - name: Use Node.js 10.x
            uses: actions/setup-node@v1
            with:
              node-version: 10.x
          - name: npm install
            run: |
              npm install
          - name: run Lighthouse CI
            run: |
              npm install -g @lhci/cli@0.3.x
              lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
    

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

    • Проверьте репозиторий, в котором будет работать Lighthouse CI.
    • Установите и настройте Node.
    • Установите необходимые пакеты npm
    • Запустите Lighthouse CI и загрузите результаты во временное общедоступное хранилище.
  4. Зафиксируйте эти изменения и отправьте их на GitHub. Если вы правильно выполнили описанные выше шаги, отправка кода на GitHub приведет к запуску только что добавленного рабочего процесса.

  5. Чтобы убедиться, что Lighthouse CI сработал, и просмотреть созданный им отчет, перейдите на вкладку «Действия» вашего проекта. Вы должны увидеть проект «Сборка» и рабочий процесс «Запуск Lighthouse CI», указанные в последнем коммите.

    Снимок экрана вкладки «Настройки» GitHub

    Вы можете перейти к отчету Lighthouse, соответствующему конкретному коммиту, на вкладке «Действия» . Нажмите на фиксацию, нажмите на шаг рабочего процесса Lighthouse CI , затем разверните результаты выполнения шага Lighthouse CI .

    Снимок экрана вкладки «Настройки» GitHub

    Вы только что настроили действие GitHub для запуска Lighthouse CI. Это будет наиболее полезно при использовании в сочетании с проверкой статуса GitHub.

Настройте проверку статуса GitHub

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

Снимок экрана вкладки «Настройки» GitHub

Приведенные ниже шаги объясняют, как настроить проверку статуса для Lighthouse CI.

  1. Перейдите на страницу приложения Lighthouse CI GitHub и нажмите «Настроить» .

  2. (Необязательно) Если вы являетесь частью нескольких организаций на GitHub, выберите организацию, владеющую репозиторием, для которого вы хотите использовать Lighthouse CI.

  3. Выберите «Все репозитории» , если вы хотите включить Lighthouse CI во всех репозиториях, или выберите «Только выбирать репозитории», если вы хотите использовать его только в определенных репозиториях, а затем выберите репозитории. Затем нажмите «Установить и авторизовать» .

  4. Скопируйте отображаемый токен. Вы будете использовать его на следующем шаге.

  5. Чтобы добавить токен, перейдите на страницу настроек вашего репозитория GitHub, нажмите «Секреты» , затем нажмите «Добавить новый секрет» .

    Снимок экрана вкладки «Настройки» GitHub
  6. Установите в поле «Имя» значение LHCI_GITHUB_APP_TOKEN , а в поле «Значение» укажите токен, который вы скопировали на последнем шаге, а затем нажмите кнопку «Добавить секрет» .

  7. Перейдите к файлу lighthouse-ci.yaml и добавьте новый секрет среды в команду «Запустить Lighthouse CI».

-           name: run Lighthouse CI
            run: |
              npm install -g @lhci/cli@0.3.x
              lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
+            env:
+              LHCI_GITHUB_APP_TOKEN: $
  1. Проверка статуса готова к использованию. Чтобы протестировать его, создайте новый запрос на включение или внесите фиксацию в существующий запрос на включение.

Настройте CI-сервер Lighthouse

Сервер Lighthouse CI предоставляет панель мониторинга для изучения исторических отчетов Lighthouse. Он также может выступать в качестве частного долгосрочного хранилища данных для отчетов Lighthouse.

Снимок экрана панели управления Lighthouse CI Server
Снимок экрана: сравнение двух отчетов Lighthouse на Lighthouse CI Server
  1. Выберите, какие коммиты сравниваются.
  2. Сумма, на которую изменилась оценка Lighthouse между двумя фиксациями.
  3. В этом разделе показаны только метрики, которые изменились между двумя коммитами.
  4. Регрессии выделены розовым цветом.
  5. Улучшения выделены синим цветом.

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

Информацию о настройке сервера Lighthouse CI, включая рецепты использования Heroku и Docker для развертывания, можно найти в этих инструкциях .

Узнать больше