Next.jsにおけるキャッシュ

Next.jsは、レンダリング作業とデータリクエストをキャッシュすることで、アプリケーションのパフォーマンスを向上させ、コストを削減します。このページでは、Next.jsのキャッシュメカニズム、それらを設定するために使用できるAPI、およびそれらがどのように相互作用するかについて詳しく説明します。

知っておくと便利: このページはNext.jsの内部動作を理解するのに役立ちますが、Next.jsを生産的に使用するために必須の知識ではありません。Next.jsのキャッシュヒューリスティックの大部分は、APIの使用状況によって決定され、ゼロまたは最小限の設定で最高のパフォーマンスを得られるデフォルト値が設定されています。代わりに例を見たい場合は、ここから始めてください。

概要

以下は、さまざまなキャッシュメカニズムとその目的の概要です:

デフォルトでは、Next.jsはパフォーマンスを向上させ、コストを削減するために可能な限りキャッシュします。これは、オプトアウトしない限り、ルートが静的レンダリングされ、データリクエストがキャッシュされることを意味します。以下の図は、デフォルトのキャッシュ動作を示しています: ビルド時にルートが静的にレンダリングされる場合と、静的ルートが初めて訪問される場合です。

キャッシュ動作は、ルートが静的または動的にレンダリングされるか、データがキャッシュされるかされないか、リクエストが初回訪問か後続のナビゲーションの一部かによって変化します。ユースケースに応じて、個々のルートとデータリクエストのキャッシュ動作を設定できます。

リクエストメモ化

Next.jsはfetch APIを拡張して、同じURLとオプションを持つリクエストを自動的にメモ化します。これは、Reactコンポーネントツリー内の複数の場所で同じデータに対してfetch関数を呼び出しても、実際には一度だけ実行されることを意味します。

例えば、ルート全体で同じデータを使用する必要がある場合（レイアウト、ページ、および複数のコンポーネントなど）、ツリーの上部でデータを取得し、コンポーネント間でプロパティを転送する必要はありません。代わりに、必要なコンポーネントでデータを取得でき、同じデータに対してネットワーク経由で複数回リクエストを行うパフォーマンスへの影響を心配する必要はありません。

async function getItem() {
  // `fetch`関数は自動的にメモ化され、結果がキャッシュされます
  const res = await fetch('https://.../item/1')
  return res.json()
}

// この関数は2回呼び出されますが、最初の1回だけ実行されます
const item = await getItem() // キャッシュ MISS

// 2回目の呼び出しはルート内のどこでも可能です
const item = await getItem() // キャッシュ HIT

リクエストメモ化の仕組み

• ルートのレンダリング中に特定のリクエストが初めて呼び出されると、その結果はメモリに存在せず、キャッシュMISSになります。
• したがって、関数が実行され、外部ソースからデータが取得され、結果がメモリに保存されます。
• 同じレンダリングパス内でのリクエストの後続の関数呼び出しはキャッシュHITになり、関数を実行せずにメモリからデータが返されます。
• ルートのレンダリングが完了し、レンダリングパスが終了すると、メモリが「リセット」され、すべてのリクエストメモ化エントリがクリアされます。

知っておくと便利:

• リクエストメモ化はNext.jsの機能ではなく、Reactの機能です。他のキャッシュメカニズムとの相互作用を示すためにここに含まれています。
• メモ化はfetchリクエストのGETメソッドにのみ適用されます。
• メモ化はReactコンポーネントツリーにのみ適用されます。つまり:
  • generateMetadata、generateStaticParams、レイアウト、ページ、およびその他のサーバーコンポーネント内のfetchリクエストに適用されます。
  • ルートハンドラー内のfetchリクエストには適用されません。これらはReactコンポーネントツリーの一部ではないためです。
• fetchが適さない場合（一部のデータベースクライアント、CMSクライアント、またはGraphQLクライアントなど）、React cache関数を使用して関数をメモ化できます。

期間

