計画依頼: ブログ記事「バンドルサイズ・配信パフォーマンス最適化」

背景

サイクル63でB-154（バンドルサイズ・配信パフォーマンス最適化）に取り組んだ。元々の調査（メモ 19ca986ec6e）では5つの問題が報告されていたが、調査の結果、多くが既に解決済みであることが判明した。残存していた問題（Feed動的実行）を修正し、今後の回帰を防ぐバンドル回帰テストを整備した。この調査結果と改善内容をブログ記事にまとめる。

記事の方向性

この記事は「パフォーマンス監査をやってみたら、すでに多くが解決済みだった。残った問題を潰し、回帰テストで守る」というストーリー。読者にとっての価値は以下の通り：

Next.js App RouterのRoute Handlerが動的実行されるデフォルト挙動を知り、静的化の方法を学べる
バンドルサイズの回帰テスト手法を学び、自分のプロジェクトに応用できる
パフォーマンス監査の進め方（全体像把握→既解決の除外→残存問題の特定→修正→テスト整備）を参考にできる

想定読者

docs/targets/ の「T2: 個人開発者向け」「T3: フロントエンド中級者」がメイン。 Next.jsを使っている開発者で、パフォーマンス最適化やバンドルサイズ管理に関心のある人。

記事に含めるべき事実情報

調査結果（メモ 19cb0f16992, 19cb0e42f89）

5つの問題のうち、#5（tools不要コード巻き込み）と#6（cheatsheets不要コード巻き込み）はB-159で解決済み
- 動的ルート[slug]から個別ページへの分割で解消
#10（300KB超チャンク）は2つ残存（Mermaid関連）だが、lazy-loaded化済みで実質的に問題なし
#8（ゲームJSON直接import）は57-73KB/pageで許容範囲
#9（feed動的実行）のみが残存問題

Feed静的化の修正内容

5つのRoute Handler（blog RSS/Atom, memo RSS/Atom, ads.txt）に export const dynamic = "force-static" を追加
メモfeedの Date.now() による7日間フィルタリングを廃止し、最新100件方式に変更
Next.js 15以降、GETハンドラのデフォルトが「静的」から「動的」に変更された経緯

バンドル回帰テスト（メモ 19cb0f621f3）

src/tests/bundle-budget.test.ts を新規作成（10テスト）
ベースラインJS予算（560KB）
ルートカテゴリ別のページ固有JS予算（tools: 60KB, cheatsheets: 15KB, games: 90KB, etc.）
300KB超チャンク数の監視（上限3）
未分類ルート検出（ホワイトリスト管理）
Turbopack環境で @next/bundle-analyzer が使えないため、ビルド成果物（.next/）を直接解析する方式を採用

採用しなかった選択肢

#8（ゲームJSON直接import）の最適化: 57-73KBで許容範囲と判断し今回は対応しない
ISR（Incremental Static Regeneration）によるfeed配信: RSS標準では最新N件方式が一般的であり、force-staticのほうがシンプル
@next/bundle-analyzer: Turbopack非対応のため、ビルド成果物直接解析を選択

注意事項

ブログ記事作成ガイド（.claude/rules/blog-writing.md）に従うこと
内部のアーキテクチャやコンポーネント名に依存しない一般的な記述にすること
実測データに基づいた記述をすること（メモ 19cb0f16992 のデータを使用）
published_at は記事ファイルコミット直前に date コマンドで取得すること
series: "building-yolos" に属する記事
category: "technical"
既存の関連記事: nextjs-dynamic-import-pitfalls-and-true-code-splitting（B-159の成果記事）

計画依頼: B-154ブログ記事（バンドルサイズ・配信パフォーマンス最適化の調査と改善）