이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Lighthouse CI로 성능 모니터링

GitHub Actions와 같은 지속적 통합 시스템에 Lighthouse를 추가하는 방법

Katie Hempenius

Lighthouse CI는 지속적 통합 중에 Lighthouse를 사용하기 위한 도구 모음입니다. Lighthouse CI는 여러 가지 방법으로 개발자 워크플로에 통합할 수 있습니다. 이 가이드에서는 다음 주제를 다룹니다.

Lighthouse CI CLI 사용
Lighthouse CI를 실행하도록 CI 제공업체를 구성하는 중입니다.
Lighthouse CI의 GitHub 작업 및 상태 확인 설정 이렇게 하면 GitHub pull 요청에 Lighthouse 결과가 자동으로 표시됩니다.
Lighthouse 보고서를 위한 성능 대시보드 및 데이터 스토어 빌드

개요

Lighthouse CI는 무료 도구 모음으로 Lighthouse를 성능 모니터링에 간편하게 사용할 수 있게 해 줍니다. 단일 Lighthouse 보고서는 실행 시점의 웹페이지 성능에 대한 스냅샷을 제공합니다. Lighthouse CI는 이러한 결과가 시간 경과에 따라 어떻게 바뀌었는지 보여줍니다. 이를 통해 특정 코드 변경사항의 영향을 식별하거나 지속적 통합 프로세스 중에 성능 기준점이 충족되도록 할 수 있습니다. 성능 모니터링은 Lighthouse CI의 가장 일반적인 사용 사례이지만 Lighthouse 보고서의 다른 측면(예: 검색엔진 최적화 또는 접근성)을 모니터링하는 데 사용할 수 있습니다.

Lighthouse CI의 핵심 기능은 Lighthouse CI 명령줄 인터페이스에서 제공됩니다. (참고: 이 도구는 Lighthouse CLI와 별도의 도구입니다.) Lighthouse CI CLI는 Lighthouse CI를 사용하기 위한 명령어 집합을 제공합니다. 예를 들어 autorun 명령어는 Lighthouse 실행을 여러 번 실행하고 Lighthouse 보고서 중앙값을 식별하며 저장을 위해 보고서를 업로드합니다. 추가 플래그를 전달하거나 Lighthouse CI의 구성 파일 lighthouserc.js를 맞춤설정하여 이 동작을 크게 맞춤설정할 수 있습니다.

Lighthouse CI의 핵심 기능은 주로 Lighthouse CI CLI에 캡슐화되어 있지만 Lighthouse CI는 일반적으로 다음 접근 방식 중 하나를 통해 사용됩니다.

지속적 통합의 일부로 Lighthouse CI 실행
모든 pull 요청을 실행하고 주석을 작성하는 Lighthouse CI GitHub 작업 사용
Lighthouse Server에서 제공하는 대시보드를 통해 시간 경과에 따른 성능 추적

이러한 모든 접근 방식은 Lighthouse CI CLI를 기반으로 합니다.

Lighthouse CI의 대안으로는 서드 파티 성능 모니터링 서비스 또는 CI 프로세스 중에 성능 데이터를 수집하는 자체 스크립트 작성이 있습니다. 성능 모니터링 서버 및 테스트 기기의 관리를 다른 사람이 처리하도록 하거나 이러한 기능을 직접 빌드하지 않고도 알림 기능 (예: 이메일 또는 Slack 통합)을 사용하려면 서드 파티 서비스를 사용하는 것이 좋습니다.

로컬에서 Lighthouse CI 사용

이 섹션에서는 Lighthouse CI CLI를 로컬에서 실행 및 설치하는 방법과 lighthouserc.js를 구성하는 방법을 설명합니다. lighthouserc.js이 올바르게 구성되었는지 확인하는 가장 쉬운 방법은 Lighthouse CI CLI를 로컬에서 실행하는 것입니다.

Lighthouse CI CLI를 설치합니다.
```
npm install -g @lhci/cli
```
Lighthouse CI는 프로젝트 저장소의 루트에 lighthouserc.js 파일을 배치하는 방식으로 구성됩니다. 이 파일은 필수 파일이며 Lighthouse CI 관련 구성 정보를 포함합니다. Lighthouse CI는 git 저장소 없이 사용하도록 구성할 수 있지만 이 문서의 안내에서는 프로젝트 저장소가 git을 사용하도록 구성되어 있다고 가정합니다.
저장소 루트에서 lighthouserc.js 구성 파일을 만듭니다.
```
touch lighthouserc.js
```
다음 코드를 lighthouserc.js에 추가합니다. 이 코드는 빈 Lighthouse CI 구성입니다. 이후 단계에서 이 구성에 추가합니다.
```
module.exports = {
  ci: {
    collect: {
      /* Add configuration here */
    },
    upload: {
      /* Add configuration here */
    },
  },
};
```
Lighthouse CI가 실행될 때마다 사이트를 제공하기 위한 서버를 시작합니다. 이 서버를 통해 Lighthouse는 실행 중인 다른 서버가 없을 때도 사이트를 로드할 수 있습니다. Lighthouse CI의 실행이 완료되면 서버가 자동으로 종료됩니다. 제공이 올바르게 작동하도록 하려면 staticDistDir 또는 startServerCommand 속성을 구성해야 합니다.

