こんにちは。世界中の開発現場で「いかに手を動かさずに品質を担保するか」を追求し続けている、リードデブオプスエンジニアです。
今日は、フロントエンド開発者なら誰もが一度は触れたことがあるであろう「ブラウザ開発者ツール（DevTools）のLighthouse」を、あなたのPCから解き放ち、CI/CDパイプラインという「自動化の聖域」へ昇華させる方法を伝授します。
「手動でポチポチ測定するのはもう終わりにしましょう」
この記事を読み終える頃、あなたのプロジェクトは「デプロイされるたびに、客観的で冷徹なパフォーマンス評価が自動で下される」という、極めてモダンで堅牢な環境へと進化しているはずです。
—
1. なぜ「手動のLighthouse」では不十分なのか？
多くのエンジニアは、ブラウザのDevToolsを開き、Lighthouseタブで「Analyze page load」をクリックします。確かにこれは手軽ですが、致命的な弱点があります。
- 環境のブレ: あなたのPCのスペック、開いているタブの数、Wi-Fiの混雑状況でスコアが変わってしまいます。
- 属人性: 「リリースの直前に測り忘れた」というミスを防げません。
- 推移の不可視化: 「1ヶ月前より速くなったのか？」という問いに、エビデンスを持って答えられません。
これらを解決するのが、Lighthouse CI (LHCI) です。これはGoogleが提供する公式ツールで、DevToolsのエンジンをサーバー（CI環境）上で動かし、計測を自動化するための最強の武器です。
—
2. 準備：Lighthouse CIをプロジェクトに組み込む
まずは、あなたのプロジェクトに計測の「脳」となるパッケージをインストールしましょう。
必要なツールのインストール
ターミナルを開き、プロジェクトのルートディレクトリで以下のコマンドを実行してください。
LHCIのCLIツールをインストールします。
プロジェクトごとの依存関係として管理するのがベストプラクティスです。
npm install –save-dev @lhci/cli
—
3. 核心：`.lighthouserc.js` の設計思想
LHCIを動かすには、設定ファイルが必要です。単なる設定値の羅列ではなく、「なぜこの設定にするのか」という意図を込めて作成しましょう。
プロジェクトのルートに `.lighthouserc.js` を作成し、以下のコードを記述してください。
module.exports = {
ci: {
// 1. 収集（Collect）フェーズの設定
collect: {
// ローカルのビルド成果物をホストするコマンド（例: Next.jsやViteの場合）
// ここでは静的ファイルが ‘dist’ ディレクトリにあると仮定します。
staticDistDir: ‘./dist’,
// 測定回数。1回だとノイズが混じるため、3回測定して平均・中央値を取るのが現場の知恵です。
numberOfRuns: 3,
// 測定対象のURL。複数指定可能です。
url: [‘http://localhost:8080/index.html’],
// ブラウザ（Chromium）を起動するための設定
settings: {
// モバイル環境をシミュレート（デスクトップが必要なら ‘desktop’ に変更）
emulatedFormFactor: ‘mobile’,
},
},
// 2. 表明（Assert）フェーズの設定
// ここが「自動化」の肝です。基準を下回ったらCIを失敗させます。
assert: {
assertions: {
// カテゴリーごとの最低スコアを0.9（90点）以上に設定
‘categories:performance’: [‘error’, { minScore: 0.9 }],
‘categories:accessibility’: [‘error’, { minScore: 0.9 }],
// 特定の指標（LCPなど）を個別に厳しくチェックすることも可能です
‘largest-contentful-paint’: [‘warn’, { maxNumericValue: 2500 }],
},
},
// 3. アップロード（Upload）フェーズの設定
upload: {
// 測定結果をどこに保存するか。
// ‘temporary-public-storage’ はGoogleが提供する一時ストレージにレポートを公開します。
target: ‘temporary-public-storage’,
},
},
};
アーキテクトの視点：なぜ `staticDistDir` を使うのか？
開発用サーバー（`npm run dev`）を立ち上げて測定するのは避けましょう。開発用サーバーはデバッグ情報の付与などで重くなっているため、「本番同等のビルド済みファイル」を対象にするのが、精度の高い測定の鉄則です。
—
4. 動作確認：ローカルで「自動測定」をシミュレートする
CIに組み込む前に、手元のマシンで正しく動作するか確認します。
1. まずはプロジェクトをビルドします（あなたのプロジェクトのビルドコマンドに変えてください）
npm run build
2. LHCIを実行します
‘autorun’ コマンドは、collect -> assert -> upload を一気に実行してくれる魔法のコマンドです。
npx lhci autorun
実行ログに以下のような表示が出れば成功です。
`✓ Healthcheck passed`
`✓ Collected results for http://localhost:8080/`
`✓ All assertions passed!`
—
5. CI/CD連携：GitHub Actionsで「守護神」を召喚する
さあ、いよいよ本番です。GitHubにコードをPushするたびに、Lighthouseが自動で走り、パフォーマンスの劣化を検知するようにします。
`.github/workflows/lighthouse.yml` を作成し、以下の内容を記述します。
name: Performance Check
on: [push, pull_request] # コードがプッシュされた時、またはPRが作成された時に発火
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- 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 # 本番用のファイルを生成
- name: Run Lighthouse CI
run: npx lhci autorun # ここで設定ファイルに基づき測定と判定を行う
env:
# GitHubトークンを渡すことで、PRのタイムラインに結果をリンクさせることができます
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
—
6. まとめ：これからあなたの開発はどう変わるか
お疲れ様でした！これであなたは、「なんとなく速い気がする」という曖昧な世界から、「数値によって品質が証明され続ける」プロフェッショナルな世界へと足を踏み入れました。
この設定を導入することで、以下のような劇的な変化が訪れます。
1. レビューの質の向上: プルリクエストに「この変更でパフォーマンスが5点下がりました」という警告が出るようになり、コードレビューがより本質的になります。
2. 確固たる自信: 「90点以上を維持している」というエビデンスがあるため、安心して新機能をデプロイできます。
3. チームの意識改革: スコアが可視化されることで、チーム全体に「パフォーマンスも機能の一部である」という文化が根付きます。
ブラウザのDevToolsは、あくまで「調査」のためのツール。CI/CD上のLighthouseは、プロダクトの「品質を保証」するためのツールです。
この一歩が、あなたの、そしてあなたのユーザーの体験を劇的に楽にすることを確信しています。さあ、今すぐ最初のビルドを回してみましょう！