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

はじめに

この記事は以下のような方に読まれることを想定しています。

• Webアプリケーションのパフォーマンス改善に関心がある方
• 手動での Lighthouse を利用した計測から、より継続的・体系的な計測へ移行を検討している方

CI/CDパイプラインに本格導入する前の段階にフォーカスして、「どのような工夫で導入ハードルを下げたのか」「実際にテストしてどう変わったのか」など実体験に基づく内容を共有したいと思います。

この記事でやらないこと

• Lighthouse CI の基本的なセットアップ手順の解説

導入のきっかけ

私たちの開発している、キャッシュレス決済サービス「誰でも決済」は、SPA として開発しています。

SPA はページ遷移時の読み込み待機がなく、スムーズな操作感を実現できます。
一方で、開発初期からリソースの読み込み速度の課題が発生するだろうと懸念していました。

機能を追加し、サービスが成長するにつれて、JavaScript のバンドルサイズは肥大化していきます。
これが初回読み込み速度や操作可能になるまでの時間（TTI: Time to Interactive）に影響し、ユーザー体験を損なう大きな原因になることを見越していました。

そこで私たちは、問題が顕在化してから対応するのではなく、問題が発生する前に継続的に手を打っていく 「予防的なアプローチ」 を開発チームの方針として掲げることにしました。

このアプローチには、主に2つのメリットがあると考えています。

ユーザー体験への影響を最小限に抑制

パフォーマンスの悪化という問題が発生する前に対処することで、ユーザーがサイトの重さなどを感じる機会そのものをなくします。

開発・実装コストの抑制

パフォーマンス問題は、後から修正しようとすると、複雑に絡み合ったコードを解きほぐす大規模なリファクタリングが必要になるケースもあり得ます。
小さなうちに摘んでおくことで、結果的に対応コストを低く抑えられるのではと考えました。

ただ、この「予防的なアプローチ」をチームで実践していく上で、従来のやり方には問題がありました。

• 手動計測の限界
  • Chrome DevTools に同梱されている Lighthouse を使った手動計測では、計測者やタイミングによって結果にばらつきが生じてしまい、継続的な観測には不向き
• 改善効果の見えにくさ
  • 個別の改善施策を実装した際に、どれだけ効果があったのか定量的に把握しづらい

こうした課題を解決するための第一歩として、Lighthouse CI の導入を決めました。

本格的な CI/CDパイプラインへの組み込みは次のステップとし、まずはローカル環境でのテスト運用から始めることにしました。

なぜテスト運用から始めたのか

Lighthouse CI は本来 CI/CDパイプラインでの実行を想定したツールですが、私たちはあえて テスト運用（ローカル環境での検証） から始めることにしました。

その理由は以下の通りです。

導入ハードルの最小化

CI/CDパイプラインに組み込む場合、以下のような準備が必要になります。

• ワークフローの設計・実装
• 失敗時の運用ルール策定
• チーム全体での合意形成・運用体制の構築

これらを一度に進めるとなると、導入までに時間がかかります。

試行錯誤の自由度

ローカル環境であれば、

• 設定ファイルの調整を気軽に試せる
• 計測対象やアサーション（検証ルール）を柔軟に変更できる
• 失敗しても他のメンバーに影響を与えない
• 様々なパターンを短期間で検証できる

開発業務との両立を重視

チーム全員が同時に Lighthouse CI の学習に時間を割くと、本来の機能開発業務に支障をきたす恐れがありました。

そこで、まず一部のメンバーが使い方を習得し、開発リソースに影響を与えないよう配慮した段階的なアプローチを取りました。

テスト運用にあたって決めたこと

チーム内での運用ルール

• 新機能実装後は必ずローカルで Lighthouse CI を実行しレポートを出力する
• スコアが基準を下回った場合は、原因分析と改善案を検討する

アサーションの設定

Lighthouse CI では、パフォーマンスやアクセシビリティなどの品質基準を「アサーション」として定義します。

これにより、単純にスコアを確認するだけでなく、基準を下回った場合にエラーや警告を出力し、品質低下を防ぐことができます。

以下は、今回採用した設定の一部です。

assert: {
    assertions: {
        'first-contentful-paint': [
            'error',
            { minScore: 0.5, level: 'warning' },
            { minScore: 0.9, level: 'error' },
        ],
        'largest-contentful-paint': [
            'error',
            { minScore: 0.5, level: 'warning' },
            { minScore: 0.9, level: 'error' },
        ],
        interactive: [
            'error',
            { minScore: 0.5, level: 'warning' },
            { minScore: 0.9, level: 'error' },
        ],
    },
},

テスト運用で分かったこと・導入後の変化

良かったこと

具体的な会話ができるようになった

これまでは『パフォーマンスは大丈夫そう』という感覚的な判断でしたが、健康診断のように『LCP は2.1秒で目標値内』『CLS は0.05で良好』といった具体的な指標で現在の状態を把握できるようになりました。

改善の方向性が明確になった

Lighthouse のレポートが、具体的な改善項目を提示してくれるため、次に取り組むべきタスクが明確になりました。

改善効果を実感できるようになった

画像最適化やコード分割の効果を、数値として確認できるため、チームのモチベーション向上に繋がりました。

苦労したこと

計測結果のブレ

ローカル環境の特性上、同じページでも実行のたびに結果が変動することがありました。

対策として、複数回実行することで中央値で計測されるようにしました。

開発サーバーでの制約

本番環境と開発環境での差異（minify の有無など）により、実際の改善効果と乖離が生じる場合がありました。

そのため、ローカルで起動した本番相当の環境で検証するようにしました。

本格運用に向けた次のステップ

CI/CDパイプラインへの組み込み

• Pull Request 作成時やマージ時のパフォーマンステストの自動実行
• パフォーマンステストのエラー検知時の Slack への通知

テスト対象ページの拡充

• PV数や滞在時間などからユーザー体験上、重要と考えられるページを選定

おわりに

Lighthouse CI をテスト運用（ローカル環境）から始めることで、導入ハードルを下げながら、チーム全体でパフォーマンス改善に取り組む基盤を構築することができました。
導入からまだ3ヶ月ほどではありますが、パフォーマンス劣化による大きな問題は発生しておらず、「問題が起きる前に対処する」というアプローチが、段階的導入の最初のステップでも十分に機能していると実感しています。

パフォーマンス改善は簡単ではありませんが、継続的な計測と改善のサイクルを回すことで、確実にユーザー体験の向上に繋げることができると思います。

今回いろんなドキュメントを読んでいる中で印象的な言葉がありましたので、こちらを紹介して終わりにしたいと思います。

Performance is a Continuous Journey

...

最後までお読みいただき、ありがとうございました！ 🚢