Next.js 16の変更点まとめ：Partial Prerenderingが安定版に

はじめに

「Next.jsアプリのパフォーマンス、もっと向上させたい…」「静的サイトのような爆速表示と、動的コンテンツのリアルタイム更新、この二つを両立できずに悩んでいませんか？」

Next.js開発者であれば、一度はこのような課題に直面したことがあるでしょう。私たちはこれまで、ページの特性に応じてServer-Side Rendering (SSR)、Static Site Generation (SSG)、Incremental Static Regeneration (ISR) といったレンダリング戦略を使い分ける必要がありました。

SSRは動的なコンテンツに強い反面、リクエストごとにサーバーでレンダリングするためTime to First Byte (TTFB) が遅くなりがちです。
SSGはCDNから配信できるため非常に高速ですが、動的コンテンツの扱いやビルド時間の増大という課題を抱えています。
ISRはSSGの弱点を補いますが、リアルタイムの更新には対応しきれない場面もあります。

これらの戦略は強力ですが、ページ全体を「静的」か「動的」のどちらか一方の型にはめる「All or Nothing」のアプローチでした。例えば、大半が静的なEコマースの商品ページでも、在庫情報やレビューといった一部の動的コンテンツのために、ページ全体をSSRせざるを得ず、パフォーマンスを犠牲にすることが少なくありませんでした。

この長年のジレンマに終止符を打つべく登場し、Next.js 16でついに安定版となったのが Partial Prerendering (PPR) です。

PPRは、静的なパフォーマンスと動的な柔軟性を融合させる、まさに革命的なレンダリングモデルです。この記事では、PPRがなぜ重要なのか、その仕組み、具体的な実装方法から実践的なTipsまで、Next.js 16の目玉機能であるPPRを徹底的に解剖します。この記事を読み終える頃には、あなたはPPRを完全に理解し、自身のプロジェクトでその強力なパフォーマンスを最大限に引き出せるようになっているはずです。

なぜPPRは登場したのか？Webレンダリングの進化と課題

PPRの革新性を理解するためには、まずこれまでのWebレンダリングがどのような変遷を辿ってきたのかを知る必要があります。

Webレンダリング戦略の歴史

サーバーサイドレンダリングの黎明期 (CGI, PHP, Ruby on Rails) Webの初期、コンテンツはリクエストごとにサーバーでHTMLを生成して返すのが主流でした。これにより動的なコンテンツは実現できましたが、リクエストのたびに重い処理が走るため、パフォーマンスに課題がありました。
SPA (Single Page Application) の台頭 (React, Vue, Angular) 次に、クライアントサイドでJavaScriptがUIを構築するSPAが登場しました。初回ロード後はページ遷移なしに高速な画面更新が可能になり、リッチなUIが実現できます。しかし、初回のバンドルサイズが大きく初期表示が遅い、そしてSEOに課題があるという弱点がありました。
Next.jsがもたらしたハイブリッドアプローチ (SSR, SSG, ISR) この両者の課題を解決するために登場したのがNext.jsです。Next.jsは、ページ単位で最適なレンダリング戦略を選択できるハイブリッドなフレームワークとして絶大な支持を得ました。
- SSR (Server-Side Rendering): リクエストごとにサーバーでHTMLを生成。SEOに強く、初期表示に必要なデータが揃っています。しかし、サーバー負荷が高く、TTFBが遅くなりがちです。
- SSG (Static Site Generation): ビルド時にすべてのページをHTMLとして事前生成。CDNに配置することで、リクエスト時にはファイルを返すだけなので超高速です。しかし、ユーザー固有の情報のような動的コンテンツには向かず、サイト規模が大きくなるとビルド時間が長大になる問題がありました。
- ISR (Incremental Static Regeneration): SSGの弱点を補う仕組み。一定時間ごとにバックグラウンドでページを再生成し、静的コンテンツの鮮度を保ちます。しかし、リアルタイム性が求められるコンテンツには対応が難しいという側面がありました。

従来のレンダリング戦略が抱える「All or Nothing」問題

これらの戦略は非常に強力でしたが、根本的な課題を抱えていました。それは、1つのページは1つのレンダリング戦略しか選べないという「All or Nothing」の問題です。

この問題が顕著になるのが、静的コンテンツと動的コンテンツが混在するページです。先ほどのEコマースの商品ページを例に考えてみましょう。

静的な部分: 商品名、商品説明、スペック、メイン画像など、滅多に変わらない情報。
動的な部分: 在庫数、ユーザーレビュー、あなたへのおすすめ商品、セール価格など、リアルタイムで変化する情報。

従来のモデルでは、このページに動的な部分が一つでも含まれていると、ページ全体をSSRまたはISR（短い間隔での再生成）で構築する必要がありました。これにより、本来は高速に表示できるはずの静的な部分まで、リクエストのたびにサーバーでレンダリングされるのを待たなければならず、TTFBが悪化し、ユーザー体験を損なう原因となっていました。