キャッシュは、サーバーリクエストのライフタイム中、Reactコンポーネントツリーのレンダリングが完了するまで続きます。

再検証

メモ化はサーバーリクエスト間で共有されず、レンダリング中にのみ適用されるため、再検証する必要はありません。

オプトアウト

メモ化はfetchリクエストのGETメソッドにのみ適用され、POSTやDELETEなどの他のメソッドはメモ化されません。このデフォルトの動作はReactの最適化であり、オプトアウトすることは推奨しません。

個々のリクエストを管理するには、AbortControllerのsignalプロパティを使用できます。ただし、これはリクエストをメモ化からオプトアウトするのではなく、進行中のリクエストを中止します。

const { signal } = new AbortController()
fetch(url, { signal })

データキャッシュ

Next.jsには、サーバーリクエストとデプロイメントを超えてデータ取得の結果を永続化する組み込みのデータキャッシュがあります。これは、Next.jsがネイティブのfetch APIを拡張して、サーバー上の各リクエストが独自の永続的なキャッシュセマンティクスを設定できるようにするため可能です。

知っておくと便利: ブラウザでは、fetchのcacheオプションはリクエストがブラウザのHTTPキャッシュとどのように相互作用するかを示しますが、Next.jsでは、cacheオプションはサーバーサイドリクエストがサーバーのデータキャッシュとどのように相互作用するかを示します。

fetchのcacheおよびnext.revalidateオプションを使用して、キャッシュ動作を設定できます。

データキャッシュの仕組み

• 'force-cache'オプションを持つfetchリクエストがレンダリング中に初めて呼び出されると、Next.jsはデータキャッシュでキャッシュされたレスポンスをチェックします。
• キャッシュされたレスポンスが見つかった場合、即座に返され、メモ化されます。
• キャッシュされたレスポンスが見つからない場合、データソースにリクエストが行われ、結果がデータキャッシュに保存され、メモ化されます。
• キャッシュされていないデータ（cacheオプションが定義されていないか{ cache: 'no-store' }を使用している場合）の場合、結果は常にデータソースから取得され、メモ化されます。
• データがキャッシュされているかどうかに関係なく、リクエストは常にメモ化され、Reactレンダリングパス中に同じデータに対して重複したリクエストが行われないようにします。

データキャッシュとリクエストメモ化の違い

どちらのキャッシュメカニズムもキャッシュされたデータを再利用することでパフォーマンスを向上させますが、データキャッシュは受信リクエストとデプロイメントを超えて永続的であるのに対し、メモ化はリクエストのライフタイム中のみ続きます。

期間

データキャッシュは、再検証またはオプトアウトしない限り、受信リクエストとデプロイメントを超えて永続的です。

再検証

キャッシュされたデータは、次の2つの方法で再検証できます:

• 時間ベースの再検証: 一定時間が経過し、新しいリクエストが行われた後にデータを再検証します。これは、変更頻度が低く、鮮度がそれほど重要でないデータに役立ちます。
• オンデマンド再検証: イベント（フォーム送信など）に基づいてデータを再検証します。オンデマンド再検証では、タグベースまたはパスベースのアプローチを使用して、一度にデータのグループを再検証できます。これは、可能な限り最新のデータを表示したい場合（ヘッドレスCMSからのコンテンツが更新されたときなど）に役立ちます。

時間ベースの再検証

時間間隔でデータを再検証するには、fetchのnext.revalidateオプションを使用してリソースのキャッシュライフタイム（秒単位）を設定します。

// 最大1時間ごとに再検証
fetch('https://...', { next: { revalidate: 3600 } })

または、ルートセグメント設定オプションを使用して、セグメント内のすべてのfetchリクエストを設定したり、fetchを使用できない場合に設定したりできます。

時間ベースの再検証の仕組み