사이트가 정적인 경우 staticDistDir 속성을 ci.collect 객체에 추가하여 정적 파일의 위치를 나타냅니다. Lighthouse CI는 자체 서버를 사용하여 사이트를 테스트하는 동안 이러한 파일을 제공합니다. 사이트가 정적이 아닌 경우 ci.collect 객체에 startServerCommand 속성을 추가하여 서버를 시작하는 명령어를 표시합니다. Lighthouse CI는 테스트 중에 새 서버 프로세스를 시작한 후 종료합니다.
```
// Static site example
collect: {
  staticDistDir: './public',
}
```
```
// Dynamic site example
collect: {
  startServerCommand: 'npm run start',
}
```
url 속성을 ci.collect 객체에 추가하여 Lighthouse CI를 실행할 때 기준이 되는 URL을 나타냅니다. url 속성 값은 URL의 배열로 제공되어야 합니다. 이 배열에는 URL이 1개 이상 포함될 수 있습니다. 기본적으로 Lighthouse CI는 각 URL에 대해 Lighthouse를 3번 실행합니다.
```
collect: {
  // ...
  url: ['http://localhost:8080']
}
```
참고: 이러한 URL은 이전 단계에서 구성한 서버에서 제공할 수 있어야 합니다. 따라서 Lighthouse CI를 로컬에서 실행하는 경우 이러한 URL에는 프로덕션 호스트가 아닌 localhost가 포함될 수 있습니다.
target 속성을 ci.upload 객체에 추가하고 값을 'temporary-public-storage'로 설정합니다. Lighthouse CI에서 수집한 Lighthouse 보고서는 임시 공용 스토리지에 업로드됩니다. 보고서는 7일 동안 보관된 후 자동으로 삭제됩니다. 이 설정 가이드에서는 빠르게 설정할 수 있는 '임시 공용 저장소' 업로드 옵션을 사용합니다. Lighthouse 보고서를 저장하는 다른 방법에 대한 자세한 내용은 문서를 참조하세요.
```
upload: {
  target: 'temporary-public-storage',
}
```
보고서의 저장 위치는 다음과 유사합니다.
```
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html
```
(보고서가 이미 삭제되었으므로 이 URL은 작동하지 않습니다.)
autorun 명령어를 사용하여 터미널에서 Lighthouse CI CLI를 실행합니다. 이렇게 하면 Lighthouse가 3번 실행되고 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 토큰은 GitHub 작업에 Lighthouse CI를 사용하려는 경우에만 필요합니다. GitHub 작업을 설정하는 방법은 이 도움말의 뒷부분에서 설명합니다.

출력에서 https://storage.googleapis.com...로 시작하는 링크를 클릭하면 Lighthouse 실행 중앙값에 해당하는 Lighthouse 보고서로 이동합니다.

autorun에서 사용하는 기본값은 명령줄 또는 lighthouserc.js를 통해 재정의할 수 있습니다. 예를 들어 아래의 lighthouserc.js 구성은 autorun가 실행될 때마다 Lighthouse 실행을 5번 수집해야 함을 나타냅니다.

numberOfRuns 속성을 사용하도록 lighthouserc.js를 업데이트합니다.

module.exports = {
    // ...
    collect: {
      numberOfRuns: 5
    },
  // ...
  },
};

autorun 명령어를 다시 실행합니다.

lhci autorun

터미널 출력에 Lighthouse가 기본 3번이 아닌 5번 실행되었다고 표시됩니다.

✅  .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 구성 문서를 참조하세요.

Lighthouse CI를 실행하도록 CI 프로세스 설정

Lighthouse CI는 원하는 CI 도구와 함께 사용할 수 있습니다. Lighthouse CI 문서의 CI 제공자 구성 섹션에는 Lighthouse CI를 일반 CI 도구의 구성 파일에 통합하는 방법을 보여주는 코드 샘플이 포함되어 있습니다. 특히 이 코드 샘플은 CI 프로세스 중에 Lighthouse CI를 실행하여 성능 측정값을 수집하는 방법을 보여줍니다.

Lighthouse CI를 사용하여 성능 측정값을 수집하는 것이 성능 모니터링을 시작하는 좋은 방법입니다. 그러나 고급 사용자는 한 단계 더 나아가 Lighthouse CI를 사용하여 특정 Lighthouse 감사를 통과하거나 모든 성능 예산을 충족하는 등 사전 정의된 기준을 충족하지 못한다면 빌드에 실패하는 것이 좋습니다. 이 동작은 lighthouserc.js 파일의 assert 속성을 통해 구성됩니다.

Lighthouse CI는 세 가지 어설션 수준을 지원합니다.

off: 어설션 무시
warn: 실패를 stderr에 출력합니다.
error: 실패를 stderr에 출력하고 0이 아닌 종료 코드를 사용하여 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 작업 설정

