部分的なプリレンダリング

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

部分的なプリレンダリングは、Next.js 14 で導入された実験的な機能です。この機能の安定性が向上するにつれて、このページの内容は更新される可能性があります。**PPR は Next.js のカナリアリリース** (next@canary) でのみ利用可能であり、Next.js の安定版では利用できません。本番環境での部分的なプリレンダリングの使用はまだ推奨していません。

Next.js のカナリアリリースをインストールするには、以下を実行します

pnpm install next@canary

この章では...

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

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

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

静的ルート vs. 動的ルート

今日構築されているほとんどのウェブアプリでは、**アプリケーション全体**または**特定のルート**に対して、静的レンダリングと動的レンダリングのどちらかを選択します。Next.js では、ルート内で動的関数 (データベースのクエリなど) を呼び出すと、*ルート全体*が動的になります。

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

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

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

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

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

ユーザーがルートを訪問したとき

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

部分的なプリレンダリングの仕組みは？

部分的なプリレンダリングは、React のSuspense (前章で学習しました) を使用して、何らかの条件 (例: データが読み込まれた) が満たされるまでアプリケーションの一部のレンダリングを遅延させます。

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

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

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

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

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

import type { NextConfig } from 'next';
 
const nextConfig: 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 Server Components を使用してサーバーでデータをフェッチしました。これにより、コストのかかるデータフェッチとロジックをサーバーに保持し、クライアント側の JavaScript バンドルを削減し、データベースの秘密がクライアントに公開されるのを防ぎます。
3. SQL を使用して必要なデータのみをフェッチすることで、各リクエストで転送されるデータ量と、メモリ内でデータを変換するために必要な JavaScript の量を削減しました。
4. JavaScript を使用してデータフェッチを並列化しました - 必要な場合のみ。
5. ストリーミングを実装して、遅いデータリクエストがページ全体をブロックするのを防ぎ、すべてが読み込まれるのを待つことなくユーザーが UI とのインタラクションを開始できるようにしました。
6. データフェッチを必要とするコンポーネントに移動させ、それによってルートのどの部分を動的にすべきかを分離しました。

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