【ITニュース解説】Lighthouse CI x GitHub Actions × Google Sheetsで構築するパフォーマンス監視基盤

Webサイトのパフォーマンスは、ビジネスにおいて非常に重要な要素である。具体的には、サイトの表示速度が速いと、検索エンジンでの評価が向上し、より多くのユーザーがサイトを見つけやすくなる。さらに、ユーザーが快適にサイトを利用できるため、途中でサイトから離れてしまうことを防ぎ、結果として商品の購入や情報の閲覧といったビジネス目標の達成につながる。このように、パフォーマンスはユーザー体験（UX）と直接結びつき、ビジネスの成功に大きく貢献する指標だ。

これまで、Webサイトのパフォーマンス測定は、Googleが提供するPageSpeed Insightsのようなツールを使って、主に実際にユーザーがアクセスする公開済みのサイト、つまり本番環境に対して行われていた。しかし、これだけでは開発の途中でパフォーマンスが悪化するような変更が加えられた場合に、それを早期に発見することが難しいという課題があった。例えば、新しい機能を追加するためにコードを変更した際、その変更が原因でサイトの表示が遅くなることがある。このような問題が本番環境にデプロイされて初めて気づくのでは、修正に時間と手間がかかり、ユーザーへの影響も大きくなってしまう。

この課題を解決するために、開発の初期段階、具体的には「プルリクエスト（PR）」の段階でパフォーマンスを測定する仕組みが求められていた。プルリクエストとは、開発者が自分のコード変更をメインのコードに統合してほしいとチームに依頼する際に使う仕組みだ。このPRの段階でパフォーマンスをチェックできれば、問題のある変更が本番環境に入る前に食い止めることができる。

この記事では、Lighthouse CI、GitHub Actions、そしてGoogle Sheetsという三つのツールを組み合わせて、このようなプルリクエスト単位でのパフォーマンス監視基盤を構築する方法について解説している。

まず、Lighthouse CIについて説明する。Lighthouseは、Googleが開発したオープンソースの自動化ツールで、Webページの品質（パフォーマンス、アクセシビリティ、SEOなど）を診断し、改善点を提案してくれる。Lighthouse CIは、このLighthouseを継続的インテグレーション（CI）環境で実行するためのツールだ。CI環境とは、開発者がコードを更新するたびに自動的にテストやビルドを行う環境のこと。Lighthouse CIを使うことで、特定のコード変更がWebサイトのパフォーマンスにどのような影響を与えるかを自動的に計測し、その結果を数値やレポートとして確認できるようになる。開発者は、自分のプルリクエストがパフォーマンスを悪化させていないかを、本番環境にデプロイする前に確認できるわけだ。

次に、GitHub Actionsの役割だ。GitHub Actionsは、GitHub上でコードのビルド、テスト、デプロイといった開発ワークフローを自動化するための機能である。特定のイベント（例えば、プルリクエストが作成された時やコードがリポジトリにプッシュされた時など）をトリガーとして、あらかじめ定義しておいた一連の処理を自動で実行してくれる。この記事の監視基盤では、開発者がプルリクエストを作成したり更新したりするたびに、GitHub Actionsが自動的にLighthouse CIを実行するよう設定する。これにより、手動で計測する手間を省き、常に最新の変更に対するパフォーマンスデータを取得できるようになる。

そして、Google Sheetsが登場する。Lighthouse CIが計測したパフォーマンスデータは、そのままでは一時的なものであり、過去のデータと比較したり、チームメンバーと共有したりするためには、どこかに永続的に保存し、見やすい形で可視化する必要がある。そこで、この記事ではGoogle Sheetsを簡易的なデータベースとして活用している。GitHub ActionsがLighthouse CIを実行した後、その結果（例えば、パフォーマンススコアや各指標の値）をGoogle Sheetsに自動的に書き込むように設定する。Google Sheetsは、表計算ソフトとして非常に馴染み深く、URLを知っている人なら誰でも簡単にアクセスしてデータを確認できる。また、グラフ機能を使えば、パフォーマンスの傾向を視覚的に把握することも容易だ。このように、複雑なデータベースシステムを構築することなく、手軽に測定結果を記録・共有できる点が利点となる。

この三つのツールが連携することで、以下のような一連の自動化されたフローが実現する。まず、開発者がWebサイトのコードを変更し、GitHubにプルリクエストを作成または更新する。次に、GitHub Actionsがこのプルリクエストのイベントを検知し、定義されたワークフローを開始する。ワークフローの中で、Lighthouse CIが実行され、プルリクエストによって変更されたWebサイトのバージョンに対してパフォーマンス計測を行う。Lighthouse CIによる計測結果は、GitHub Actionsを通じてGoogle Sheetsに自動的に記録される。この際、プルリクエスト番号、変更されたURL、各パフォーマンス指標のスコアなどが追記される。さらに、測定結果が悪かった場合や、特定の基準値から外れた場合には、Slackなどのコミュニケーションツールに自動的に通知を送ることも可能だ。これにより、開発チームはパフォーマンスの低下にすぐに気づき、対応できるようになる。

このようなパフォーマンス監視基盤を構築することには、多くのメリットがある。まず、パフォーマンス悪化の早期発見と防止だ。本番環境にデプロイされる前にパフォーマンスの問題を発見できるため、修正にかかる時間とコストを抑えられる。次に、開発プロセスの透明性の向上だ。プルリクエストごとにパフォーマンスデータが記録されることで、どの変更がパフォーマンスに影響を与えたのかが明確になり、チーム全体でパフォーマンスに対する意識を高めることができる。また、Google Sheetsでデータが共有されるため、誰でも簡単に現状を把握できる。最後に、継続的な改善の促進だ。定期的にパフォーマンスを計測し、その履歴を追うことで、サイト全体のパフォーマンス傾向を把握し、長期的な改善計画を立てる上での貴重なデータとなる。

この監視基盤は、特別なサーバーを準備することなく、既存のGitHub環境とGoogleアカウントがあれば手軽に導入できる点も魅力的だ。システムエンジニアを目指す初心者にとっても、CI/CD（継続的インテグレーション/継続的デリバリー）の考え方や、自動化の具体的な実現方法を学ぶ上で非常に良い題材となるだろう。Webサイトのパフォーマンスは「顔」とも言える重要な要素であり、このような自動監視の仕組みは、安定した高品質なサービスを提供するために不可欠なのだ。