WordPressのLighthouseをCI/CDに組み込む自動化設定（Lighthouse CI＋GitHub Actions）

Chrome DevTools の Lighthouse パネルで手作業で測っている計測は、Lighthouse CI（@lhci/cli）を使うとプルリクエストごとに自動で実行できます。この記事では、WordPress のテーマやプラグインのリポジトリに Lighthouse CI を組み込み、GitHub Actions 上で WordPress を起動して計測し、性能やアクセシビリティが基準を下回ったら知らせる仕組みを作ります。

Lighthouse を CI で回す意味と限界

DevTools の Lighthouse は手元のブラウザで1回測るだけなので、拡張機能や回線状態の影響を受け、結果が毎回ぶれます。また「測り忘れ」が起きやすく、重い画像やレンダリングを妨げるスクリプトが入ったことに公開後まで気づかないことがあります。CI に組み込むと、同じ条件で毎回測り、前回より悪くなった変更をマージ前に見つけられます。

一方で、Lighthouse はラボデータ（決めた条件での模擬計測）です。実際の訪問者の体験を集めたフィールドデータ（Chrome UX Report や Search Console の Core Web Vitals レポート）とは一致しません。特に INP（Interaction to Next Paint）は操作を伴う指標なので、Lighthouse の通常の計測では測れず、TBT（Total Blocking Time）を目安として見ることになります。CI のスコアは「劣化を防ぐ見張り役」と考え、検索順位の改善を約束するものではない点を押さえておきます。

全体の構成

構成は次の3つです。

• 計測対象の WordPress: CI 上で @wordpress/env（wp-env、Docker で WordPress を起動する公式ツール）を使って立ち上げる。既存のステージング環境の URL を測る方法もある
• Lighthouse CI: lhci autorun が「計測（collect）→判定（assert）→結果の保存（upload）」をまとめて実行する
• GitHub Actions: プルリクエストのたびに上の2つを順に動かす

本番サイトを CI から直接測るのは避けます。計測のたびに負荷がかかるうえ、キャッシュの状態で結果が変わり、変更前後の比較になりません。

手順1：計測用の WordPress を用意する

テーマのリポジトリ直下に .wp-env.json を置くと、wp-env がそのテーマを読み込んだ WordPress を起動します。既定では http://localhost:8888 で開きます。

{
  "core": null,
  "themes": [ "." ],
  "plugins": []
}

"core": null は最新の安定版 WordPress を使う指定です。本番と同じバージョンで測りたい場合は、wp-env のドキュメントに従ってバージョンを固定します。

起動直後の WordPress は投稿がほぼ空なので、トップページだけ測っても実態とかけ離れます。画像や長文を含むテスト用コンテンツを WXR ファイルで用意し、WP-CLI でインポートしておくと、実際の記事ページに近い条件になります。wp-env では wp-env run cli wp ... の形で WP-CLI を実行できます（古い wp-env では wp を省いた書き方だった時期があるため、エラーになったら手元のバージョンのヘルプを確認してください）。

手順2：lighthouserc.js で計測と判定の基準を決める

リポジトリ直下に lighthouserc.js を作ります。

module.exports = {
  ci: {
    collect: {
      url: [
        'http://localhost:8888/',
        'http://localhost:8888/?p=1',
      ],
      numberOfRuns: 3,
      settings: {
        preset: 'desktop',
      },
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', { minScore: 0.8 }],
        'categories:accessibility': ['error', { minScore: 0.9 }],
        'largest-contentful-paint': ['warn', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
      },
    },
    upload: {
      target: 'filesystem',
      outputDir: './lhci-report',
    },
  },
};

設定のポイントは次のとおりです。

• numberOfRuns: 同じ URL を複数回測り、中央値で判定します。1回だけだと CI ランナーの混み具合でスコアが上下し、無関係な変更で失敗が出ます
• preset: 省略するとモバイル相当（低速回線と CPU 制限を模擬）で測ります。モバイルとデスクトップの両方を見たい場合は、設定ファイルを分けて2回実行します
• assertions: warn は警告だけ、error は CI を失敗させます。導入直後から厳しい error を並べると、既存の問題で毎回落ちて誰も見なくなります。最初は現状のスコアより少し下を warn にし、改善が進んだ項目から error に切り替えるのが続けやすい運用です
• upload: filesystem は結果を CI 内のフォルダに保存します。temporary-public-storage を指定すると共有用の URL が発行されますが、レポートが一時的に公開状態になるため、非公開のステージング URL や社内向けの内容を測る場合は使わないでください

