Lighthouse CIを利用したWebサイト品質監査の自動化
Webサイト制作、開発の現場ではプロダクトの品質を保つために定期的な監査が求められます。Webサイトを定量的に監査するための手段はいくつかあると思いますが、Lighthouseと呼ばれるツールが一般的に広く利用されています。
Lighthouseとは
LighthouseはGoogleが提供するオープンソースの品質監査ツールです。Lighthouseの監査は以下の指標を基に行われます。
- パフォーマンス
- アクセシビリティ
- ベストプラクティス
- SEO
- PWA対応
PWA対応をどこまで実施するかは案件によって変わってくるかと思いますが、基本的にLighthouseで示される品質監査結果を向上させることでよりユーザーが使いやすく、そして検索されやすいサイトにすることができます。
LighthouseはChromeの拡張機能を利用することで簡単にページの監査結果を取得することができます。
ブラウザから簡易測定できるのは非常に便利である一方、開発段階や納品前に手動で１ページづつ計測するにはかなり骨が折れます。
そこでLighthouseによる監査を一定のタイミングでより簡単に実施する方法を紹介したいと思います。
Lighthouse CIとは
Lighthouse CIはLighthouseによる監査結果を一定のタイミングで継続的に取得することができる自動化ツールです。
このツールを利用するには以下の条件を満たす必要があります。
- ソースコードをGitで管理している
- Travis CI, CircleCI, Jenkins, AppVeyor, GitHub ActionsなどCI/CDツールによるビルド及びデプロイの自動化を導入している
- 静的サイトであること
まずはローカルのプロジェクト環境でLighthouseの監査をコマンドベースで実行できるようにしたいと思います。以下コマンドでLighthouse CIをインストールしてください。
npm install -g @lhci/cliLighthouse CIのコマンドがインストールできたら、設定ファイルをプロジェクトディレクトリのルート直下にlighthouserc.jsを作成します。
ここではReactのフレームワークGatsby.jsのプロジェクトをベースに解説したいと思います。利用したいプロジェクト構成に合わせて適宜記載を変更してください。
project
├── public
| ├── index.html
| └── その他ファイル
├── src
| ├── pages
| ├── images
| └── components
├── lighthouserc.js
├── node_modules
├── package.json
└── その他ファイル省略lighthouserc.jsには以下のようにコードを記載してください。
module.exports = {
ci: {
collect: {
numberOfRuns: 3,
staticDistDir: "./public",
url: [
"/"
]
},
upload: {
target: "temporary-public-storage",
},
},
};collectでは監査対象に関する詳細設定をすることができます。上記サンプルでは１ページに対する監査の実行を３回行うようにしています。複数回行うことで監査結果のブレを補正できますがその分時間がかかります。標準では３回実施されるように設定されています。
staticDistDirには公開ディレクトリを記載します。ここではpublicにしています。urlでは監査対象となるページを指定します。指定しない場合は全てのページに対して実行されるため、かなり時間がかかります。普段は監査が必要ページだけを記載するようにすると良いでしょう。
uploadでtarget=temporary-public-storageにすることでGCP Cloud Storageに7日間一時的に監査結果が保存されます。
7日以上レポート結果を保持したい場合などでは他のオプションが用意されているので検討してみてください。
今回Lighthouse CIの設定ファイルはJavaScriptで記述しましたが、他にも以下のファイル名、拡張子で設定することができます。
- .lighthouserc.js
- lighthouserc.js
- .lighthouserc.json
- lighthouserc.json
- .lighthouserc.yml
- lighthouserc.yml
- .lighthouserc.yaml
- lighthouserc.yaml
ここまで設定できたら、開発プロジェクトを一度ビルドした後に以下コマンドを実行してください。
lhci autorun次のように順番に指定したページの監査が実行されていればOKです。
Started a web server on port 52150...
Running Lighthouse 3 time(s) on http://localhost:52150/
Run #1...done.
Run #2...done.
Run #3...done.
Running Lighthouse 3 time(s) on http://localhost:52150/page-2/
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!最後に監査結果のURLが表示されるのでアクセスしてみましょう。次のようにレポート結果が出力されていればローカルでの実行は完了です。
Lighthouse CIとGitHub Actionsによる計測の自動化
次にLighthouse CIのコマンド実行が一定のタイミングで行われるように自動化させる方法をみていきましょう。
CI/CDにLighthouseの監査を組み込むには様々なツールが利用できます。今回はGitHubが提供するGitHub Actionsを使った方法を紹介したいと思います。
GitHub Actionsの基本的な設定方法は以下記事を参照してください。
GitHub Actionsのワークフローが記載されているymlファイルに以下を追記してください。
以上の設定まで完了したら実際にコミットをプッシュしてワークフローが正常に動作するか確認してみましょう。
Run Lighthouse CI を展開するとローカルで実行したようにレポート結果のURLが出力されています。
補足
Lighthouse CIとGitHub Actionsで計測が自動化されましたが、ここまできたら通知も自動化したいと思います。GitHub ActionsでSlackに通知を送る場合は以下記事を参照してみてください。
以下記述を既存のワークフローに追加します。SLACK_WEBHOOK_URLには環境変数として利用したいSlackのWebhook URLを設定しておきます。
SlackのWebhook URL取得手順は次の記事を参照してください。
以下のように通知が来れば完了です。
まとめ
この記事で紹介したLighthouse CIの設定は非常に簡易的なものになります。より詳細な設定方法は公式のドキュメントを参照してください。
