Lighthouse CI x GitHub Actions × Google Sheetsで構築するパフォーマンス監視基盤

はじめに

Web サイトのパフォーマンスは、SEO 評価とユーザー体験の両面でビジネスインパクトに直結する重要な指標です。
本番環境におけるパフォーマンス測定は、PageSpeed Insights を用いて行えていましたが、PR 単位でのパフォーマンス測定を行えていませんでした。
そこで、Lighthouse CI を用いて PR 単位でのパフォーマンス測定の自動化を実装しました。

本記事では、実際の実装例を交えて、Lighthouse CI 運用のアーキテクチャなどをご紹介します。
少しでも参考になれば幸いです。

Lighthouse CI とは

そもそも Lighthouse CI とは、Web アプリケーションのパフォーマンス測定を自動化し、CI/CD パイプラインに組み込むことで、継続的なパフォーマンス監視を実現するツールです。

従来の手動でのパフォーマンス測定に対し、Lighthouse CI は下記のメリットがあります。

• 自動化
  • PR ごとなど、定期実行によるパフォーマンス測定の自動化
• 可視化
  • レポート生成とチームへの通知による問題の早期発見
• 継続性
  • 長期的なパフォーマンス推移の追跡とデータ蓄積

また、「開発者ツールを立ち上げて...lighthouse タブを開いて...Desktop か Mobile か選んで...」という手間が省けるため、効率的にパフォマンス測定を行えるメリットがあります。

以前、Lighthouse CI について詳細に紹介した記事を書いたので、よければご参考ください。

自動化の概要

Lighthouse CI の実行タイミングは下記にしています。

• PR をオープンもしくは作成したタイミング
  • PR のブランチ上で Lighthouse CI 実行
• /lighthouse checkをコメントしたタイミング
  • PR のブランチ上で Lighthouse CI 実行
• 平日毎日 10:00 の定期実行タイミング
  • デフォルトブランチ上で Lighthouse CI 実行

この仕組みにより、各 PR での変更がパフォーマンスに与える影響をデフォルトブランチとの比較で定量的に把握できます。

PR ごとで Lighthouse の実行結果を確認することができるため、パフォーマンス悪化となりうる修正を早期に検知することができるようになります。

アーキテクチャ概要

アーキテクチャの概要になります。
GitHub Actions、Google Sheets、モック API サーバーを組み合わせた Lighthouse CI 環境を構築しています。

余談ですが、ソースコードベースで Claude Code に markdown でアーキテクチャを出力してもらいました。
1 から markdown を書いて...修正して...という手間がなくなったので、とても便利でした。

主要コンポーネント

1. CI/CDパイプライン

• GitHub Actions Workflow
  • 3つのトリガー（PR、コメント、スケジュール）に対応
• カスタムアクション
  • setup、run、cleanupの3段階でモジュール化
    • setup は、モックサーバー用のモックデータ作成
    • cleanup は、モックサーバー用のモックデータ削除
    • run は、Lighthouse CI の実行とレポート作成
  • 計測結果の保存
    • Lighthouse の実行結果は GitHub Artifacts に保存

2. 測定環境

• モックAPI サーバー
  • テスト用データの安定供給
  • 「開発環境では、IP アドレス制限をしていたこと & フロント特化のパフォーマンス測定が目的」だったため、モック API サーバーを採用
• デバイス別測定
  • モバイルとデスクトップの両方に対応

3. データフロー

基本的には、下記のフローとなります。

測定実行 → 結果解析 → レポート生成 → 保存・通知

通知については、スケジュール実行（デフォルトブランチ上での Lighthouse 測定）の結果と PR 上での実行結果との差分を PR にコメントするようにしています。

実装のポイント

監視対象の Lighthouse 結果の選定

Lighthouse のデメリットとして、実行タイミングによって数値が変動します。
そのため 1 回の Lighthouse 実行結果を正のパフォーマンスとすることは難しいです。

そこで、Lighthouse CI の複数実行と中央値のファイルを明示してくれる機能を使用します。
下記は、実際の Lighthouse CI の設定ファイル（.yml）を元に簡易化したものです。

ci:
  collect:
    startServerCommand: yarn build && yarn start
    url:
      - http://0.0.0.0:xxxx/
    numberOfRuns: 10
    startServerReadyPattern: 'Listening on'
  upload:
    target: filesystem