• revalidateを持つfetchリクエストが初めて呼び出されると、データは外部データソースから取得され、データキャッシュに保存されます。
• 指定された時間枠内（例: 60秒）で呼び出されるすべてのリクエストは、キャッシュされたデータを返します。
• 時間枠が経過した後、次のリクエストでもキャッシュされた（現在は古い）データが返されます。
  • Next.jsはバックグラウンドでデータの再検証をトリガーします。
  • データが正常に取得されると、Next.jsはデータキャッシュを新しいデータで更新します。
  • バックグラウンドの再検証が失敗した場合、以前のデータは変更されずに保持されます。

これはstale-while-revalidateの動作に似ています。

オンデマンド再検証

データは、パス（revalidatePath）またはキャッシュタグ（revalidateTag）によってオンデマンドで再検証できます。

オンデマンド再検証の仕組み

• fetchリクエストが初めて呼び出されると、データは外部データソースから取得され、データキャッシュに保存されます。
• オンデマンド再検証がトリガーされると、適切なキャッシュエントリがキャッシュから削除されます。
  • これは、新しいデータが取得されるまで古いデータをキャッシュに保持する時間ベースの再検証とは異なります。
• 次にリクエストが行われると、再びキャッシュMISSになり、データは外部データソースから取得され、データキャッシュに保存されます。

オプトアウト

fetchからのレスポンスをキャッシュしたくない場合は、次のようにします:

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

フルルートキャッシュ

関連用語:

自動静的最適化、静的サイト生成、または静的レンダリングという用語が、ビルド時にアプリケーションのルートをレンダリングおよびキャッシュするプロセスを指すために互換的に使用されているのを見かけることがあります。

Next.jsはビルド時にルートを自動的にレンダリングおよびキャッシュします。これは、すべてのリクエストに対してサーバーでレンダリングする代わりにキャッシュされたルートを提供できるようにする最適化であり、ページの読み込みが速くなります。

フルルートキャッシュの仕組みを理解するには、Reactがレンダリングをどのように処理するか、およびNext.jsが結果をどのようにキャッシュするかを見ることが役立ちます:

1. サーバー上のReactレンダリング

サーバー上で、Next.jsはReactのAPIを使用してレンダリングを調整します。レンダリング作業は、個々のルートセグメントとSuspense境界によってチャンクに分割されます。

各チャンクは2つのステップでレンダリングされます:

1. Reactはサーバーコンポーネントを、ストリーミング用に最適化された特別なデータ形式であるReactサーバーコンポーネントペイロードにレンダリングします。
2. Next.jsはReactサーバーコンポーネントペイロードとクライアントコンポーネントのJavaScript命令を使用して、サーバー上でHTMLをレンダリングします。

これは、作業をキャッシュしたりレスポンスを送信したりする前に、すべてがレンダリングされるのを待つ必要がないことを意味します。代わりに、作業が完了するとレスポンスをストリーミングできます。

Reactサーバーコンポーネントペイロードとは何ですか？

Reactサーバーコンポーネントペイロードは、レンダリングされたReactサーバーコンポーネントツリーのコンパクトなバイナリ表現です。クライアント上のReactがブラウザのDOMを更新するために使用します。Reactサーバーコンポーネントペイロードには以下が含まれます:

• サーバーコンポーネントのレンダリング結果
• クライアントコンポーネントがレンダリングされるべき場所のプレースホルダーとそれらのJavaScriptファイルへの参照
• サーバーコンポーネントからクライアントコンポーネントに渡されるプロパティ

詳細については、サーバーコンポーネントのドキュメントを参照してください。

2. サーバー上のNext.jsキャッシュ（フルルートキャッシュ）

Next.jsのデフォルトの動作は、ルートのレンダリング結果（ReactサーバーコンポーネントペイロードとHTML）をサーバー上でキャッシュすることです。これは、ビルド時に静的にレンダリングされたルート、または再検証中に適用されます。

3. クライアント上のReactハイドレーションと調整

リクエスト時に、クライアント上で:

