Lighthouse CIとGitHub Actionsで「激重」コードを阻止する – ITFROMZERO

Table of Contents

実話：5万行のコードベースと、止まらないパフォーマンススコアの急落

私は以前、5万行を超えるコードを持つECサイトのプロジェクトを管理していました。当初はすべてが順調で、Lighthouseのスコアは常に90点以上を維持していました。しかし、リファクタリングを行い、マーケティングチームからのトラッキングスクリプトをいくつか追加しただけで、パフォーマンススコアは一気に40点まで落ち込んでしまったのです。さらに悲しいことに、Google Search Consoleのキーワード順位もその直後に急降下しました。

当時の私のミスは、「自分のマシンでは速く動いている」という感覚を過信しすぎたことでした。実際、Webのパフォーマンスは数値で定量化される必要があります。ユニットテストを書くのと同じように、CI/CDプロセスの中で継続的にチェックしなければなりません。

Webサイトの速度を密かに低下させる「3つの犯人」

多くのプロジェクトを通じて、スコアが低下する典型的な3つの理由に気づきました：

肥大化したライブラリ: ある開発者が、日付のフォーマットを1行書くためだけに、うっかり Moment.js（約280KB）をインストールしてしまいました。dayjs ならわずか2KBで済むところでした。
未処理の画像: コンテンツチームが、200KBのWebP形式ではなく、5MBのバナー画像をそのままCMSにアップロードしてしまいました。
レンダリングをブロックするスクリプト: トラッキングコードの配置場所を誤ったため、ブラウザが最初のフレームを表示するまでに余計に2〜3秒かかってしまいました。

Chrome DevToolsで手動のLighthouseを使っているだけでは、ミスを見逃しがちです。チーム開発では、誰かが意図せずCore Web Vitalsを損なうコードをコミットしてしまうことは、日常茶飯事です。

なぜLighthouse CI (LHCI) が「最適解」なのか？

LHCIを採用する前にいくつかの方法を試しましたが、どれも欠点がありました：

手動チェック: Chromeを開いてレポートを生成する。非常に時間がかかり、忘れがちです。
PageSpeed Insights APIの使用: 定期的にスキャンするスクリプトを書く。しかし、これはコードが本番環境（Production）にデプロイされた後にしか報告されません。これでは「泥棒を見て縄をなう」状態です。
Lighthouse CI: これは能動的な解決策です。プルリクエスト（Pull Request）の段階で、質の低いコードを門前払いします。最低スコアに達しない場合、GitHubはコードのマージを許可しません。

GitHub ActionsにLHCIを統合する手順

始めるには、GitHubにプッシュされたWebプロジェクトが必要です。この手順は、React、Next.js、Vue、あるいは静的なHTMLサイトでも適用可能です。

ステップ1：CLIのインストール

まずはローカル環境でテストするために、LighthouseのCLIパッケージをプロジェクトにインストールします。

npm install -g @lhci/[email protected]

ステップ2：lighthouserc.jsで「ルール」を設定する

ルートディレクトリに lighthouserc.js ファイルを作成します。ここで、新しいコードがクリアすべき基準を定義します。

module.exports = {
  ci: {
    collect: {
      numberOfRuns: 3, // 誤差を避けるため、3回実行して平均値を取得
      staticDistDir: './dist', 
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', { minScore: 0.9 }], 
        'categories:accessibility': ['error', { minScore: 0.8 }], 
        'categories:best-practices': ['error', { minScore: 0.9 }],
        'categories:seo': ['error', { minScore: 0.9 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }], // レイアウトシフト（ガタつき）を阻止
      },
    },
    upload: {
      target: 'temporary-public-storage', 
    },
  },
};

ステップ3：GitHub Actionsで自動化する

.github/workflows/lighthouse.yml ファイルを作成します。誰かがコードをプッシュするたびに、GitHubが自動的にこのスクリプトを実行します。

name: Lighthouse CI
on: [push, pull_request]
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install && npm run build
      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/[email protected]
          lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

実践的なアドバイス：100点という数字にこだわりすぎない

導入したばかりの頃は、満点に執着しがちです。しかし実際には、GitHubのCIサーバー（通常はUbuntu）は個人のマシンよりもスペックが低いことが多いです。そのため、CI上のスコアは通常5〜10点ほど低くなります。

100点を目指す代わりに、安定性に注目しましょう。プロジェクトの平均スコアが85点なら、しきい値（assertion）を80点に設定します。もしコミットによってスコアが60点まで下がれば、システムが即座に「警告」を発します。それは、新しく追加された2MBのPNG画像や、メインスレッドをブロックしている謎のスクリプトが原因かもしれません。

結論

Lighthouse CIの設定には20分ほどしかかかりませんが、得られるメリットは長期的です。それは、ユーザー体験が時間の経過とともに劣化しないように見守ってくれる、勤勉な門番のようなものです。SEOの順位が落ちるまで最適化を待つ必要はありません。今すぐLHCIを統合して、マージボタンを押した後に安心して眠れるようにしましょう。