Next.js は React の事実上の標準フレームワークになり、企業の Web プロダクトの多くで採用されています。一方で App Router 移行・Server Components の理解・Edge Runtime の使い所など、3 年経験者でも判断が分かれる論点が増えました。本稿は本番運用の実務目線で深掘りします。
App Router vs Pages Router の判断軸
| 状況 | 推奨 | 理由 |
|---|---|---|
| 新規プロジェクト | App Router | Server Components・Streaming・Partial Prerendering が利用可能 |
| 既存 Pages Router の小規模アプリ | 段階移行 or 据え置き | 移行コスト＞メリットなら据え置きも合理的 |
| 大規模 Pages Router | 段階移行 | app/ ディレクトリ並行で新機能から段階導入 |
| SSG 中心のサイト | App Router | generateStaticParams + ISR で柔軟性が高い |
Server Components と Client Components の境界設計
App Router の中核は Server Components がデフォルト である点です。Client Components を意識的に最小化することでバンドルサイズと TTI が劇的に改善します。
- "use client" は葉に: ツリーの末端（ボタン・フォームなど）に閉じ込める
- 状態は Client、データ取得は Server: useState / useEffect が必要なものだけ Client
- props で Server → Client にデータを渡す: ただし Serializable なものに限定
- Suspense で部分的にロード: 重いデータ取得は Suspense 境界で遅延表示
レンダリング戦略の使い分け
Next.js は SSG / ISR / SSR / CSR / PPR の 5 種類のレンダリング戦略を持ちます。コンテンツ更新頻度とユーザー体験の組み合わせで判断します。
- SSG（静的生成）: 更新頻度低・全ユーザー同一表示（マーケサイト・ブログ）
- ISR（増分静的再生成）: 数分〜数時間で更新（ニュース・商品一覧）
- SSR（サーバーサイドレンダリング）: ユーザー別の動的データ（ダッシュボード）
- CSR（クライアント側）: SEO 不要・インタラクティブ重視（管理画面）
- PPR（Partial Prerendering）: 静的シェル + 動的部分の混在
Edge Runtime と Node Runtime の選択
Edge Runtime は低レイテンシでグローバル分散される一方、Node の API（fs / process）が使えません。次の判断軸で選びます。
- Edge を選ぶ: 地理的に分散したユーザー・軽量な処理・middleware・A/B テスト
- Node を選ぶ: 重い CPU 処理・Node native モジュール依存・既存ライブラリ互換性
- 注意: Edge は実行時間・メモリ・バンドルサイズに厳しい制限
Core Web Vitals の本番改善
Next.js の Core Web Vitals 改善で効果が大きい順:
- next/image の活用: priority 属性で LCP 画像を指定、sizes 属性で適切なバリアント配信
- next/font: フォントのプリロードと CLS 回避
- Server Components 化: JS バンドル削減で INP 改善
- Suspense + loading.tsx: 初回表示の体感速度を改善
- Route Segment Config: dynamic = "force-static" でキャッシュ強制
関連リンク
React のパフォーマンス改善は React 実践、フロント高速化は Core Web Vitals 実践、CDN/エッジは CDN/エッジ実装 を参照してください。
