Webサイトのパフォーマンスが重要視される昨今、皆さんもパフォーマンスの継続的な監視に課題を感じているのではないでしょうか。
特に、Lighthouse を使った手動でのパフォーマンス計測や、その結果レポートの保存には、意外と手間と時間がかかります。
私自身もこの課題を解決したいと考え、Lighthouse CI を導入して計測を自動化したところ、開発体験が大きく向上しました。
そこで本記事では、その具体的な導入方法とメリットなどをご紹介できればと思います。
▼ こんな方におすすめの記事です
- Lighthouseの手動計測にかかる工数を削減したい
- 継続的にサイトのパフォーマンスを計測・監視する仕組みを導入したい
本記事では、Lighthouse CI を導入し、GitHub Actions で計測ワークフローを実行するまでをハンズオン形式で解説します。
最終的なコードは以下のリポジトリで公開していますので、ぜひ参考にしてください。
- なぜWebパフォーマンスは重要なのか？
- Lighthouse とは
- Lighthouse CIで計測を自動化する
- 実際に導入してみた
- ステップ1：Lighthouse CI GitHub Appのインストール
- ステップ2：パッケージのインストール
- ステップ3：設定ファイルの作成
- ステップ4：ローカル環境での実行
- ステップ5：GitHub Actionsワークフローへの組み込み
- まとめ
本セクションでは、Web サイトにおけるパフォーマンスがなぜ重要なのか、Google が公開している情報を基に改めて解説します。
パフォーマンスは「すべて」に繋がる
結論から言うと、Web パフォーマンスの向上は、ユーザー体験 (UX)・ビジネス成果・検索順位 (SEO) といった、 Web サイトに関わるあらゆる側面でメリットがあります。
ページの表示が遅いことは、単に「ユーザーを待たせる」という問題だけでなく、機会損失やブランドイメージの低下にも繋がります。
大きく 3 つの理由があります。
ユーザー体験 (UX) を劇的に向上させる
ページの読み込みが遅いと、ユーザーはストレスを感じてサイトから離脱してしまいます。
これは多くの開発者が直感的に理解していることですが、Google も同様の考えを持っています。
その思想の根幹にあるのが、Google が製品開発の哲学として掲げる 「ユーザーに焦点を絞れば、他のものはみな後からついてくる (Focus on the user and all else will follow.)」 という、シンプルかつ極めて重要な前提です。
この哲学を技術的な指標として具体的に落とし込んだのが、 Core Web Vitals (コア ウェブ バイタル) です。
出典: Web Vitals の概要: サイトの健全性を示す重要指標
Core Web Vitals は、ユーザー体験の質を測定するための重要な指標群です。
-
LCP (Largest Contentful Paint)
- ページの主要なコンテンツが表示されるまでの時間（読み込み速度）
-
FID (First Input Delay) / INP (Interaction to Next Paint)
- ユーザーが最初に行った操作への応答性（インタラクティブ性）
-
CLS (Cumulative Layout Shift)
- ページの視覚的な安定性（予期せぬレイアウトのズレ）
これらの指標のしきい値が、なぜその値に設定されているのか、その根拠については下記の公式記事で詳しく解説されています。
上記の記事にも記載がありますが、Google と Chromium チームの研究によると、これらの指標がサイトの離脱率に大きく関わっていることがデータで示されています。
私たちは、これらの指標としきい値がユーザーにどのような影響を与えるかを理解するために、何百万ものページインプレッションを分析しました。その結果、サイトが上記のしきい値を満たしている場合、ユーザーがページ読み込みを放棄する（コンテンツが描画される前にページを離れる）可能性が24%低くなることがわかりました。
出典: The science behind Web Vitals (blog.chromium.org)
このように、パフォーマンスの改善はユーザーのストレスを軽減し、コンテンツを確実に届ける上で不可欠です。
ビジネス成果 (CVR, 売上) に直結する
優れたユーザー体験は、最終的にビジネスの成果へと繋がります。
実際に、多くの企業がパフォーマンス改善によってコンバージョン率 (CVR) や売上を向上させており、Google はそれらの成功事例を公開しています。
例えば、T-mobile の事例が公開されています。
サイトのパフォーマンスを改善するための取り組みの結果、Largest Contentful Paint（LCP）が全体で 42% 減少しました。
ウェブサイトのユーザーからの苦情が全体で 20% 減少。
ウェブサイトの読み込みが遅いという苦情が 34% 減少。
ページの読み込み時間が短縮されたことで、購入フローも効率化され、ショッピングの意図がある見込み顧客の訪問のコンバージョン率が同じ期間に 60% 向上しました。
出典: T-Mobile’s data-driven approach to web performance led to a 20% reduction in user site issues and a 60% improvement in visit-to-order rate. (web.dev)
これらの事例は、パフォーマンスが単なる技術指標ではなく、事業の成長を左右する重要な要素であることがわかります。
検索エンジン最適化 (SEO) の評価を高める
Googleは 2021 年より、Core Web Vitals を Google 検索のランキング要因に組み込んでいます。
これは「ページエクスペリエンス シグナル」の一部であり、Web サイトのパフォーマンスが検索結果の順位に直接影響を与えます。
つまり、パフォーマンスを改善することは、ユーザーのためになるだけでなく、Google からの評価を高め、より多くのユーザーにサイトを見つけてもらうための SEO 対策としても極めて有効なのです。
パフォーマンスの重要性については、なんとなくご理解いただけたと思います。
次に、すでにご存知の方も多いかと思いますが、改めて Lighthouse について軽く触れておきます。
Lighthouse は、Google が提供するオープンソースの Web サイト品質監査ツールです。
ウェブサイトの「パフォーマンス」「アクセシビリティ」「ベストプラクティス」「SEO」といった項目を監査し、具体的な改善点をスコアと共に可視化してくれます。
また、Google がユーザー体験における重要な指標として定義している Core Web Vitals である LCP や CLS、そして INP に関連する TBT (Total Blocking Time) も計測できます。
非常に強力なツールですが、手動での利用にはいくつかの課題があります。
- 計測環境による結果のブレ
- ローカルマシンの開発者ツールから実行する場合、マシンスペックやネットワーク環境、インストールされているブラウザ拡張機能などの影響を受け、計測結果にブレが生じる可能性
- 手間と時間がかかる
- 複数ページを計測する場合、1 ページずつ手動で実行し、結果を記録・保存する必要があるため、手間と時間がかかる（定期的に複数ページをチェックするのは大きな負担）
そこで登場するのが Lighthouse CI です。
Lighthouse CI は、Web サイトのパフォーマンスを継続的に監視・改善するための自動化ツールです。
Lighouse を CI/CD（継続的インテグレーション/継続的デリバリー）環境で自動的に実行、結果を保存、分析、評価することができます。
主なメリットとしては、下記です。
- 計測環境の安定化
- CI/CD環境（GitHub Actionsなど）の安定したリソース上で実行されるため、ローカル環境による結果のブレを防ぎ、一貫性のあるデータを取得できる
- 計測プロセスの完全自動化
- プルリクエスト作成時や main ブランチへのマージ時など、特定のトリガーで自動的に計測を実行できる
- これにより、手動での計測漏れや手間を根本からなくすことができる
- 継続的なパフォーマンス監視
- 定期的にパフォーマンスを計測・記録することで、意図しないパフォーマンスの悪化を早期に検知できる
本番環境を計測する PageSpeed Insights とは異なり、開発環境やステージング環境に対しても同様の計測を組み込めるため、デプロイ前のパフォーマンスチェックに特に有効です。
それでは、実際に Lighthouse CI を導入してみたいと思います。
今回は、GitHub Actions のワークフローで Lighthouse CI を実行し、レポート結果を閲覧できる状態をゴールとします。
ステップ1：Lighthouse CI GitHub Appのインストール
まず、GitHub リポジトリと連携するための Lighthouse CI App をインストールし、Token 情報を取得します。
ここでで取得した Token 情報は、後のステップで GitHub Actions の Secrets に設定するため、安全な場所に控えておいてください。
ステップ2：パッケージのインストール
次に、Lighthouse CI の CLI パッケージをプロジェクトにインストールします。
npm install @lhci/cli --save-dev
package.json の scripts に、Lighthouse CI を実行するためのコマンドを追加します。
モバイルとデスクトップで設定を切り替えられるようにしておくと便利です。
"scripts": {
"build": "nuxt build",
"dev": "nuxt dev",
"generate": "nuxt generate",
"preview": "nuxt preview",
"postinstall": "nuxt prepare",
"lhci:mobile": "lhci autorun",
"lhci:desktop": "lhci autorun --collect.settings.preset=desktop"
}
ステップ3：設定ファイルの作成
プロジェクトのルートに .lighthouserc.yml という名前で設定ファイルを作成します。
※ 設定ファイルの形式は .js や .json も選択可能です
今回は、ビルドした Nuxt アプリケーションをプレビューサーバーで起動し、3 つのページに対して計測を行う設定で行います。
- トップ画面（
/）
- ホーム画面（
/home）
- 説明画面（
/about）
フィイル名は、.lighthouserc.ymlで作成します。
また、計測結果のブレを抑えるため numberOfRuns: 3 を指定し、3 回実行した結果の中央値をレポートとして生成します。
レポートは、Lighthouse CI が提供する一時的なパブリックストレージにアップロードします。
ci:
collect:
# 計測前に開発サーバーを起動するコマンド
startServerCommand: npm run build && npm run preview
# 計測対象の URL
url:
- http://localhost:3000/
- http://localhost:3000/home
- http://localhost:3000/about
# 各 URL に対する実行回数
numberOfRuns: 3
upload:
# レポートのアップロード先
target: temporary-public-storage
警告
target: temporary-public-storage は、URL を知っていれば誰でもレポートにアクセスできるため、プライベートなプロジェクトでは lhci-server を別途構築するか、GitHub Actions の Artifact として保存する運用をおすすめします。
ステップ4：ローカル環境での実行
この状態で、Lighthouse CI はローカルでも実行できます。
先ほど scripts に追加したコマンドを実行してみましょう。
# モバイル版の計測を実行
npm run lhci:mobile
# デスクトップ版の計測を実行
npm run lhci:desktop
実行が成功すると、下記のようなログが出力されます。
（この時点では GitHub トークンを設定していないため GitHub token not set という警告が出ますが、ローカル実行では問題ありません。）
lighthouse-ci-playground % npm run lhci:mobile
> lhci:mobile
> lhci autorun
(node:8378) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
✅ .lighthouseci/ directory writable
✅ Configuration file found
✅ Chrome installation found
⚠️ GitHub token not set
Healthcheck passed!
(node:8400) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Started a web server with "npm run build && npm run preview"...
Running Lighthouse 3 time(s) on http://localhost:3000/
Run #1...done.
Run #2...done.
Run #3...done.
Running Lighthouse 3 time(s) on http://localhost:3000/home
Run #1...done.
Run #2...done.
Run #3...done.
Running Lighthouse 3 time(s) on http://localhost:3000/about
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!
(node:8756) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Uploading median LHR of http://localhost:3000/...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/xxxx-xxx.report.html
Uploading median LHR of http://localhost:3000/home...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/xxxx-xxx.report.html
Uploading median LHR of http://localhost:3000/about...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/xxxx-xxx.report.html
No GitHub token set, skipping GitHub status check.
Done running autorun.
(node:8377) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
実行が完了すると、プロジェクトルートに .lighthouseci ディレクトリが作成され、その中に HTML と JSON 形式のレポートが保存されます。
ログに出力された URL、またはローカルに保存された HTML ファイルを開くと、おなじみの Lighthouse レポートを確認できます。
ステップ5：GitHub Actionsワークフローへの組み込み
最後に、このプロセスを GitHub Actions で自動化します。
まず、ステップ1で取得したトークンを、リポジトリの Settings > Secrets and variables > Actions から登録します。
今回は LHCI_GITHUB_APP_TOKEN という名前で Secret を作成します。
次に、.github/workflows/lighthouse.yml という名前でワークフローファイルを作成します。
今回は、main ブランチへの push をトリガーとして、モバイルとデスクトップ両方の Lighthouse を実行し、結果を GitHub Actions の Artifacts にアップロードするというシンプルなワークフローです。
name: Lighthouse Check on Push
on:
push:
branches:
- main
jobs:
lighthouse:
runs-on: ubuntu-latest
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: 'lts/*'
cache: 'npm'
- name: Install dependencies
run: npm install
- name: Run Lighthouse mobile audit
run: npm run lhci:mobile
- name: Upload Lighthouse mobile report artifact
uses: actions/upload-artifact@v4
with:
name: lighthouse-mobile-report
include-hidden-files: true
path: ${{ github.workspace }}/.lighthouseci/lhr-*.html
retention-days: 7
- name: Run Lighthouse desktop audit
run: npm run lhci:desktop
- name: Upload Lighthouse desktop report artifact
uses: actions/upload-artifact@v4
with:
name: lighthouse-desktop-report
include-hidden-files: true
path: ${{ github.workspace }}/.lighthouseci/lhr-*.html
retention-days: 7
このファイルをコミットして main ブランチに push すると、Actions ワークフローが実行されます。
ワークフローが完了すると、Summary ページからモバイルとデスクトップそれぞれのレポートを Artifacts としてダウンロードできます。
また、GithubActions からすぐアクセスできるように mobile / desktop それぞれの実行結果を artifact へ保存することができました。
今回は、Lighthouse CI と GitHub Actions を用いて、Webサイトのパフォーマンス計測を自動化する方法をご紹介しました！
これまで手動で行っていた Lighthouse の計測を CI に組み込むことで、工数をかけることなく、継続的なパフォーマンス監視の仕組みを構築できました！
もちろんアプリケーションの規模によって実行時間は変動しますが、開発プロセスの早い段階でパフォーマンスの劣化を検知できる強力な仕組みです！
本記事が、皆さんの開発フローを改善する一助となれば幸いです。
また、別の機会に、計測結果の差分を検知して Pull Request にコメントを自動投稿する方法などもご紹介できればと思います！
最後までお読みいただき、ありがとうございました！