この「All or Nothing」の制約を打ち破り、静的な部分のパフォーマンスと動的な部分の柔軟性を1つのページ内で共存させるために開発されたのが、Partial Prerendering (PPR)なのです。

Partial Prerendering (PPR) の核心に迫る：仕組みと使い方

PPRは、Next.js App RouterとReact Server Components (RSC) のアーキテクチャを基盤として実現されています。そのコンセプトは非常にシンプルです。「ページの静的な部分を事前にビルドしておき、動的な部分だけをリクエスト時にストリーミングで配信する」というものです。

「静的シェル」と「動的ホール」

PPRを理解する上で最も重要な概念が「静的シェル (Static Shell)」と「動的ホール (Dynamic Holes)」です。

静的シェル: ページのレイアウト、ナビゲーションバー、フッター、そして商品名や商品説明といった静的なコンテンツを含む、ページの骨格となる部分です。これはビルド時に事前生成（Prerender）され、CDNにキャッシュされます。
動的ホール: 在庫情報やレビューなど、動的に生成されるコンテンツが入る「穴」の部分です。静的シェルの中では、この部分はプレースホルダーとして空けられています。

この仕組みを図でイメージしてみましょう。

【ビルド時】
+-------------------------------------------------+
|               静的シェル (Static Shell)           |
| +-------------------------------------------+ |
| | ナビゲーションバー (静的)                 | |
| +-------------------------------------------+ |
| |                                           | |
| | 商品画像、商品名、商品説明 (静的)         | |
| |                                           | |
| | +---------------------------------------+ | |
| | | 動的ホール (1): レビュー (プレースホルダー)| |
| | +---------------------------------------+ | |
| |                                           | |
| | +---------------------------------------+ | |
| | | 動的ホール (2): おすすめ商品 (プレースホルダー) | |
| | +---------------------------------------+ | |
| |                                           | |
| +-------------------------------------------+ |
| | フッター (静的)                           | |
| +-------------------------------------------+ |
+-------------------------------------------------+

PPRの動作フロー

ユーザーがページにアクセスした際の動作フローは以下のようになります。

即時レスポンス: ユーザーからのリクエストに対し、CDNにキャッシュされている「静的シェル」が即座に返されます。これにより、TTFBが劇的に改善され、ユーザーはすぐにページの骨格を見ることができます。
動的コンテンツのストリーミング: ブラウザが静的シェルを表示している間に、Next.jsサーバーは「動的ホール」の中身を非同期でレンダリングします。
コンテンツの注入: レンダリングが完了した動的コンテンツは、HTTPストリーミングを通じてブラウザに送信され、対応するプレースホルダー部分にシームレスに注入されます。この間、Suspenseのfallbackに指定したスケルトンUIやローディングスピナーが表示されるため、ユーザーはデータが読み込み中であることを認識できます。

このアーキテクチャにより、ユーザーはサーバーでの重い処理が終わるのを待つことなく、インタラクション可能なページを即座に手に入れることができるのです。

コードで見るPPR：`Suspense`が鍵

驚くべきことに、PPRを有効にするために特別な設定はほとんど必要ありません。Next.js 14.1以降のApp Routerを使用していれば、PPRはデフォルトで有効です。

PPRの魔法を実現する鍵となるのが、Reactの <Suspense> コンポーネントです。<Suspense>でラップされたコンポーネントが「動的ホール」として扱われます。

それでは、Eコマースの商品ページを例に、具体的なコードを見ていきましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


// app/products/[id]/page.tsx

import { Suspense } from 'react';
import ProductDetails from '@/components/ProductDetails';
import { Reviews, ReviewsSkeleton } from '@/components/Reviews';
import { Recommendations, RecommendationsSkeleton } from '@/components/Recommendations';
import { getStaticProductData } from '@/lib/products';

// このページ自体は静的として扱われる
export default async function ProductPage({ params }: { params: { id: string } }) {
  // 商品の基本情報（商品名、説明など）はビルド時に取得される
  // このデータ取得はキャッシュされる
  const product = await getStaticProductData(params.id);

  return (
    <div>
      {/* ============================= */}
      {/* === ここからが静的シェル === */}
      {/* ============================= */}
      <header>My E-Commerce Site</header>
      <main>
        {/* このコンポーネントは静的にレンダリングされる */}
        <ProductDetails product={product} />
        
        <hr />

        {/* ========================================= */}
        {/* === ここからが動的なホール (1): レビュー === */}
        {/* ========================================= */}
        <Suspense fallback={<ReviewsSkeleton />}>
          {/* 
            Reviewsコンポーネントは内部で動的なデータ取得を行う。
            (例: fetch(..., { cache: 'no-store' }))
            このため、この部分はリクエスト時にレンダリングされる。
          */}
          <Reviews productId={product.id} />
        </Suspense>
        
        <hr />

        {/* =================================================== */}
        {/* === ここからが動的なホール (2): おすすめ商品 === */}
        {/* =================================================== */}
        <h2>あなたへのおすすめ</h2>
        <Suspense fallback={<RecommendationsSkeleton />}>
          {/* 
            Recommendationsコンポーネントも動的なデータ取得を行う。
            レビューとは独立してストリーミングされる。
          */}
          <Recommendations category={product.category} />
        </Suspense>
      </main>
      <footer>Footer Content</footer>
      {/* =========================== */}
      {/* === ここまでが静的シェル === */}
      {/* =========================== */}
    </div>
  );
}