1. HTMLは、クライアントおよびサーバーコンポーネントの高速な非インタラクティブな初期プレビューをすぐに表示するために使用されます。
2. Reactサーバーコンポーネントペイロードは、クライアントとレンダリングされたサーバーコンポーネントツリーを調整し、DOMを更新するために使用されます。
3. JavaScript命令は、クライアントコンポーネントをハイドレートし、アプリケーションをインタラクティブにするために使用されます。

4. クライアント上のNext.jsキャッシュ（ルーターキャッシュ）

Reactサーバーコンポーネントペイロードは、クライアントサイドのルーターキャッシュに保存されます。これは個々のルートセグメントごとに分割されたメモリ内キャッシュです。このルーターキャッシュは、以前に訪問したルートを保存し、将来のルートをプリフェッチすることで、ナビゲーションエクスペリエンスを向上させるために使用されます。

5. 後続のナビゲーション

後続のナビゲーションまたはプリフェッチ中に、Next.jsはReactサーバーコンポーネントペイロードがルーターキャッシュに保存されているかどうかをチェックします。保存されている場合、サーバーに新しいリクエストを送信するのをスキップします。

ルートセグメントがキャッシュにない場合、Next.jsはサーバーからReactサーバーコンポーネントペイロードを取得し、クライアント上のルーターキャッシュに保存します。

静的 (Static) と動的 (Dynamic) レンダリング

ルートがビルド時にキャッシュされるかどうかは、静的 (static) または動的 (dynamic) にレンダリングされるかによって決まります。静的ルートはデフォルトでキャッシュされますが、動的ルートはリクエスト時にレンダリングされ、キャッシュされません。

この図は、静的および動的にレンダリングされたルートの違いを、キャッシュされたデータとキャッシュされていないデータで示しています:

静的および動的レンダリングについてさらに学ぶ。

期間

デフォルトでは、フルルートキャッシュは永続的です。つまり、レンダリング出力はユーザーリクエスト間でキャッシュされます。

無効化

フルルートキャッシュを無効化する方法は2つあります:

• データの再検証 (Revalidating Data): データキャッシュ (Data Cache) を再検証すると、サーバー上でコンポーネントを再レンダリングし、新しいレンダリング出力をキャッシュすることで、ルーターキャッシュも無効化されます。
• 再デプロイ: デプロイ間で永続化されるデータキャッシュとは異なり、フルルートキャッシュは新しいデプロイ時にクリアされます。

オプトアウト

以下の方法でフルルートキャッシュをオプトアウト（つまり、各受信リクエストごとにコンポーネントを動的にレンダリング）できます:

• 動的API (Dynamic API) を使用: これによりルートはフルルートキャッシュからオプトアウトされ、リクエスト時に動的にレンダリングされます。データキャッシュは引き続き使用可能です。
• dynamic = 'force-dynamic' または revalidate = 0 ルートセグメント設定オプションを使用: これによりフルルートキャッシュとデータキャッシュがスキップされます。つまり、サーバーへの各受信リクエストごとにコンポーネントがレンダリングされ、データがフェッチされます。ルーターキャッシュはクライアントサイドキャッシュであるため、引き続き適用されます。
• データキャッシュ (Data Cache) をオプトアウト: ルートにキャッシュされていない fetch リクエストがある場合、そのルートはフルルートキャッシュからオプトアウトされます。特定の fetch リクエストのデータは、各受信リクエストごとにフェッチされます。キャッシュをオプトアウトしない他の fetch リクエストは、データキャッシュに引き続きキャッシュされます。これにより、キャッシュされたデータとキャッシュされていないデータのハイブリッドが可能になります。

クライアントサイドルーターキャッシュ (Client-side Router Cache)

Next.jsには、メモリ内のクライアントサイドルーターキャッシュがあり、レイアウト、ローディング状態、ページごとに分割されたルートセグメントのRSCペイロードを保存します。

