WithCodeMedia-1-pc
previous arrowprevious arrow
next arrownext arrow

WithCodeMedia-1-sp
previous arrowprevious arrow
next arrownext arrow

Lighthouse CIで自動計測を実装|GitHub Actions連携でパフォーマンス監視の自動化方法を解説

生徒

博士、Webサイトのパフォーマンスをチェックするために毎回手動でLighthouseを実行するのが大変なんです。もっと自動化できる方法はないですか?

ペン博士

それなら「Lighthouse CI」を使うんじゃ!GitHubにコードをpushするたびに自動でパフォーマンスをチェックしてくれるんじゃよ。今回はLighthouse CIの導入から、GitHub Actionsとの連携、Core Web Vitalsの自動監視まで、実践的な内容を詳しく解説するぞい!

生徒

ありがとうございます!よろしくお願いします!

Webサイトのパフォーマンス測定において、GoogleのLighthouseは非常に強力なツールです。しかし、手動での計測には以下のような課題があります:

  • 毎回手動で実行する必要があり、時間がかかる
  • 計測を忘れてパフォーマンスが悪化したまま公開してしまう
  • 複数のページを一度に測定するのが困難
  • 過去のスコアとの比較が難しい

本記事では、Lighthouse CIを使ったパフォーマンス自動計測の実装方法について、導入から実践的な活用まで、実例を踏まえて徹底的に解説します。

「学習→案件獲得」につなげた受講生のリアルな体験談も公開中!
働き方を変えたい方にも響くストーリーです。

片山さん
妊娠をきっかけに、子どものためにもどこでも働けるスキルを身に付けたいと考える。そこで、オンラインスクールのfammで1ヶ月間Web制作の勉強を開始。その後、独学で勉強に励むも限界を感じ、案件保証が魅力のWithCodeへ入学し、稼げる力を身に付けることができた。現在は副業として稼ぐ力を身に付け、10件以上の案件を担当するまでに成長した。

詳しくはこちらの記事をご覧ください。

片山さんの主な制作実績はこちら


目次

Lighthouse CIとは?基礎知識を理解する

Lighthouse CIの定義

Lighthouse CI(LHCI)は、GoogleのLighthouseをコマンドラインで実行し、CI/CDパイプラインに組み込むためのツールです。

通常のLighthouseとの違い:

機能通常のLighthouseLighthouse CI
実行方法Chrome DevTools / CLICLI / CI/CD自動実行
実行タイミング手動自動(コミット/PR時)
複数ページ測定1ページずつ手動設定ファイルで一括指定
閾値チェック目視確認自動判定・ビルド失敗
履歴管理なしLighthouse Server / Temporary Public Storage

Lighthouse CIの主な機能

Lighthouse CIは以下の機能を提供します:

  • 自動計測:指定したURLに対して自動でLighthouseを実行
  • 閾値チェック(Assertions):設定した基準を満たさない場合にビルドを失敗させる
  • 複数回実行:計測のばらつきを抑えるため、複数回実行して平均値を算出
  • 結果の保存:計測結果を保存し、過去のスコアと比較
  • レポート生成:HTML形式の詳細レポートを生成

測定される指標

Lighthouse CIでは、以下の指標を自動で測定できます:

1. パフォーマンス

  • LCP(Largest Contentful Paint):最大コンテンツの描画時間
  • FID(First Input Delay):初回入力遅延
  • CLS(Cumulative Layout Shift):累積レイアウトシフト
  • FCP(First Contentful Paint):初回コンテンツ描画
  • SI(Speed Index):表示速度指標
  • TBT(Total Blocking Time):合計ブロッキング時間

2. その他の指標

  • アクセシビリティ:ARIA属性、コントラスト比など
  • ベストプラクティス:セキュリティ、HTTPS使用など
  • SEO:メタタグ、robots.txt、構造化データなど
  • PWA:Service Worker、マニフェストファイルなど

Lighthouse CIを導入するメリット

生徒

Lighthouse CIを導入するメリットって何ですか?

ペン博士

うむ。ここでは、Lighthouse CIを導入するメリットについて解説するぞ!

1. パフォーマンス劣化の早期発見

コードをコミットするたびに自動でチェックされるため、パフォーマンスが悪化した場合にすぐに気づけます。