Lighthouse のバージョンが上がると、監査項目の名前や分類が変わることがあります。たとえば PWA カテゴリは新しい Lighthouse で廃止されており、lighthouse:recommended のようなプリセットの中身もバージョンで変わります（2026年10月現在）。プリセットに頼りきらず、上のように見たい項目を明示しておくと、更新時の想定外の失敗を減らせます。

手順3：GitHub Actions のワークフローを作る

.github/workflows/lighthouse.yml を作ります。

name: Lighthouse CI

on:
  pull_request:

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install tools
        run: npm install -g @wordpress/env @lhci/cli

      - name: Start WordPress
        run: wp-env start

      - name: Run Lighthouse CI
        run: lhci autorun

      - name: Save report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: lighthouse-report
          path: lhci-report

GitHub がホストする Ubuntu ランナーには Docker と Chrome が入っているため、追加の準備なしで wp-env と Lighthouse CI が動きます。if: always() を付けているのは、判定で失敗したときこそレポートを見たいからです。Actions の画面から成果物（artifact）としてダウンロードし、HTML レポートを開けば DevTools と同じ形式で原因を確認できます。

アクションのメジャーバージョン（@v4 など）や Node.js のバージョンは更新されていくため、導入時点の各リポジトリの案内に合わせてください。プルリクエストにチェック結果を表示したい場合は、Lighthouse CI の GitHub App を導入し、発行されたトークンを LHCI_GITHUB_APP_TOKEN という名前でリポジトリの Secrets に登録して、lhci autorun の env に渡します。トークンをワークフローファイルや設定ファイルに直接書かないでください。

ステージング環境の URL を測る場合

テーマ単体ではなく、プラグイン構成や実データを含むサイト全体を見たい場合は、デプロイ後のステージング URL を collect.url に指定します。このときの注意点は3つです。

1. キャッシュの温め: ページキャッシュがある環境では、1回目だけ遅くなります。numberOfRuns を増やすか、計測前に一度アクセスしておきます
2. アクセス制限: Basic 認証などで保護したステージングは、そのままでは Lighthouse が中身を測れません。IP 制限で CI ランナーを許可するのは IP が固定されないため難しく、認証ヘッダーを渡す設定を使うことになります。認証情報は Secrets に置き、ログに出力しないようにします
3. ログイン状態: 管理バーの有無で結果が変わります。訪問者と同じ、ログアウト状態のページを測ります

失敗したときの読み方

CI が失敗したら、まずどの assertion が失敗したかをログで確認し、次に保存したレポートの該当監査を開きます。よくある原因と対処は次のとおりです。

• LCP の悪化: 追加した画像の容量や、LCP 要素になった画像に遅延読み込み（loading="lazy"）が付いていないかを確認します。WordPress はファーストビューの画像を自動判定して lazy を外しますが、テーマ側の独自出力では効かない場合があります
• CLS の悪化: 幅と高さを指定していない画像や広告枠、後から差し込まれるバナーが原因になりがちです
• レンダリングを妨げるリソース: 追加した CSS や JavaScript がページの描画を止めています。スクリプトは wp_enqueue_script() の strategy 引数（WordPress 6.3 以降）で defer や async を指定できます。新しい Lighthouse ではこの監査が「インサイト」としてまとめて表示される場合があります
• スコアだけが不安定: 中身の変更がないのに数値がぶれる場合は、numberOfRuns を増やし、基準値に少し余裕を持たせます

まとめ

• Lighthouse CI（@lhci/cli）の lhci autorun で、計測・判定・保存を CI 上でまとめて実行できる
• 計測対象は wp-env で CI 上に立てた WordPress か、ステージング環境にし、本番は直接測らない
• numberOfRuns で複数回測り、基準は warn から始めて段階的に error へ移す
• レポートは artifact として保存し、公開ストレージへのアップロードは内容に応じて避ける
• Lighthouse はラボデータで INP は測れないため、フィールドデータと合わせて判断する

• WordPressをGitHub ActionsでCI/CD自動デプロイする方法
• PageSpeed Insightsの「レンダリングを妨げるリソース」を解消する方法