Lighthouse CI の段階的導入 〜 テスト運用から始めてみる

開発チームは、SPA（シングルページアプリケーション）としてキャッシュレス決済サービス「誰でも決済」を開発していました。 SPAはスムーズな操作感が利点である一方、機能追加に伴いJavaScriptのバンドルサイズが肥大化しやすい特性があります。

このまま開発を進めると、将来的に初回読み込み速度や操作可能になるまでの時間（TTI）が悪化し、ユーザー体験を損なうことへの強い懸念がありました。

問題が顕在化してから大規模なリファクタリングで対応するのではなく、問題が発生する前に継続的に手を打っていく「予防的なアプローチ」をチームの方針として掲げていました。

ツール導入前の課題

「予防的なアプローチ」を実践する上で、以下の課題がありました。

1. 手動計測の限界 Chrome DevToolsのLighthouseを使った手動計測では、計測する人やタイミング、ネットワーク環境によって結果にばらつきが生じ、パフォーマンスの変化を継続的に観測するには不向きでした。
2. 改善効果の見えにくさ 個別のパフォーマンス改善施策（例：画像最適化、コード分割）を実施した際に、その効果がどれだけあったのかを定量的に把握しづらい状況でした。

どのような状態を目指していたか

これらの課題を解決し、以下の状態を目指していました。

1. パフォーマンスの悪化を早期に、かつ自動で検知できる状態。
2. 改善施策の効果を数値で定量的に測定し、継続的な改善サイクルを回せる状態。
3. チーム全体が「パフォーマンスは大丈夫そう」といった感覚的な判断ではなく、具体的な指標に基づいてコミュニケーションが取れる状態。

• WebPageTest
• SaaS型パフォーマンス監視サービス (SpeedCurve, Calibreなど)

導入ハードルの低さ（スモールスタートの可否）

いきなり完璧なCI/CDパイプラインを構築するのではなく、まずはローカル環境で試行錯誤できる手軽さを重視しました。

計測の自動化・継続性

手動計測の課題であった「ばらつき」と「手間」を解消するため、CIプロセスに組み込める（将来的には）ことを重視しました。

コスト

オープンソースであり、追加コストなしで始められる点。

設定の柔軟性

「アサーション」機能により、プロジェクトの品質基準を柔軟に定義し、自動チェックできる点を重視しました。

手動計測の課題を解決する「第一歩」として、Lighthouse CIが最適であると判断しました。

• 手動計測の「ばらつき」や「継続性のなさ」を解消し、継続的な観測を実現できる点
• 既存のLighthouseの知見を活かせ、レポートによって具体的な改善項目が明確になる点
• アサーション（品質基準）機能により、パフォーマンスの低下を自動で検知できる点

改善したかった課題はどれくらい解決されたか

手動計測の課題

「新機能実装後はローカルでLighthouse CIを実行する」というチームルールを設けることで、継続的な計測の第一歩を踏み出せました。

改善効果の見えにくさ

画像最適化やコード分割といった施策の効果を、LCPやバンドルサイズといった具体的な数値として確認できるようになり、課題は解決されました。

どのような成果が得られたか

コミュニケーションの質の向上

「パフォーマンスは大丈夫そう」という感覚的な会話から、「LCPは2.1秒で目標値内」「CLSは0.05で良好」といった、具体的な指標に基づいた会話ができるようになりました。

改善タスクの明確化

Lighthouseレポートが具体的な改善項目（例：「使用されていないJavaScriptの削減」など）を提示してくれるため、次に取り組むべきタスクが明確になりました。

チームのモチベーション向上

自分たちの施策が数値として改善に繋がることを実感できるようになり、チームのモチベーションが向上しました。

問題の予防

導入から3ヶ月間、パフォーマンス劣化による大きな問題は発生しておらず、「問題が起きる前に対処する」アプローチが機能していると実感できています。

計測結果のブレ

ローカル環境で実行するため、マシンスペックや他の起動中プロセスによって、実行のたびに計測結果が変動することがありました。

対策：複数回実行し、中央値で計測するようにしました。

開発サーバーでの制約

開発環境（devサーバー）では、コードがminify（圧縮）されていなかったり、本番環境と差があるため、計測結果が実際の改善効果と乖離することがありました。

対策：ローカルで本番相当のビルド（build & start）を実行し、その環境に対して検証するようにしました。

• Webアプリケーションのパフォーマンス改善に関心があるが、手動計測の限界を感じている方に強くおすすめします。

• いきなりCI/CDパイプラインへの本格導入を目指すと、ワークフローの設計や運用体制の構築などでハードルが高く感じるかもしれません。

• この記事のように、まずは「ローカル環境でのテスト運用」からスモールスタートすることで、導入ハードルを下げつつ、チームでパフォーマンス改善に取り組む基盤を構築できます。

1. CI/CDパイプラインへの組み込み Pull Request作成時やmainブランチへのマージ時に、パフォーマンステストを自動実行する仕組みを構築します。

2. 通知の仕組み パフォーマンステストでアサーションエラーが検知された場合、Slackなどへ自動で通知する仕組みを導入します。

3. テスト対象ページの拡充 現在は特定のページのみを対象としていますが、今後はPV数や滞在時間などからユーザー体験上、重要と考えられるページを選定し、テスト対象を拡充していきます。