従来の方法:

  • 新機能を実装
  • 本番環境にデプロイ
  • 数週間後、ユーザーから「遅い」という報告
  • 原因調査に時間がかかる

Lighthouse CI導入後:

  • 新機能を実装してPull Request作成
  • 自動でLighthouse CI実行
  • スコアが基準を下回るとビルド失敗
  • マージ前に問題を修正

2. Core Web Vitalsの継続的監視

GoogleのSEOランキング要因であるCore Web Vitals(LCP、FID、CLS)を常に監視できます。

設定例:

// lighthouserc.json
{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "first-input-delay": ["error", {"maxNumericValue": 100}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}

これにより、SEOに悪影響を与える前に問題を検知できます。

3. チーム全体での品質意識向上

Pull Requestにパフォーマンスレポートが自動で追加されるため、チーム全員がパフォーマンスを意識するようになります。

レビュー時のチェック項目:

  • 「この変更でLCPが500ms悪化していますね。画像最適化が必要です」
  • 「CLSスコアが上昇しています。レイアウトシフトの原因を調査しましょう」
  • 「全指標がグリーンです。マージしましょう」

4. 手作業の削減

手動でLighthouseを実行する必要がなくなり、計測にかかる時間を大幅削減できます。

作業手動Lighthouse CI
1ページの計測約3分自動(0分)
10ページの計測約30分自動(0分)
月間計測回数数回(忘れがち)コミットごと(数十〜数百回)

Lighthouse CIの導入方法【ステップバイステップ】

生徒

メリットは分かったんですけど、実際どうやって導入するんですか?

ペン博士

いい質問じゃ。ここでは、実際にLighthouse CIをプロジェクトに導入する手順を詳しく解説するぞ!

ステップ1:Lighthouse CIのインストール

npmまたはyarnでインストールします。

# npmの場合
npm install -D @lhci/cli
# yarnの場合
yarn add -D @lhci/cli

package.jsonのdevDependenciesに追加されます:

// package.json
{
  "devDependencies": {
    "@lhci/cli": "^0.13.0"
  }
}

ステップ2:設定ファイルの作成

プロジェクトルートにlighthouserc.jsonを作成します。

// lighthouserc.json
{
  "ci": {
    "collect": {
      // 計測回数(複数回実行して平均を取る)
      "numberOfRuns": 3,
      // ビルド後の静的ファイルがあるディレクトリ
      "staticDistDir": "./build",
      // または、開発サーバーを起動する場合
      // "startServerCommand": "npm run start",
      // 計測するURL(複数指定可能)
      "url": [
        "http://localhost:3000/",
        "http://localhost:3000/about",
        "http://localhost:3000/contact"
      ]
    },
    "assert": {
      // スコアやメトリクスの閾値を設定
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "categories:accessibility": ["warn", {"minScore": 0.9}],
        "categories:best-practices": ["warn", {"minScore": 0.9}],
        "categories:seo": ["warn", {"minScore": 0.9}],
        // Core Web Vitals
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "first-input-delay": ["error", {"maxNumericValue": 100}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        // その他のメトリクス
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "speed-index": ["warn", {"maxNumericValue": 3000}],
        "total-blocking-time": ["warn", {"maxNumericValue": 300}]
      }
    },
    "upload": {
      // 結果の保存先(オプション)
      "target": "temporary-public-storage"
    }
  }
}

設定項目の詳細

collect(計測設定):

  • numberOfRuns:実行回数(3〜5回推奨)
  • staticDistDir:静的ファイルのディレクトリ
  • startServerCommand:サーバー起動コマンド
  • url:計測対象のURL配列

assert(閾値設定):

  • ["error", {...}]:基準未達時にビルド失敗
  • ["warn", {...}]:基準未達時に警告のみ
  • minScore:最低スコア(0〜1の範囲)
  • maxNumericValue:最大値(ミリ秒単位)

ステップ3:package.jsonにスクリプト追加

// package.json
{
  "scripts": {
    "build": "next build",
    "lighthouse": "lhci autorun",
    "lighthouse:collect": "lhci collect",
    "lighthouse:assert": "lhci assert",
    "lighthouse:upload": "lhci upload"
  }
}

コマンドの説明:

  • lhci autorun:collect、assert、uploadを一括実行
  • lhci collect:Lighthouseを実行して結果を収集
  • lhci assert:収集した結果を閾値と比較
  • lhci upload:結果をサーバーにアップロード

ステップ4:ローカルでテスト実行

# ビルド
npm run build
# Lighthouse CI実行
npm run lighthouse

実行すると、以下のような出力が表示されます:

Collecting Lighthouse results
Running Lighthouse 3 time(s) on http://localhost:3000/
   Run #1...done.
   Run #2...done.
   Run #3...done.
Done collecting Lighthouse results.
Asserting against Lighthouse results
   ✓ categories:performance: minScore assertion passed
   ✓ largest-contentful-paint: maxNumericValue assertion passed
   ✓ cumulative-layout-shift: maxNumericValue assertion passed
All assertions passed!
Uploading Lighthouse results
   ✓ Uploaded to https://storage.googleapis.com/...

GitHub Actionsとの連携【自動化の実装】

ペン博士

Lighthouse CIの本領は自動化してこそじゃ。特にGitHub Actionsとの相性が良い。ここでは、GitHub Actionsを使って、自動でLighthouse CIを実行する方法を解説するぞ!

生徒

そうなんですね!よろしくお願いします!

基本的なワークフロー設定

.github/workflows/lighthouse-ci.ymlを作成します。

# .github/workflows/lighthouse-ci.yml
name: Lighthouse CI
on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]
jobs:
  lighthouse-ci:
    runs-on: ubuntu-latest
    steps:
      # リポジトリをチェックアウト
      - uses: actions/checkout@v3
      # Node.jsのセットアップ
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'npm'
      # 依存関係のインストール
      - name: Install dependencies
        run: npm ci
      # ビルド
      - name: Build project
        run: npm run build
      # Lighthouse CI実行
      - name: Run Lighthouse CI
        run: npm run lighthouse
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
      # 結果をアーティファクトとして保存
      - name: Upload Lighthouse reports
        uses: actions/upload-artifact@v3
        if: always()
        with:
          name: lighthouse-reports
          path: .lighthouseci/