このコードのポイントは以下の通りです。

ページの基本構造は静的: ProductPage自体はasyncコンポーネントですが、内部で行われるデータ取得 (getStaticProductData) がキャッシュされるため、ページの主要部分は静的に事前生成されます。これが「静的シェル」となります。
Suspenseで動的境界を定義: <Reviews>と<Recommendations>コンポーネントは、それぞれ<Suspense>でラップされています。これらのコンポーネントは、内部で動的なデータフェッチ（例えば fetch の cache: 'no-store' オプションや、cookies()、headers() といったDynamic Functionsの使用）を行うため、「動的ホール」として扱われます。
fallbackでUXを向上: 動的コンテンツがロードされるまでの間、fallbackプロパティに指定されたスケルトンコンポーネント (<ReviewsSkeleton />, <RecommendationsSkeleton />) が表示されます。これにより、レイアウトシフトを防ぎ、ユーザー体験を向上させます。

このように、開発者は「どこを動的にしたいか」を<Suspense>で宣言するだけで、Next.jsが自動的にPPRを適用し、最適なレンダリングを行ってくれるのです。

PPRがもたらすメリットと考慮すべき点

PPRは多くのメリットをもたらしますが、採用する上で知っておくべき考慮点も存在します。

メリット

圧倒的なパフォーマンス向上:
- TTFB (Time to First Byte) の劇的な改善: CDNから静的シェルを即座に返せるため、サーバーでのレンダリング待ち時間がなくなり、TTFBは限りなくゼロに近づきます。
- FCP/LCP の高速化: ユーザーはページの主要なコンテンツをすぐに視認できるため、First Contentful Paint (FCP) や Largest Contentful Paint (LCP) といったCore Web Vitalsの指標が大幅に改善されます。
最高のユーザー体験 (UX):
- 静的な部分は即座に表示され、インタラクション可能になります。
- 動的な部分はスケルトンUIなどで読み込み中であることが明示されるため、ユーザーは白紙の画面を見て待たされるストレスから解放されます。
優れた開発体験 (DX):
- 「SSGかSSRか」というページ単位での二者択一の悩みから解放されます。
- 開発者はコンポーネント単位でキャッシュ戦略を考えるだけでよくなり、より直感的にアプリケーションを構築できます。
- 複雑な設定は不要で、Reactの標準的な機能である<Suspense>を使うだけで実現できるシンプルさも魅力です。
インフラコストの削減:
- 静的シェルがCDNから配信されることで、オリジンサーバーへのリクエスト数が減少します。これにより、サーバーの負荷が軽減され、インフラコストの削減につながる可能性があります。

デメリット / 考慮すべき点

App RouterとRSCへの依存: PPRは、React Server Components (RSC) を前提としたApp Routerのアーキテクチャ上で成り立っています。従来のPages Routerでは利用できず、PPRの恩恵を受けるためにはApp Routerへの移行が必要です。
Suspenseの境界設計の重要性: Suspenseの境界（boundary）をどこに設定するかが、パフォーマンスとUXを左右します。境界が大きすぎるとストリーミングのメリットが薄れ、細かすぎるとコンポーネントの管理が複雑になる可能性があります。戦略的な設計が求められます。
キャッシュ戦略の理解: ページ単位ではなく、コンポーネントやデータフェッチ単位でキャッシュを管理する必要があるため、アプリケーション全体のキャッシュ戦略をより深く理解し、設計することが重要になります。特に、意図せずページ全体が動的レンダリングになってしまうケース（ルートレイアウトでのDynamic Functionsの使用など）には注意が必要です。
サードパーティライブラリの互換性: RSCに対応していないクライアントサイド専用のライブラリ（例: windowオブジェクトに直接アクセスするもの）は、'use client'ディレクティブを付けたClient Component内で使用する必要があります。PPRの文脈でもこの原則は変わらないため、ライブラリの選定や利用方法に注意が必要です。

現場で使えるPPR実践Tips

PPRを最大限に活用するための、より実践的なヒントをいくつかご紹介します。

