「遅くなった」を感覚で語るな。GitHub ActionsとLighthouse CIで実装する「パフォーマンス予算」の自動監視

PMや経営者からの、この**「感覚的な指摘」**ほど、エンジニアを困らせるものはありません。
しかし、悔しいことにその指摘は大抵正しいのです。それをPMが確認する前に、エンジニアコード生成時にチェックできる仕組みがあると便利だと思いませんか？

そうすることで、
プログラムのコードのレベルがあがり、モダン開発がすすみます。

Webサイトのパフォーマンス改善は、ダイエットに似ています。 一度気合を入れて画像を圧縮し、コードを整理して「80kg → 60kg」に落とすのは簡単です。難しいのは、**半年後も「60kg」をキープすること（リバウンド防止）**です。

機能を追加すれば、JavaScriptは増えます。 デザインをリッチにすれば、画像は重くなります。 放っておけば、サイトは物理法則に従って必ず遅くなるのです。

本記事では、この「速度のリバウンド」を根性論で防ぐのではなく、
**GitHub Actions と Lighthouse CI を用いて「遅くなるコードをそもそもマージさせない」仕組み（自動化）**について解説します。

---

第1章：なぜ「パフォーマンス予算」が必要なのか？

ダイエットを維持するには、「太ったら気づく」では遅すぎます。「食べる前にカロリーを見る」必要があります。 Web開発においてこれに当たるのが、**「パフォーマンス予算 (Performance Budget)」**という考え方です。

• JavaScriptサイズ: 300KB 以内
• Lighthouseスコア: 90点 以上
• First Contentful Paint: 1.5秒 以内

これらを「努力目標」ではなく、**「絶対に超えてはいけない予算（制約）」**として定義します。
エンジニアには、工数予算もそうですが、別の予算、コード予算（制約）とすることが、モダン開発に必須の仕組みです。

「予算オーバー」＝「バグ」とみなす

多くの現場では、機能バグ（ボタンが動かない等）はリリースを止めますが、パフォーマンス悪化（1秒遅くなる等）はスルーされがちです。

パフォーマンス予算をCI（継続的インテグレーション）に組み込むことで、「速度低下」を「構文エラー」と同等の「リリースできない不具合」として扱うことができます。これこそが、品質維持の唯一の解です。

---

第2章：最強の門番「Lighthouse CI」

この監視を自動化するために、Googleが提供している公式ツールが Lighthouse CI (LHCI) です。
これを GitHub Actions（自動化ワークフロー）に組み込むことで、以下のフローが実現します。

1. エンジニアがコードを修正し、プルリクエスト（PR）を出す。
2. GitHub Actions が自動で起動し、そのページに対してLighthouse計測を実行する。
3. もしスコアが予算（例: 90点）を下回っていたら、テスト失敗としてマージをブロックする。

人間がチェックする必要はありません。門番が自動で「出直しなさい」と弾いてくれるのです。

---

第3章：実装レシピ (GitHub Actions)

では、具体的な実装を見てみましょう。 .github/workflows/ci.yml に数行書くだけで、この強力な門番を雇うことができます。

1. ワークフローの設定

YAML

name: CI
on: [pull_request] # PR作成時に発動

jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js
        uses: actions/setup-node@v3
      
      - name: Install & Build
        run: |
          npm install
          npm run build # 本番相当のビルドを作成
      
      - name: Run Lighthouse CI
        run: npm install -g @lhci/cli && lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

2. 予算の定義 (lighthouserc.json)

次に、「何点以下なら落とすか」という予算を定義します。ここがPMとエンジニアの握りどころです。

JSON

{
  "ci": {
    "collect": {
      "staticDistDir": "./out" // Next.jsなどの出力先
    },
    "assert": {
      "assertions": {
        // カテゴリごとの最低スコア (0~1)
        "categories:performance": ["error", {"minScore": 0.9}], 
        "categories:accessibility": ["error", {"minScore": 0.9}],

        // 個別の指標にも予算を設定できる
        "first-contentful-paint": ["error", {"maxNumericValue": 2000}], // 2秒以内
        "interactive": ["error", {"maxNumericValue": 3500}] // 3.5秒以内
      }
    }
  }
}

この設定（minScore: 0.9）がある限り、パフォーマンススコアが89点になったコードは、絶対に本番環境に反映されません。

---

第4章：開発文化の変革

この仕組みを導入すると、開発チームの会話が劇的に変わります。

導入前:

• PM: 「新機能を入れたい」
• エンジニア: 「入れると重くなりますが…まあ、後でチューニングしましょう」
• 結果: 技術的負債の先送り

導入後:

• PM: 「新機能を入れたい」
• エンジニア: 「入れると予算（JSサイズ）オーバーでCIが落ちます。代わりにどの機能を削りますか？ あるいは、予算を増やしますか？」
• 結果: 健全なトレードオフの議論

「遅くなった」という感覚論ではなく、
「予算内に収まるか」という定量的な議論ができるようになる。これこそが、自動化監視の真の価値です。

---

まとめ：速度は「機能」である

「パフォーマンスは、機能要件（Functional Requirement）だ」という言葉があります。 どんなに便利な機能も、表示に10秒かかれば誰も使いません。つまり、遅い機能は、壊れているのと同じです。

• 一度きりの高速化は、誰でもできる。
• 高速化を**「維持」**できるのが、プロの組織。

GitHub Actions と Lighthouse CI を導入し、あなたのチームにも「品質の門番」を配置しましょう。 それが、ユーザー体験を永続的に守るための、最も安上がりで確実な投資です。

---

👇 【指標】予算を決めるための基準とは？

【SEO】LCPはもう古い？Googleの新指標「INP」の正体

パフォーマンス予算を設定する際、今絶対に含めるべきなのが「INP（応答速度）」です。 Lighthouse CIでINP悪化を防ぐために知っておくべき知識を解説します。

👉 記事を読む：Googleの新指標「INP」とエンジニアがやるべきデバッグ :::

👇 【解決策】CIで落ちた時のチューニング術

【AWS】重い画像を自動で軽くする「画像パイプライン」

パフォーマンス予算オーバーの原因が「画像」なら、これを導入するだけで解決します。 S3に置くだけでWebP/AVIFに自動変換するサーバーレス構成。

👉 記事を読む：AWS Lambdaによる画像最適化パイプライン :::

👉 記事を書いた人