Pull Requestへのコメント追加

Lighthouse CIの結果をPull Requestにコメントとして追加する設定:

# .github/workflows/lighthouse-ci.yml(続き)
jobs:
  lighthouse-ci:
    # ...(前述の設定)
    steps:
      # ...(前述のステップ)
      # Lighthouse CI実行(コメント機能付き)
      - name: Run Lighthouse CI with comment
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            http://localhost:3000
            http://localhost:3000/about
          uploadArtifacts: true
          temporaryPublicStorage: true
          runs: 3

この設定により、Pull Requestに以下のようなコメントが自動追加されます:

## Lighthouse CI Results
### http://localhost:3000
| Category | Score |
|----------|-------|
| Performance | 95 +2 |
| Accessibility | 100 |
| Best Practices | 92 -3 |
| SEO | 100 |
**Core Web Vitals**
- LCP: 1.8s 
- FID: 15ms 
- CLS: 0.05 
[View full report](https://storage.googleapis.com/...)

複数環境での計測

本番環境、ステージング環境など、複数の環境で計測する設定:

# .github/workflows/lighthouse-ci.yml
name: Lighthouse CI - Multi Environment
on:
  pull_request:
    branches: [main]
jobs:
  lighthouse-ci:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        environment: [staging, production]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - name: Install dependencies
        run: npm ci
      - name: Run Lighthouse CI - ${{ matrix.environment }}
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            ${{ matrix.environment == 'staging' && 'https://staging.example.com' || 'https://example.com' }}
          uploadArtifacts: true
          runs: 3

Core Web Vitalsの自動監視【実践編】

生徒

Lighthouseってスコア見るだけじゃダメなんですか?

ペン博士

それは違うぞ。継続的に監視しないと意味がない。特にCore Web Vitalsは別物と考えた方がいい。ここでは、GoogleのSEOランキング要因であるCore Web Vitalsを継続的に監視する方法を解説するぞ!

Core Web Vitalsとは?

Core Web Vitalsは、ユーザーエクスペリエンスを測定する3つの指標です:

1. LCP(Largest Contentful Paint)

意味: ページの主要コンテンツが表示されるまでの時間

良好な値: 2.5秒以内

改善方法:

  • 画像最適化(WebP、AVIF)
  • サーバー応答時間の短縮
  • CSSとJavaScriptの最適化
  • CDNの使用

2. FID(First Input Delay)

意味: ユーザーが最初にページを操作してから、ブラウザが応答するまでの時間

良好な値: 100ミリ秒以内

改善方法:

  • JavaScriptの実行時間削減
  • コード分割
  • Web Workerの使用
  • サードパーティスクリプトの削減

3. CLS(Cumulative Layout Shift)

意味: ページ読み込み中のレイアウトのずれ

良好な値: 0.1以下

改善方法:

  • 画像・動画に明示的なサイズ指定
  • フォントの読み込み最適化
  • 動的コンテンツの事前スペース確保
  • 広告サイズの固定

厳格なCore Web Vitals設定例

// lighthouserc.json
{
  "ci": {
    "assert": {
      "preset": "lighthouse:no-pwa",
      "assertions": {
        // Core Web Vitals(厳格)
        "largest-contentful-paint": [
          "error",
          {"maxNumericValue": 2000, "aggregationMethod": "optimistic"}
        ],
        "first-input-delay": [
          "error",
          {"maxNumericValue": 80}
        ],
        "cumulative-layout-shift": [
          "error",
          {"maxNumericValue": 0.08}
        ],
        // 追加のパフォーマンス指標
        "first-contentful-paint": [
          "warn",
          {"maxNumericValue": 1500}
        ],
        "speed-index": [
          "warn",
          {"maxNumericValue": 2500}
        ],
        "total-blocking-time": [
          "error",
          {"maxNumericValue": 200}
        ],
        "interactive": [
          "warn",
          {"maxNumericValue": 3500}
        ],
        // リソースサイズ
        "resource-summary:script:size": [
          "warn",
          {"maxNumericValue": 300000}
        ],
        "resource-summary:stylesheet:size": [
          "warn",
          {"maxNumericValue": 50000}
        ],
        "resource-summary:image:size": [
          "warn",
          {"maxNumericValue": 500000}
        ],
        // カテゴリースコア
        "categories:performance": ["error", {"minScore": 0.95}],
        "categories:accessibility": ["warn", {"minScore": 0.95}],
        "categories:best-practices": ["warn", {"minScore": 0.9}],
        "categories:seo": ["error", {"minScore": 0.95}]
      }
    }
  }
}

スコア悪化時の自動通知

Slackに通知を送る設定:

# .github/workflows/lighthouse-ci.yml
jobs:
  lighthouse-ci:
    steps:
      # ...(前述のステップ)
      - name: Run Lighthouse CI
        id: lighthouse
        continue-on-error: true
        run: npm run lighthouse
      # 失敗時にSlack通知
      - name: Notify Slack on failure
        if: steps.lighthouse.outcome == 'failure'
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {
              "text": "Lighthouse CI Failed",
              "blocks": [
                {
                  "type": "section",
                  "text": {
                    "type": "mrkdwn",
                    "text": "*Lighthouse CI failed on PR #${{ github.event.number }}*\n\nCore Web Vitals did not meet the threshold.\n\n<${{ github.event.pull_request.html_url }}|View Pull Request>"
                  }
                }
              ]
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

よくあるトラブルシューティング

生徒

Lighthouse CI運用するにあたってトラブルシューティングのことも知りたいです!

ペン博士

うむ。ここでは、主なトラブルシューティングを3つ紹介するぞい!

問題1:スコアが毎回大きく変動する

症状: 同じページなのに、実行するたびにスコアが大きく変わる

原因:

  • 実行回数が少ない(1回のみ)
  • ネットワーク環境の不安定さ
  • 外部リソースの読み込み遅延

解決策:

// lighthouserc.json
{
  "ci": {
    "collect": {
      // 実行回数を増やす(3〜5回推奨)
      "numberOfRuns": 5,
      // 集計方法を指定
      "settings": {
        // ネットワークスロットリングを有効化
        "throttlingMethod": "simulate",
        "throttling": {
          "rttMs": 40,
          "throughputKbps": 10240,
          "cpuSlowdownMultiplier": 1
        }
      }
    },
    "assert": {
      "assertions": {
        // 楽観的な値(最良の実行結果)を使用
        "largest-contentful-paint": [
          "error",
          {
            "maxNumericValue": 2500,
            "aggregationMethod": "optimistic"
          }
        ]
      }
    }
  }
}

問題2:GitHub Actionsでタイムアウトする

症状: Lighthouse CI実行中にGitHub Actionsがタイムアウト

解決策:

# .github/workflows/lighthouse-ci.yml
jobs:
  lighthouse-ci:
    # タイムアウトを延長
    timeout-minutes: 30
    steps:
      # キャッシュを活用して高速化
      - name: Cache dependencies
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      # ビルドキャッシュも活用
      - name: Cache build
        uses: actions/cache@v3
        with:
          path: .next/cache
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}

問題3:本番環境とスコアが大きく異なる

症状: ローカル/CIのスコアは良好だが、本番環境のスコアが低い

原因:

  • CDNや外部リソースの影響
  • サードパーティスクリプト(広告、アナリティクスなど)
  • サーバーのレスポンス時間

解決策:

// lighthouserc.json
{
  "ci": {
    "collect": {
      // 本番環境のURLで計測
      "url": [
        "https://example.com",
        "https://example.com/about"
      ],
      // 本番環境と同じヘッダーを送信
      "settings": {
        "extraHeaders": {
          "Cookie": "session=...",
          "Authorization": "Bearer ..."
        }
      }
    }
  }
}

また、本番環境専用のワークフローを作成:

# .github/workflows/lighthouse-production.yml
name: Lighthouse CI - Production
on:
  schedule:
    # 毎日午前3時に実行
    - cron: '0 3 * * *'
  workflow_dispatch:
jobs:
  lighthouse-production:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Lighthouse on production
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            https://example.com
            https://example.com/about
            https://example.com/products
          uploadArtifacts: true
          runs: 5
生徒

Lighthouse CIを使えば、パフォーマンスを常に監視できるんですね!これならユーザーに快適なサイトを提供し続けられます。

ペン博士

その通りじゃ!一度設定すれば、あとは自動で監視してくれるから、パフォーマンスの劣化に気づけるんじゃ。SEOにも良い影響があるぞい!

生徒

早速試してみます!ありがとうございました!


まとめ

本記事では、Lighthouse CIを使ったパフォーマンス自動計測の実装方法について、実践的な内容を解説しました。

重要なポイントは以下の通りです。

Lighthouse CIとは:Lighthouseをコマンドラインで実行し、CI/CDに組み込めるツール
導入のメリット
:パフォーマンス劣化の早期発見、Core Web Vitalsの継続監視、チーム全体での品質向上
導入方法
:npm install、lighthouserc.json作成、package.jsonにスクリプト追加
GitHub Actions連携
:Pull Request時に自動実行、結果をコメントで共有
Core Web Vitals監視
:LCP、FID、CLSの閾値設定で自動判定
・トラブルシューティング
:スコアの変動対策、タイムアウト対応、本番環境との差異解消

Lighthouse CIを導入することで、パフォーマンスを継続的に監視し、ユーザーエクスペリエンスを常に高く保つことができます

まずは小規模なプロジェクトから始めて、lighthouserc.jsonの基本設定を試してみましょう。慣れてきたら、GitHub Actionsとの連携や、より厳格な閾値設定にチャレンジしてください。


WithCodeを体験できる初級コース公開中!

初級コース(¥49,800)が完全無料に!

  • 期間:1週間
  • 学習内容: ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成 → 正しい学習方法で「確かな成長」を実感できるカリキュラム

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか?

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください!

この記事を書いた人

WithCode(ウィズコード)は「目指すなら稼げる人材」をビジョンに、累計400名以上のフリーランスを輩出してきた超実践型プログラミングスクールです。150社以上の実案件支援を特徴にWeb制作・Webデザインなどの役立つ情報を現場のノウハウに基づいて発信していきます。

– service –WithCodeの運営サービス

  • WithCode
    - ウィズコード -

    スクール

    「未経験」から
    現場で通用する
    スキルを身に付けよう!

    詳細はこちら
  • WithFree
    - ウィズフリ -

    実案件サポート

    制作会社のサポート下で
    実務経験を積んでいこう!

    詳細はこちら
  • WithCareer
    - ウィズキャリ -

    就転職サポート

    大手エージェントのサポート下で
    キャリアアップを目指そう!

    詳細はこちら

公式サイト より
今すぐ
無料カウンセリング
予約!

目次