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

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

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

概要

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

メカニズム	対象	場所	目的	期間
リクエストメモ化	関数の戻り値	サーバー	Reactコンポーネントツリー内でデータを再利用	リクエストライフサイクルごと
データキャッシュ	データ	サーバー	ユーザーリクエストとデプロイメント間でデータを保存	永続的（再検証可能）
フルルートキャッシュ	HTMLとRSCペイロード	サーバー	レンダリングコストを削減しパフォーマンスを向上	永続的（再検証可能）
ルーターキャッシュ	RSCペイロード	クライアント	ナビゲーション時のサーバーリクエストを削減	ユーザーセッションまたは時間ベース

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

Next.jsにおける4つのキャッシュメカニズムのデフォルト動作を示す図。ビルド時とルート初回訪問時のHIT、MISS、SETが表示されています。

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

リクエストメモ化

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

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

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

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

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

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

// この関数は2回呼び出されますが、初回のみ実行されます
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プロパティを使用できます。ただし、これはリクエストをメモ化からオプトアウトするのではなく、進行中のリクエストを中止します。

app/example.js

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

データキャッシュ

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

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

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

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

キャッシュされたおよびキャッシュされていないfetchリクエストがデータキャッシュとどのように相互作用するかを示す図。キャッシュされたリクエストはデータキャッシュに保存され、メモ化されます。キャッシュされていないリクエストはデータソースから取得され、データキャッシュには保存されず、メモ化されます。

'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つのステップでレンダリングされます：

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

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

React Server Component Payloadとは何ですか？

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

サーバーコンポーネントのレンダリング結果

クライアントコンポーネントがレンダリングされるべき場所のプレースホルダーとそれらのJavaScriptファイルへの参照

サーバーコンポーネントからクライアントコンポーネントに渡されるプロパティ

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

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

フルルートキャッシュのデフォルト動作を示す図。静的レンダリングされたルートのReact Server Component PayloadとHTMLがサーバー上でキャッシュされます。

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

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

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

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

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

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

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

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

ルートセグメントがキャッシュにない場合、Next.jsはサーバーからReact Server Components Payloadを取得し、クライアント上のルーターキャッシュを更新します。

静的レンダリングと動的レンダリング

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

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

静的および動的レンダリングがフルルートキャッシュに与える影響。静的ルートはビルド時またはデータ再検証後にキャッシュされ、動的ルートはキャッシュされない

静的および動的レンダリングについて詳しく学ぶ。

期間

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

無効化

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

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

オプトアウト

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

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

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

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

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

ルーターキャッシュにより:

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

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

期間

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

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

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

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

無効化

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

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

オプトアウト

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

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

キャッシュの相互作用

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

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

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

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

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

API

次の表は、異なるNext.js APIがキャッシュにどのように影響するかの概要を示しています:

API	ルーターキャッシュ	フルルートキャッシュ	データキャッシュ	Reactキャッシュ
`<Link prefetch>`	キャッシュ
`router.prefetch`	キャッシュ
`router.refresh`	再検証
`fetch`			キャッシュ	キャッシュ
`fetch` `options.cache`			キャッシュまたはオプトアウト
`fetch` `options.next.revalidate`		再検証	再検証
`fetch` `options.next.tags`		キャッシュ	キャッシュ
`revalidateTag`	再検証（サーバーアクション）	再検証	再検証
`revalidatePath`	再検証（サーバーアクション）	再検証	再検証
`const revalidate`		再検証またはオプトアウト	再検証またはオプトアウト
`const dynamic`		キャッシュまたはオプトアウト	キャッシュまたはオプトアウト
`cookies`	再検証（サーバーアクション）	オプトアウト
`headers`, `searchParams`		オプトアウト
`generateStaticParams`		キャッシュ
`React.cache`				キャッシュ
`unstable_cache`			キャッシュ

`<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には、きめ細かいデータキャッシュと再検証のためのキャッシュタグシステムがあります。

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

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

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

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

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

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

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

`revalidatePath`

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

revalidatePath('/')

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

ルートハンドラー - サードパーティイベント（例: webhook）への応答としてデータを再検証するため。
サーバーアクション - ユーザーインタラクション（例: フォーム送信、ボタンクリック）後にデータを再検証するため。

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

revalidatePath 対 router.refresh:

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

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

動的API

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 に完全なパスのリストを渡します：

app/blog/[slug]/page.js

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

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

ビルド時にパスのサブセットを静的にレンダリングし、残りをランタイム時に初回アクセスでレンダリングするには、部分的なパスのリストを返します：

app/blog/[slug]/page.js

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' を使用します：

app/blog/[slug]/page.js

export async function generateStaticParams() {
  return []
}

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

app/changelog/[slug]/page.js

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
})

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

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

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

On this page