• numberOfRuns で Lighthouse の実行回数を設定することができます
• target を filesystem で設定することで、Lighthouse 実行結果の HTML / JSON ファイルをローカルディレクトリに保存することができます
  • また、保存の際に manifest.json という JSON ファイルが生成されて、中央値となる HTML / JSON ファイルを指定してくれます

この機能を活かすことで、数値にブレがあったとしても複数回 Lighthouse を実行した後の比較的安定した中央値となりうる結果を取得することができます。

閾値の設定

複数回実行したとはいえ、パフォーマンスメトリクスなどはどうしても数値の差分が出ます。
例えば、FCP において毎回 1ms の違いも出ないわけではありません。
また、desktop での実行は、比較的数値は安定しますが、mobile での実行時は、数値がより不安定になります。

mobile 実行時に適応される詳細部分については、下記の ドキュメントをご参考ください。

そのため、カテゴリスコアやパフォーマンスメトリクスそれぞれに閾値を設定しています。
例えば、FCP（First Contentful Paint：最初のコンテンツが描画されるまでの時間）において、基準値よりも 100ms 以上遅延した場合は、警告を表示するようなものです。

また、mobile の数値不安定問題については、Lighthouse 実行回数を増やすことで比較的数値を安定させるように対策をしています。
ただ、今後も数値にブレが多く生じる場合は、desktop と mobile で別々の閾値を設定すると言った対応を行おうと思います。

Google Sheets の DB 化

今回、Lighthouse スケジュール実行結果は、毎日平日に Google Sheets に格納するようにしています。
理由は、いくつかありますが、大きく以下の 2 点です。

• コストをかけたくなかったため
  • Lighthouse CI の機能としてカスタムサーバー経由で実行結果を保存する機能がありますが、インフラコスト等少なからず一定のコストがかかってしまいます
  • そのため、コストがかからず比較的導入が容易な Google Sheets を採用しました
• 非エンジニアへの共有
  • 先述した通り、SEO 対策といった目的も兼ねているため、そのステークホルダーに日々の開発環境下でのパフォーマンス測定結果を共有する場面があるかもしれません
  • その場合は、Google Sheets であれば比較的簡単に共有することができ、Looker Studio といった見やすく整形できるツールもあるため、今回は Google Sheets を採択しました
    • もちろん、BigQuery などに保存することも選択肢の 1 つだとは思いますが、今回は諸々の理由から対応を見送りました

結果

結論としては、以下です。

• 測定工数：10 ~ 20分/画面 → 0分（完全自動化）
  • コードメンテナンスコストは除く
• 測定頻度：PJ レベルの成果物が出来上がった任意のタイミング → PR単位

導入して間もないため、閾値等の設定は現在も調整中ではあります。
しかし、今まで 1 画面の Lighthouse 計測にかかる時間においては

1. Lighthouse 結果記録用のドキュメントとファイル用意
2. 開発環境の立ち上げ
3. 対象の画面に移動（開発者ツール表示）
4. desktop の Lighthouse の実行(複数回)
5. 平均値をドキュメントに記録
6. 結果レポートをファイルに保存
7. mobile の Lighthouse の実行(複数回)
8. 平均値をドキュメントに記録
9. 結果レポートをファイルに保存
10. パフォーマンス結果の確認

といったフローを 1 人のエンジニアの工数を割いて実行していました。
「Lighthouse 結果記録用のドキュメントとファイル用意」から実施する場合は、1 つの画面で 20 分以上時間がかかることもありました。

それを今回の Lighthouse CI の導入によって
PR 単位で Lighthouse 計測をすることができ、何より人の工数をかけずに自動で計測をすることができるため、人の工数という観点では、ほぼ 0 コストでパフォーマンス計測を行えるようになりました。
※ もちろん API に変更が入った場合は、微々たるものですがメンテナンスコストはかかります

今後

現状の成果としては、工数削減といった限定的なものにはなっています。
しかし、今後運用を進めていくことで、
潜在的なパフォーマンス問題を事前検知することができ、日々の小さい単位でのリリース物に対してもパフォーマンス測定を実施できるようになるため、より良いユーザー体験の提供並びに SEO 評価に繋がるのではないかと考えています。

まとめ

Lighthouse CI の導入により、パフォーマンス測定を「手動の負担」から「自動化」へと転換することができました。
PR 単位での継続的な監視は、パフォーマンス劣化を未然に防ぎ、結果としてユーザー体験の向上と SEO 評価の改善に直結します。

本記事で紹介したアーキテクチャは、GitHub Actions と Google Sheets を活用することで
インフラコストを最小限に抑えながら実現可能です。

少しでも参考になれば幸いです。