GitHub 작업을 사용하여 Lighthouse CI를 실행할 수 있습니다. 이렇게 하면 코드 변경사항이 GitHub 저장소의 브랜치로 푸시될 때마다 새로운 Lighthouse 보고서가 생성됩니다. 상태 확인과 함께 사용하여 각 pull 요청에 대해 이러한 결과를 표시합니다.

저장소의 루트에서 .github/workflows라는 디렉터리를 만듭니다. 프로젝트의 워크플로가 이 디렉터리에 위치합니다. 워크플로는 미리 정해진 시간 (예: 코드가 푸시될 때)에 실행되는 프로세스이며 하나 이상의 작업으로 구성됩니다.
```
mkdir .github
mkdir .github/workflows
```
.github/workflows에서 lighthouse-ci.yaml 파일을 만듭니다. 이 파일에는 새 워크플로에 대한 구성이 저장됩니다.
```
touch lighthouse-ci.yaml
```

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!"

이 구성은 새 코드가 저장소에 푸시될 때마다 실행되는 단일 작업으로 구성된 워크플로를 설정합니다. 이 작업에는 4단계가 있습니다.

Lighthouse CI를 실행할 저장소를 확인합니다.
노드 설치 및 구성
필수 npm 패키지 설치
Lighthouse CI를 실행하고 결과를 임시 공용 스토리지에 업로드합니다.

변경사항을 커밋하고 GitHub에 푸시합니다. 위 단계를 올바르게 따른 경우 코드를 GitHub에 푸시하면 방금 추가한 워크플로 실행이 트리거됩니다.
Lighthouse CI가 트리거되었는지 확인하고 Lighthouse CI에서 생성한 보고서를 보려면 프로젝트의 작업 탭으로 이동합니다. 최근 커밋 아래에 프로젝트 빌드 및 Lighthouse CI 실행 워크플로가 나열되어야 합니다.

작업 탭에서 특정 커밋에 해당하는 Lighthouse 보고서로 이동할 수 있습니다. 커밋을 클릭하고 Lighthouse CI 워크플로 단계를 클릭한 다음 Lighthouse CI 실행 단계의 결과를 펼칩니다.

Lighthouse CI를 실행하기 위한 GitHub 작업을 설정했습니다. GitHub 상태 확인과 함께 사용할 때 가장 유용합니다.

GitHub 상태 확인 설정

상태 확인은 구성된 경우 모든 PR에 표시되는 메시지이며 일반적으로 테스트 결과 또는 빌드 성공과 같은 정보를 포함합니다.

아래 단계에서는 Lighthouse CI의 상태 확인을 설정하는 방법을 설명합니다.

Lighthouse CI GitHub 앱 페이지로 이동하여 구성을 클릭합니다.
(선택사항) GitHub에서 여러 조직에 속한 경우 Lighthouse CI를 사용할 저장소를 소유한 조직을 선택합니다.
모든 저장소에 Lighthouse CI를 사용 설정하려면 모든 저장소를 선택하고 특정 저장소에서만 Lighthouse CI를 사용하려면 저장소만 선택을 선택한 후 저장소를 선택합니다. 그런 다음 Install & Authorize(설치 및 승인)를 클릭합니다.
표시된 토큰을 복사합니다. 다음 단계에서 이를 사용합니다.
토큰을 추가하려면 GitHub 저장소의 설정 페이지로 이동하여 보안 비밀을 클릭한 후 새 보안 비밀 추가를 클릭합니다.
이름 필드를 LHCI_GITHUB_APP_TOKEN로 설정하고 값 필드를 이전 단계에서 복사한 토큰으로 설정한 후 보안 비밀 추가 버튼을 클릭합니다.
lighthouse-ci.yaml 파일로 이동하여 'run 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: $

상태 확인을 사용할 수 있습니다. 테스트하려면 새 pull 요청을 생성하거나 기존 pull 요청으로 커밋을 푸시합니다.

Lighthouse CI 서버 설정

Lighthouse CI 서버는 Lighthouse 이전 보고서를 살펴볼 수 있는 대시보드를 제공합니다. Lighthouse 보고서의 장기 비공개 데이터 스토어 역할도 합니다.

Lighthouse CI 서버에서 두 Lighthouse 보고서를 비교하는 스크린샷

비교할 커밋을 선택합니다.
두 커밋 간의 Lighthouse 점수 변동량입니다.
이 섹션에는 두 커밋 간에 변경된 측정항목만 표시됩니다.
회귀는 분홍색으로 강조표시됩니다.
개선사항은 파란색으로 강조표시됩니다.

Lighthouse CI Server는 자체 인프라를 배포하고 관리하는 데 익숙한 사용자에게 가장 적합합니다.

배포를 위해 Heroku 및 Docker를 사용하는 레시피를 비롯하여 Lighthouse CI 서버 설정에 대한 자세한 내용은 이 instructions를 참조하세요.

자세히 알아보기

Lighthouse CI GitHub 저장소