GitHub Actions などの継続的インテグレーション システムに Lighthouse を追加する方法について説明します。
Lighthouse CI は、Google Cloud が提供する Lighthouse を使用する場合のツールを紹介します。Lighthouse CI は、 組み込みます。このガイドの内容 次のトピックをご覧ください。
- Lighthouse CI CLI を使用する。
- Lighthouse CI を実行するように CI プロバイダを構成する。
- GitHub のアクションと ステータス チェック Lighthouse の CI の作成ですこれにより、Lighthouse の検索結果が自動的に表示されます。 GitHub の pull リクエスト。
- Lighthouse レポート用にパフォーマンス ダッシュボードとデータストアを構築する。
概要
Lighthouse CI は、Lighthouse の使用を促進するための無料ツールスイートです。 パフォーマンスモニタリングですLighthouse レポートでは、発生したすべてのウェブページが 実行時のページのパフォーマンスLighthouse CI では、これらのイベントが 検出結果は時間とともに変化していますこれを使用して パフォーマンスのしきい値を確実に満たすようにすることが 継続的インテグレーションプロセスを サポートしますパフォーマンスのモニタリングは 他の側面をモニタリングするために使用できます。 Lighthouse レポート(SEO、ユーザー補助など)に関する変更です。
Lighthouse CI のコア機能は Lighthouse CI コマンドで実現
使用できます。(注: これは Lighthouse とは別個のツールです)。
CLI を使用します)。「
Lighthouse CI CLI には、
コマンド
おすすめの方法をご覧くださいたとえば、autorun
コマンドを実行すると複数の
Lighthouse が実行され、Lighthouse レポートの中央値が特定され、レポートがアップロードされる
されます。この動作は、追加のフラグを渡すことで大幅にカスタマイズできます。
Lighthouse CI の構成ファイル lighthouserc.js
をカスタマイズします。
Lighthouse CI のコア機能は主に 使用できます。Lighthouse CI は通常、 次のようなアプローチがあります。
- 継続的インテグレーションの一環として Lighthouse CI を実行する
- pull のたびに実行とコメントを行う Lighthouse CI GitHub Action を使用する リクエスト
- Lighthouse で提供されるダッシュボードでパフォーマンスの推移をトラッキングする できます。
これらのアプローチはすべて、Lighthouse CI CLI を基盤としています。
Lighthouse CI の代わりに、サードパーティのパフォーマンス モニタリングを使用することもできます。 CI 中にパフォーマンス データを収集するための独自のスクリプトを記述するか、 プロセスです許可したい場合は、サードパーティ サービスの 別のユーザーがパフォーマンス モニタリング サーバーの管理を担当していて、 通知機能(メールや Slack のチャットなど)が必要な場合は、 統合など)を使用できます。
ローカルで Lighthouse CI を使用する
このセクションでは、Lighthouse CI CLI をローカルで実行してインストールする方法と、
lighthouserc.js
の構成方法Lighthouse CI CLI をローカルで実行すると、
lighthouserc.js
が正しく構成されていることを確認する最も簡単な方法です。
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 では、 サイトのテスト中に独自のサーバーを使用してこれらのファイルを配信する。お使いの サイトが静的でない場合は、startServerCommand
プロパティをci.collect
オブジェクトを使用して、サーバーを起動するコマンドを示します。 Lighthouse CI がテスト中に新しいサーバー プロセスを起動し、シャットダウンします。 減らすことができます// Static site example collect: { staticDistDir: './public', }
// Dynamic site example collect: { startServerCommand: 'npm run start', }
追加
url
プロパティをci.collect
オブジェクトに追加して、Lighthouse CI が送信する URL を示します。 Lighthouse の実行対象にする 必要があると考えていますurl
プロパティの値は次のようになります。 URL の配列として指定します。この配列には 1 つ以上の URL を含めることができます方法 デフォルトでは、Lighthouse CI は URL ごとに Lighthouse を 3 回実行します。collect: { // ... url: ['http://localhost:8080'] }
追加
target
プロパティをci.upload
オブジェクトに設定し、値を'temporary-public-storage'
。以下のユーザーが収集した Lighthouse レポート: Lighthouse CI は一時的な公開ストレージにアップロードされます。レポートは 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 Action の設定方法については、この記事の後半で説明します。名前で始まる出力の
https://storage.googleapis.com...
をタップすると、Lighthouse レポートが表示されます。 Lighthouse の実行時間の中央値に相当しますautorun
で使用されるデフォルトは、コマンドラインまたはlighthouserc.js
。たとえば、次のlighthouserc.js
構成の場合、 は、autorun
のたびに 5 回の Lighthouse 実行を収集する必要があることを示します。 実行されます。numberOfRuns
プロパティを使用するようにlighthouserc.js
を更新します。module.exports = { // ... collect: { numberOfRuns: 5 }, // ... }, };
autorun
コマンドを再実行します。lhci autorun
ターミナルの出力には、Lighthouse が 5 回実行されたことが示されます。 デフォルトの 3 よりも
✅ .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 ツールで使用できます。「CI を構成する」 プロバイダ のセクションに、Lighthouse の CI ドキュメントのコードサンプルが掲載されています。 Lighthouse CI を一般的な CI ツールの構成ファイルに組み込む。 特に、以下のコードサンプルは、Lighthouse CI を実行して、 継続的に確認できます
まずは、Lighthouse CI を使用してパフォーマンス測定値を収集することが推奨されます。
パフォーマンスモニタリングです上級ユーザーの方は一歩進めて
そして、Lighthouse CI を使用して、事前定義済みの要件を満たしていないビルドを失敗させる
Lighthouse の特定の監査に合格する、すべてのパフォーマンス基準を満たす、などの条件を満たす
できます。この動作は、
assert
プロパティ(lighthouserc.js
)をご覧ください。
Lighthouse CI では、次の 3 つのレベルのアサーションがサポートされています。
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 によって生成された警告メッセージのスクリーンショット](https://web.dev/static/articles/lighthouse-ci/image/screenshot-a-warning-mes-f1c97df5d1d.png?authuser=19&hl=ja)
Lighthouse CI アサーションについて詳しくは、 ドキュメントをご覧ください。
GitHub Action を設定して Lighthouse CI を実行する
GitHub Action を使用すると、 Lighthouse CI。これにより、コードが変更されるたびに、新しい Lighthouse レポートが生成されます。 GitHub リポジトリの任意のブランチに push されます。組み合わせて使用 ステータスが 確認 pull リクエストごとに結果を表示します。
![GitHub のステータス チェックのスクリーンショット](https://web.dev/static/articles/lighthouse-ci/image/screenshot-a-github-stat-667c532905358.png?authuser=19&hl=ja)
リポジトリのルートで、という名前のディレクトリを
.github/workflows
。「 ワークフロー このディレクトリに配置されます。ワークフローとは (コードが push されるときなど)に実行され、 1 つ以上のアクションで構成されます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!"
この構成では、実行する単一のジョブで構成されるワークフローが設定されます。 新しいコードがリポジトリに push されるたびに発生します。このジョブには 4 つのステップがあります。
- Lighthouse CI の実行先となるリポジトリを確認する
- ノードをインストールして構成する
- 必要な npm パッケージをインストールする
- Lighthouse CI を実行し、結果を一時的な公開ストレージにアップロードします。
これらの変更を commit して GitHub に push します。ルールの GitHub にコードを push すると、ワークフローの実行がトリガーされます。 表示されます。
Lighthouse CI がトリガーされたことを確認し、レポートを表示する プロジェクトの [アクション] タブに移動します。[ [Build project and Run Lighthouse CI] ワークフローは、 確認できます。
特定の commit に対応する Lighthouse レポートに移動できる [操作] タブで操作できます。commit をクリックし、[Lighthouse CI] をクリックします。 [run Lighthouse CI] ステップの結果を展開します。
これで、Lighthouse CI を実行するための GitHub Action を設定できました。これは GitHub のステータスと組み合わせて使用すると便利です。 チェックします。
GitHub ステータス チェックを設定する
ステータス チェック(設定されている場合)は、すべての PR に表示され、 通常はテストの結果やテストの合格状況などの情報が 構築できます。
![GitHub の「Settings」のスクリーンショットタブ](https://web.dev/static/articles/lighthouse-ci/image/screenshot-the-github-s-67f929ea66a01.png?authuser=19&hl=ja)
以下の手順では、Lighthouse CI のステータス チェックを設定する方法について説明します。
Lighthouse CI GitHub アプリに移動します。 ページに移動し、[構成] をクリックします。
(省略可)GitHub で複数の組織に所属している場合は、 Lighthouse を使用するリポジトリを所有する組織 CI
すべてのリポジトリで Lighthouse CI を有効にする場合は、[All repositories] を選択します。 使用する場合は、[Only select repositories] を選択します。 特定のリポジトリに配置し、そのリポジトリを選択します。[ インストールと承認する。
表示されたトークンをコピーします。これを次のステップで使用します。
トークンを追加するには、GitHub の [Settings] ページに移動します。 [Secret] をクリックし、[Add a new secret] をクリックします。
[名前] フィールドを
LHCI_GITHUB_APP_TOKEN
に設定し、[値] を設定します。 前のステップでコピーしたトークンを入力し、[Add シークレット ボタン。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 を作成してから、 リクエスト commit を既存の pull リクエストに push できます。
Lighthouse CI サーバーを設定する
Lighthouse CI サーバーは、ダッシュボードを使用して履歴を調査できます。 Lighthouse レポート。また、プライベートな長期保存のデータストアとしても機能し、 Lighthouse レポート。
![Lighthouse CI サーバー ダッシュボードのスクリーンショット](https://web.dev/static/articles/lighthouse-ci/image/screenshot-the-lighthous-bf52f6dd2ad0e.png?authuser=19&hl=ja)
![Lighthouse CI Server で 2 つの Lighthouse レポートを比較した場合のスクリーンショット](https://web.dev/static/articles/lighthouse-ci/image/screenshot-comparing-li-a86afa61fb603.png?authuser=19&hl=ja)
- 比較するコミットを選択します。
- 2 つの commit の間での Lighthouse スコアの変化量。
- このセクションには、2 つの commit 間で変更された指標のみが表示されます。
- 回帰はピンクでハイライト表示されます。
- 改善点は青色でハイライト表示されます。
Lighthouse CI Server は、デプロイやデプロイに慣れている 管理する必要もありません。
Lighthouse CI サーバーのセットアップについて詳しくは、以下のリンクをご覧ください。 Heroku と Docker を使用してデプロイする場合は、 こちらの手順をご覧ください。