バンドルモニタリング

21.4.1. バンドルサイズ基準

ビルド成果物のサイズは以下の基準を超過してはなりません。

項目	最大サイズ	測定基準	TQS 要求事項
初期 JavaScript	300KB	gzip 圧縮後	必須
単一チャンク最大	500KB	gzip 圧縮後	必須
全体 CSS	100KB	gzip 圧縮後	必須
単一画像アセット	500KB	元のサイズ	必須

• 初期 JavaScript はエントリーポイントで読み込むすべての JS ファイルの合計サイズを基準とします。
• 単一チャンクが 500KB を超過する場合、コード分割を適用して分離しなければなりません。
• サードパーティライブラリは vendor チャンクに分離してキャッシュ効率を高めなければなりません。
• CSS は未使用のスタイルを削除（PurgeCSS など）してサイズを最小化しなければなりません。

---

21.4.2. 分析ツール

バンドル構成を視覚的に分析するために以下のツールを使用しなければなりません。

ツール	用途	適用タイミング
rollup-plugin-visualizer	Vite/Rollup バンドル可視化	ビルド後分析
source-map-explorer	ソースマップベースのバンドル分析	ビルド後分析
bundlephobia	パッケージサイズの事前確認	パッケージ導入前

• バンドル分析は最低 リリース単位（スプリント終了またはバージョンリリース）ごとに実施しなければなりません。
• rollup-plugin-visualizer を使用してバンドル構成レポート（HTML ファイル）を生成することを推奨します。

// vite.config.ts
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    visualizer({
      filename: 'dist/bundle-report.html',
      gzipSize: true,
    }),
  ],
})

• 新規パッケージ導入時に bundlephobia を通じてパッケージサイズとツリーシェイキングサポート状況を事前に確認しなければなりません。
• 分析レポートはビルドアーティファクトとして保管し、サイズ変化の推移を追跡することを推奨します。

---

21.4.3. CI サイズ検証

CI パイプラインでビルド成果物のサイズを自動的に検証しなければなりません。

• ビルド完了後に成果物のサイズを測定し、21.4.1. で定義した基準と比較しなければなりません。
• 閾値を超過した場合はビルドを失敗処理しなければなりません。
• bundlesize または size-limit ツールを CI に統合して自動検証することを推奨します。

// package.json - size-limit 設定例
{
  "size-limit": [
    { "path": "dist/assets/*.js", "limit": "300 KB", "gzip": true },
    { "path": "dist/assets/*.css", "limit": "100 KB", "gzip": true }
  ]
}

• PR（Pull Request）にバンドルサイズの変化量を自動的にコメントすることを推奨します。
• サイズ増加が 10% 以上の場合、コードレビューで原因を分析しなければなりません。

---

21.4.4. パフォーマンスバジェット

プロジェクトごとにパフォーマンスバジェットを策定し管理しなければなりません。

バジェット項目	基準値	測定方法
初期 JS サイズ	300KB（gzip）	ビルド成果物測定
全体 CSS サイズ	100KB（gzip）	ビルド成果物測定
LCP	2.5 秒以下	Lighthouse CI
INP	200ms 以下	Chrome UX Report
CLS	0.1 以下	Lighthouse CI
Lighthouse パフォーマンススコア	90 点以上	Lighthouse CI

• パフォーマンスバジェットはプロジェクト初期に策定し、チーム全体に共有しなければなりません。
• バジェット超過時は以下の手順に従います。
  1. 原因となるコードまたはリソースを特定します。
  2. コード分割、遅延読み込み、リソース最適化などの改善措置を実施します。
  3. 改善後に基準値以内に復帰したことを検証します。
• パフォーマンスバジェット基準は 6 か月周期で見直し、技術環境の変化に合わせて調整します。
• 見直し時には実ユーザーデータ（RUM）を基に基準値の妥当性を評価します。