Tip 1: `Suspense`の境界を戦略的に設計する

Suspenseでどこを囲むかは非常に重要です。以下の点を考慮して設計しましょう。

Above the Fold (ファーストビュー) は静的に: ユーザーが最初に目にする画面（スクロールせずに見える範囲）は、可能な限り静的シェルに含め、即座に表示されるようにします。LCPの改善に直結します。
Below the Fold (スクロール後) を動的に: コメント欄や関連商品リストなど、スクロールしないと見えない部分は、積極的にSuspenseで囲み、遅延ロードさせましょう。これにより、初期表示のパフォーマンスへの影響を最小限に抑えられます。
データ取得が遅いコンポーネントを分離する: 外部APIへの依存などでどうしても読み込みが遅くなるコンポーネントは、他のUIから独立させてSuspenseで囲むことで、そのコンポーネントの遅延がページ全体の表示をブロックするのを防ぎます。

Tip 2: 高品質なスケルトンUIを実装する

fallbackに表示されるUIは、ユーザー体験を大きく左右します。

単なる「ローディング中…」は避ける: テキストだけのローディング表示は、味気なく、ユーザーに不安を与える可能性があります。
レイアウトを維持するスケルトンを: 実際に表示されるコンテンツのレイアウトを模したスケルトンUI（Shimmer UIとも呼ばれる）を用意しましょう。これにより、コンテンツが読み込まれた際のレイアウトシフト（CLS: Cumulative Layout Shift）を防ぎ、スムーズな表示を実現できます。shadcn/uiなどのライブラリには、便利なSkeletonコンポーネントが用意されています。

Tip 3: Next.jsのキャッシュとレンダリングを可視化・デバッグする

意図通りにPPRが機能しているかを確認することが重要です。

ビルドログの確認: next build を実行すると、各ページが静的（λ）か動的（○）かが出力されます。PPRが適用されているページは静的（λ）としてマークされるはずです。
ブラウザの開発者ツール: Networkタブでドキュメントのレスポンスを確認します。PPRが機能している場合、最初のHTMLレスポンスには静的シェルとSuspenseのfallbackが含まれ、その後、動的コンテンツがチャンクとしてストリーミングされてくる様子を観察できます。
Vercelへのデプロイ: Vercelにデプロイすると、Speed InsightsやAnalytics機能を使って、TTFBやLCPといったパフォーマンス指標を実環境でモニタリングし、PPR導入による改善効果を定量的に測定できます。

まとめ

Next.js 16で安定版となったPartial Prerendering (PPR)は、単なる新機能ではありません。それは、Webアプリケーションのパフォーマンスと体験を根底から変える、レンダリングの新しいパラダイムです。

これまで私たちが直面してきた、静的サイトの「速度」と動的アプリケーションの「柔軟性」のトレードオフ、すなわち「All or Nothing」問題は、PPRによってついに解決されました。PPRは、React Server ComponentsとSuspenseを組み合わせることで、1つのページ内に静的なシェルと動的なホールを共存させ、両者の利点を同時に享受することを可能にします。

その結果として得られるのは、CDNエッジからの即時レスポンスによる驚異的なTTFB、最適化されたCore Web Vitals、そしてシームレスでストレスのないユーザー体験です。開発者にとっても、複雑なレンダリング戦略の選択に頭を悩ませることなく、コンポーネント単位でその性質を考えるだけで、フレームワークが最適なパフォーマンスを引き出してくれるという、この上ない開発体験を提供します。

App Routerへの移行というハードルはありますが、PPRがもたらす恩恵はそれを補って余りあるものです。今後のWeb開発において、このアーキテクチャがスタンダードになっていくことは間違いないでしょう。

さあ、あなたのNext.jsプロジェクトでも<Suspense>を使って、遅延がちなコンポーネントをラップすることから始めてみませんか？小さな一歩からでも、PPRがもたらす次世代のWebパフォーマンスをきっと実感できるはずです。Next.js 16と共に、より速く、より快適なWebの世界を構築していきましょう。

Next.js 16の変更点まとめ：Partial Prerenderingが安定版に#

はじめに#

なぜPPRは登場したのか？Webレンダリングの進化と課題#

Webレンダリング戦略の歴史#

従来のレンダリング戦略が抱える「All or Nothing」問題#

Partial Prerendering (PPR) の核心に迫る：仕組みと使い方#

「静的シェル」と「動的ホール」#

PPRの動作フロー#

コードで見るPPR：Suspenseが鍵#

PPRがもたらすメリットと考慮すべき点#

メリット#

デメリット / 考慮すべき点#

現場で使えるPPR実践Tips#

Tip 1: Suspenseの境界を戦略的に設計する#

Tip 2: 高品質なスケルトンUIを実装する#

Tip 3: Next.jsのキャッシュとレンダリングを可視化・デバッグする#

まとめ#