部分プリレンダリング

これまでは、静的レンダリングと動的レンダリング、そしてデータに依存する動的コンテンツをストリーミングする方法について学びました。このチャプターでは、部分プリレンダリング（PPR） を使用して、静的レンダリング、動的レンダリング、ストリーミングを同じルートで組み合わせる方法を学びましょう。

部分プリレンダリングは、Next.js 14で導入された実験的な機能です。このページの内容は、機能の安定性が向上するにつれて更新される可能性があります。

このチャプターの内容...

ここで扱うトピックは以下のとおりです

部分プリレンダリングとは何か。

部分プリレンダリングの仕組み。

静的ルートと動的ルート

現在構築されているほとんどのWebアプリでは、アプリケーション全体、または特定のルートに対して、静的レンダリングと動的レンダリングのいずれかを選択します。Next.jsでは、ルートで（データベースのクエリなど）動的関数を呼び出すと、ルート全体が動的になります。

ただし、ほとんどのルートは完全に静的または動的ではありません。たとえば、eコマースサイトを考えてみましょう。商品情報ページの大部分を静的にレンダリングしたい場合がありますが、ユーザーのカートやおすすめの商品は動的に取得したい場合があります。これにより、ユーザーにパーソナライズされたコンテンツを表示できます。

ダッシュボードページに戻り、どのコンポーネントを静的と見なし、どのコンポーネントを動的と見なしますか？

準備ができたら、下のボタンをクリックして、ダッシュボードルートをどのように分割するかを確認してください

部分プリレンダリングとは？

Next.js 14では、部分プリレンダリングの実験的バージョンが導入されました。これは、同じルートで静的レンダリングと動的レンダリングの利点を組み合わせることができる新しいレンダリングモデルです。例えば

ユーザーがルートにアクセスしたとき

• ナビゲーションバーと製品情報を含む静的ルートシェルが提供され、初期読み込みの高速化が保証されます。
• シェルは、カートやおすすめの商品などの動的コンテンツが非同期に読み込まれる場所を空けておきます。
• 非同期の穴は並行してストリーミングされ、ページ全体の読み込み時間が短縮されます。

部分プリレンダリングの仕組み

部分プリレンダリングは、ReactのSuspense（前のチャプターで学習しました）を使用して、特定の条件が満たされるまで（例：データが読み込まれるまで）アプリケーションの一部のレンダリングを遅延させます。

Suspenseフォールバックは、静的コンテンツと共に初期HTMLファイルに埋め込まれます。ビルド時（または再検証時）に、静的コンテンツはプリレンダリングされて静的シェルが作成されます。動的コンテンツのレンダリングは、ユーザーがルートをリクエストするまで延期されます。

コンポーネントをSuspenseでラップしても、コンポーネント自体が動的になるわけではありません。Suspenseは、静的コードと動的コードの境界として使用されます。

ダッシュボードルートにPPRを実装する方法を見てみましょう。

部分プリレンダリングの実装

ppr オプションを next.config.mjs ファイルに追加して、Next.js アプリの PPR を有効にします

/** @type {import('next').NextConfig} */
 
const nextConfig = {
  experimental: {
    ppr: 'incremental',
  },
};
 
export default nextConfig;

'incremental' 値を使用すると、特定のルートに PPR を適用できます。

次に、experimental_ppr セグメント設定オプションをダッシュボードレイアウトに追加します

import SideNav from '@/app/ui/dashboard/sidenav';
 
export const experimental_ppr = true;
 
// ...

これで完了です。開発環境ではアプリケーションに違いが見られないかもしれませんが、本番環境ではパフォーマンスの向上が見られるはずです。Next.js は、ルートの静的部分をプリレンダリングし、ユーザーがリクエストするまで動的部分を遅延させます。

部分プリレンダリングの優れた点は、使用するためにコードを変更する必要がないことです。Suspense を使用してルートの動的部分をラップしている限り、Next.js はルートのどの部分が静的でどの部分が動的であるかを認識します。

PPR は、Web アプリケーションのデフォルトのレンダリングモデルになる可能性があり、静的サイトと動的レンダリングの両方の利点を組み合わせることができます。ただし、まだ実験段階です。将来的には安定させて、Next.js での構築のデフォルトの方法にしたいと考えています。

まとめ

要約すると、アプリケーションのデータフェッチを最適化するために、いくつかのことを行いました

1. アプリケーションコードと同じリージョンにデータベースを作成して、サーバーとデータベース間のレイテンシを削減しました。
2. Reactサーバーコンポーネントを使用してサーバー上のデータをフェッチしました。これにより、負荷の高いデータフェッチとロジックをサーバー上に維持し、クライアント側のJavaScriptバンドルを削減し、データベースのシークレットがクライアントに公開されるのを防ぎます。
3. SQLを使用して必要なデータのみをフェッチし、各リクエストで転送されるデータ量とメモリ内でデータを変換するために必要なJavaScriptの量を削減しました。
4. 理にかなっている場合は、JavaScriptでデータフェッチを並列化します。
5. ストリーミングを実装して、低速のデータリクエストがページ全体をブロックするのを防ぎ、すべてが読み込まれるのを待たずにユーザーがUIとの対話を開始できるようにしました。
6. データの取得を必要とするコンポーネントに移動することで、ルートのどの部分が動的であるべきかを分離します。

次の章では、データを取得する際に実装が必要となる可能性のある2つの一般的なパターン、検索とページネーションについて見ていきます。