ユーザーがルート間を移動する際、Next.jsは訪問したルートセグメントをキャッシュし、ユーザーが移動する可能性が高いルートをプリフェッチ (prefetch) します。これにより、即時の前後移動、ナビゲーション間のフルページリロードなし、React状態とブラウザ状態の保持が実現されます。

ルーターキャッシュでは:

• レイアウト はキャッシュされ、ナビゲーション時に再利用されます（部分レンダリング (partial rendering)）。
• ローディング状態 はキャッシュされ、ナビゲーション時に再利用され、即時ナビゲーション (instant navigation) を実現します。
• ページ はデフォルトではキャッシュされませんが、ブラウザの前後移動中に再利用されます。実験的な staleTimes 設定オプションを使用して、ページセグメントのキャッシュを有効にできます。

知っておくと良いこと: このキャッシュはNext.jsとサーバーコンポーネントに特化しており、ブラウザの bfcache とは異なりますが、同様の結果をもたらします。

期間

キャッシュはブラウザの一時メモリに保存されます。ルーターキャッシュの持続時間は2つの要素で決まります:

• セッション: キャッシュはナビゲーション間で保持されます。ただし、ページのリフレッシュ時にクリアされます。
• 自動無効化期間: レイアウトとローディング状態のキャッシュは、特定の時間後に自動的に無効化されます。期間はリソースがプリフェッチ (prefetch) された方法と、リソースが静的生成 (statically generated) されたかどうかに依存します:
  • デフォルトのプリフェッチ (prefetch={null} または未指定): 動的ページではキャッシュされず、静的ページでは5分間キャッシュされます。
  • 完全なプリフェッチ (prefetch={true} または router.prefetch): 静的および動的ページの両方で5分間キャッシュされます。

ページのリフレッシュはすべてのキャッシュされたセグメントをクリアしますが、自動無効化期間はプリフェッチされた時点から個々のセグメントにのみ影響します。

知っておくと良いこと: 実験的な staleTimes 設定オプションを使用して、上記の自動無効化時間を調整できます。

無効化

ルーターキャッシュを無効化する方法は2つあります:

• サーバーアクション (Server Action) 内で:
  • パスごとに (revalidatePath) またはキャッシュタグごとに (revalidateTag) オンデマンドでデータを再検証
  • cookies.set または cookies.delete を使用すると、ルーターキャッシュが無効化され、クッキーを使用するルートが古くなるのを防ぎます（例: 認証）。
• router.refresh を呼び出すと、ルーターキャッシュが無効化され、現在のルートに対してサーバーに新しいリクエストが行われます。

オプトアウト

Next.js 15時点では、ページセグメントはデフォルトでオプトアウトされています。

知っておくと良いこと: <Link> コンポーネントの prefetch プロパティを false に設定することで、プリフェッチ (prefetching) をオプトアウトすることもできます。

キャッシュの相互作用

異なるキャッシュメカニズムを設定する際には、それらがどのように相互作用するかを理解することが重要です:

データキャッシュとフルルートキャッシュ

• データキャッシュの再検証またはオプトアウトは、レンダリング出力がデータに依存するため、フルルートキャッシュを無効化します。
• フルルートキャッシュの無効化またはオプトアウトは、データキャッシュに影響しません。キャッシュされたデータとキャッシュされていないデータの両方を持つルートを動的にレンダリングできます。これは、ページの大部分がキャッシュされたデータを使用しているが、リクエスト時にフェッチする必要があるデータに依存するいくつかのコンポーネントがある場合に便利です。すべてのデータを再フェッチするパフォーマンスへの影響を心配することなく、動的にレンダリングできます。

データキャッシュとクライアントサイドルーターキャッシュ

• データキャッシュとルーターキャッシュを即座に無効化するには、サーバーアクション (Server Action) 内で revalidatePath または revalidateTag を使用できます。
• ルートハンドラー (Route Handler) でデータキャッシュを再検証しても、ルートハンドラーが特定のルートに関連付けられていないため、ルーターキャッシュは即座に無効化されません。つまり、ハードリフレッシュが行われるか、自動無効化期間が経過するまで、ルーターキャッシュは以前のペイロードを提供し続けます。

API

次の表は、さまざまなNext.js APIがキャッシュにどのように影響するかをまとめたものです:

<Link>

デフォルトでは、<Link> コンポーネントはフルルートキャッシュからルートを自動的にプリフェッチし、Reactサーバーコンポーネントペイロードをルーターキャッシュに追加します。

プリフェッチを無効にするには、prefetch プロパティを false に設定できます。ただし、これはキャッシュを永続的にスキップするわけではなく、ユーザーがルートを訪問したときにルートセグメントがクライアントサイドでキャッシュされます。

<Link> コンポーネントについてさらに学ぶ。

router.prefetch

useRouter フックの prefetch オプションを使用して、手動でルートをプリフェッチできます。これにより、Reactサーバーコンポーネントペイロードがルーターキャッシュに追加されます。

useRouter フック APIリファレンスを参照。

router.refresh

useRouter フックの refresh オプションを使用して、手動でルートをリフレッシュできます。これにより、ルーターキャッシュが完全にクリアされ、現在のルートに対してサーバーに新しいリクエストが行われます。refresh はデータキャッシュやフルルートキャッシュには影響しません。

レンダリング結果は、React状態とブラウザ状態を保持しながらクライアント側で調整されます。

useRouter フック APIリファレンスを参照。

fetch

fetch から返されるデータは、データキャッシュに自動的にキャッシュされません。

fetch のデフォルトのキャッシュ動作（例: cache オプションが指定されていない場合）は、cache オプションを no-store に設定するのと同じです:

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

その他のオプションについては、fetch APIリファレンスを参照。

fetch options.cache

個々の fetch をキャッシュにオプトインするには、cache オプションを force-cache に設定します:

// キャッシュにオプトイン
fetch(`https://...`, { cache: 'force-cache' })

その他のオプションについては、fetch APIリファレンスを参照。

fetch options.next.revalidate

fetch の next.revalidate オプションを使用して、個々の fetch リクエストの再検証期間（秒単位）を設定できます。これにより、データキャッシュが再検証され、フルルートキャッシュも再検証されます。新しいデータがフェッチされ、コンポーネントがサーバー上で再レンダリングされます。

// 最大1時間後に再検証
fetch(`https://...`, { next: { revalidate: 3600 } })

その他のオプションについては、fetch APIリファレンスを参照。

fetch options.next.tags と revalidateTag

Next.jsには、きめ細かいデータキャッシュと再検証のためのキャッシュタグシステムがあります。

1. fetch または unstable_cache を使用する際に、キャッシュエントリを1つ以上のタグでタグ付けできます。
2. その後、revalidateTag を呼び出して、そのタグに関連付けられたキャッシュエントリをパージできます。

例えば、データをフェッチする際にタグを設定できます:

// タグ付きでデータをキャッシュ
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })

その後、タグを指定して revalidateTag を呼び出し、キャッシュエントリをパージします:

// 特定のタグを持つエントリを再検証
revalidateTag('a')

revalidateTag は、達成したい目的に応じて2つの場所で使用できます:

1. ルートハンドラー (Route Handlers) - サードパーティのイベント（例: Webhook）に応じてデータを再検証するため。ルーターハンドラーは特定のルートに関連付けられていないため、ルーターキャッシュは即座に無効化されません。
2. サーバーアクション (Server Actions) - ユーザーアクション（例: フォーム送信）後にデータを再検証するため。これにより、関連するルートのルーターキャッシュが無効化されます。

revalidatePath

revalidatePath を使用すると、特定のパス以下のルートセグメントのデータを手動で再検証し、再レンダリングを単一の操作で行えます。revalidatePath メソッドを呼び出すと、データキャッシュが再検証され、フルルートキャッシュが無効化されます。

revalidatePath('/')

revalidatePath は、達成したい目的に応じて2つの場所で使用できます:

1. ルートハンドラー (Route Handlers) - サードパーティのイベント（例: Webhook）に応じてデータを再検証するため。
2. サーバーアクション (Server Actions) - ユーザー操作（例: フォーム送信、ボタンクリック）後にデータを再検証するため。

詳細については、revalidatePath APIリファレンスを参照。

revalidatePath と router.refresh の違い:

router.refresh を呼び出すと、ルーターキャッシュがクリアされ、データキャッシュやフルルートキャッシュを無効化せずに、サーバー上でルートセグメントが再レンダリングされます。

違いは、revalidatePath がデータキャッシュとフルルートキャッシュをパージするのに対し、router.refresh() はクライアントサイドAPIであるため、データキャッシュとフルルートキャッシュを変更しないことです。

動的API (Dynamic APIs)

cookies や headers などの動的API、およびページの searchParams プロパティは、実行時の受信リクエスト情報に依存します。これらを使用すると、ルートはフルルートキャッシュからオプトアウトされ、つまりルートは動的にレンダリングされます。

cookies

サーバーアクション内で cookies.set または cookies.delete を使用すると、ルーターキャッシュが無効化され、クッキーを使用するルートが古くなるのを防ぎます（例: 認証変更を反映するため）。

cookies APIリファレンスを参照。

セグメント設定オプション

ルートセグメント設定オプションは、ルートセグメントのデフォルトを上書きする場合や、fetch API を使用できない場合（例: データベースクライアントやサードパーティライブラリ）に使用できます。

以下のルートセグメント設定オプションは、フルルートキャッシュを無効にします:

• const dynamic = 'force-dynamic'

この設定オプションは、すべてのフェッチをデータキャッシュから除外します（つまり no-store）:

• const fetchCache = 'default-no-store'

より高度なオプションについては、fetchCache を参照してください。

その他のオプションについては、ルートセグメント設定 ドキュメントを参照してください。

generateStaticParams

動的セグメント（例: app/blog/[slug]/page.js）の場合、generateStaticParams によって提供されるパスはビルド時にフルルートキャッシュに保存されます。リクエスト時には、Next.js はビルド時に未知だったパスも初回アクセス時にキャッシュします。

ビルド時にすべてのパスを静的にレンダリングするには、generateStaticParams に完全なパスリストを指定します:

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  return posts.map((post) => ({
    slug: post.slug,
  }))
}

ビルド時に一部のパスを静的にレンダリングし、残りを実行時に初回アクセス時にレンダリングするには、部分的なパスリストを返します:

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  // ビルド時に最初の10投稿をレンダリング
  return posts.slice(0, 10).map((post) => ({
    slug: post.slug,
  }))
}

すべてのパスを初回アクセス時に静的にレンダリングするには、空の配列を返す（ビルド時には何もレンダリングされない）か、export const dynamic = 'force-static' を利用します:

export async function generateStaticParams() {
  return []
}

知っておくと良い: generateStaticParams からは、たとえ空であっても配列を返す必要があります。そうしないと、ルートは動的にレンダリングされます。

export const dynamic = 'force-static'

リクエスト時のキャッシュを無効にするには、ルートセグメントに export const dynamicParams = false オプションを追加します。この設定オプションを使用すると、generateStaticParams によって提供されたパスのみが提供され、他のルートは404になるか（キャッチオールルート の場合）マッチします。

React の cache 関数

React の cache 関数を使用すると、関数の戻り値をメモ化でき、同じ関数を複数回呼び出しても一度だけ実行されます。

fetch リクエストは自動的にメモ化されるため、React の cache でラップする必要はありません。ただし、fetch API が適さないユースケース（データベースクライアント、CMSクライアント、GraphQLクライアントなど）でデータリクエストを手動でメモ化する場合に cache を使用できます。

import { cache } from 'react'
import db from '@/lib/db'

export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})