はじめに

この記事は、React Tokyo アドベントカレンダーの20日目の記事です。

Data Cache、Full Route Cache、Router Cacheがそれぞれどのように連動して今作っているものが動いているのか？明確に意識してNext.jsを触れていますか？この場合どうなるの・・・？これは・・・？と？が飛びまくっている日々をしばし過ごしていたので、今回はNext.jsのキャッシングがどのように構成されているのか、について、日本昔ばなしの桃太郎に例えながら、楽しくまとめてみます。

公式ドキュメントを見たい方はこちら（桃太郎はでてきません）

この記事で触れないこと

レンダリングの仕組み
RSC Payloadって？
Prefetchの詳細な動作（よかったら別記事でまとめたのでご覧ください）

登場人物

Next.jsのキャッシングを理解するうえで、まずは登場人物から紹介します。

Data Cache
Full Route Cache
Router Cache

この3人があなたのオトモです。こちらに加えて、

Request Memoization
Data Source

というおじいさんおばあさんがいるイメージです。

そして、

Prefetchが連動
cacheオプションで挙動制御ができる

という鬼が出てきます。

Data Cache、Full Route Cache、Router Cacheはそれぞれ出身やスキルが異なります。そして、あなたが出会った時、こんな持ち物を持っていたそうです。

	Data Cache	Full Route Cache	Router Cache
出身	サーバー	サーバー	クライアント
スキル	fetch単位のCache管理	サーバー側のルート単位のCache管理	クライアント側のルート単位のCache管理
持ち物	サーバーからのレスポンスデータ	RSC Payload・HTML	RSC Payload

そして、これを適材適所であなたは配置を指示しました。するとこうなったそうです。

どうですか？お三方を好きになれそうですか？でも、鬼退治にいくなら、おじいさんとおばあさんのサポート、欲しいですよね。

そこで準備のために、おじいさんはサーバーに、おばあさんはおじいさんが持ってきたデータを関数というカゴベースで管理をしてあげることにしました。なんでおじいさんはサーバーに行ったのかって？桃はサーバーから流れてくるからです。

最強の布陣ができあがりました。これでようやく鬼退治に向かうことができそうです。

サーバーサイドからクライアントサイドに向かって、あなたは今一度、フォーメーションを確認します。

それぞれが持つ役割と配置

Data Source

Data SourceはNext.jsやReactの機能とかではなく、fetch先のデータソースそのものです。

おじいさんは、あなたがおばあさんにお願いしたリクエストをおばあさんから受け取って、データを取得して返すんだと思ってください。

Data Cache

Data CacheはData Sourceが返した生のデータを保管します。おじいさんの一番そばでおじいさんが渡してきたデータを持ち帰れるようにきれいにカゴにいれるイメージです。

Request Memoization

Request Memoizationは同じくData Sourceから受け取った生のデータをインメモリベース・fetch単位で保管します。その場限りなので、セッションが変わればリセットされます。おばあさんはおじいさんから受け取ったデータを管理するんでしたよね。そう、おばあさんはfetch単位でメモ化を担当しているのです。

(もしくは、あなた:「おばあちゃん、きびだんご、もうなくなったから、もう一回ちょうだい。」→ おばあさん:「ええ！？さっきあげたでしょ！？もう作り直さないわよ！」という動きをイメージした方が正確かもしれない)

※このメモ化はNext.jsの機能ではなく、Reactの機能です。なのでお三方ではなくおばあさんにお願いしました。

また、この時にレンダリングの動作として、動的レンダリングの場合はRSC payloadとHTMLを、静的レンダリングの場合はRSC payloadのみを生成します。

Full Route Cache

Full Route Cacheは生成されたRSC payloadやHTMLを保管します。

同じルートのリクエストが来た際に、保管してあるRSC payloadやHTMLがあれば、それ以上サーバー側にリクエストを渡さずにクライアントサイドへ返します。ルート単位での管理ですね。

静的ルートの場合は、ビルド時に生成されたRSC payloadがここに保管されます。

Router Cache

Router Cacheは唯一クライアントサイドを守る存在で、インメモリベースRSC Payloadを保管します。インメモリベースなので、Request Memoizationと同じく、セッションが変わればリセットされます。

これもルート単位での管理です。

イメージしてみよう

Next.jsでは、これらのキャッシュが連動して、可能な限り再利用することでパフォーマンスを最大化してくれます。
例えば、静的ルートで最もこれらのキャッシュが活用されるケースを考えてみましょう。
クライアントサイドでナビゲーションが発生し、静的レンダリングとなる /exampleのパスにアクセスしようとしたときは以下のような動きになります。

Router Cache（クライアント側）にRSC Payloadがあるか確認。
あれば、それを即座に使用して即座にページを更新（サーバーへのリクエストなし）。
ない場合は、サーバーにRSC Payloadをリクエストする。
サーバー側でFull Route CacheにRSC Payload（と初回用のHTML）がキャッシュされているか確認する。
あれば、それをクライアントに返し、受け取ったRSC PayloadをRouter Cacheに保存して使用する。
Full Route Cacheにない場合、サーバー側でルートをレンダリングする。
この時、データ取得も必要ならData Cacheに生データがキャッシュされているかを確認し、あればそれを使用。
なければData Source（外部APIなど）に問合せて、新しいデータを取得、Data Cacheに保存して使用する。
レンダリング結果としてRSC PayloadとHTMLを生成し、クライアントに返却。
クライアントはこれをRouter Cacheに保存して次回以降のナビゲーションで再利用できるようにする。

なお、Request Memoizationは？おばあさんどこいったの！？と思うかもしれません。
思い出してください。おじいさんやおばあさんは、あくまでサポート役なのです（おじいさん役のData Sourceもあくまで外部のものであるという見方）。
Rquest Memoizationは同じfetchリクエストが複数あった場合に自動で重複を防ぐ（メモ化する）Reactの仕組みでした。
なので、このフローには直接含まれない、あくまでサポートするだけ、と整理するとよいと思います。

注意事項

ただし、ここまでの内容は静的レンダリングなのか、動的レンダリングなのか、また最後に出てくるcacheオプションの設定状況で挙動が細かく異なります！

Full Route Cacheは動的レンダリングの場合、デフォルトではSkipされてData CacheやData Sourceを見に行く挙動になりますし、dynamic = 'force-dynamic'またはrevalidate = 0オプションが使用されている場合はFull Route CacheとData Cacheがスキップされたりします。

ここまでで、なんとなくイメージができてきたら、公式ドキュメントをもう一度見てみることをお勧めします。ちょっとだけでも理解の助けになっていれば嬉しいです。

鬼退治に行く

さて、最後に鬼退治に行きましょう。冒頭で、下記の2つがあるという話をしました。

Prefetchが連動
cacheオプションで挙動制御ができる

Prefetchが連動する部分

まずはPrefetchとの連動について。ここではRoute Cache＆静的ルートの組み合わせが関係してきます。

静的ルートでは全ルートがPrefetchの動作対象となりますが、この時、Route CacheにRSC Payloadがあるのかを確認しています。

RSC Payloadがあれば、リクエストが実際に発生した際に即座にそのデータを返すことで素早くページを表示します。

cacheオプションにより挙動を制御できる

cacheオプションの設定内容によって、レンダリングの扱いが変わります。つまりキャッシュの挙動がここで変わってくるということです。

具体的にはData Cache、Full Route Cacheに関係してきます。

オプション指定	レンダリング	Data Cache	Full Route Cache（HTML / RSC）	補足
fetch(url, { cache: 'force-cache' })	静的レンダリング寄り（SSG相当）	使う（永続・再利用）	有効になりやすい（※）	デフォルトでキャッシュされるfetchの代表例。ルート側で dynamic = 'force-dynamic' 等を指定すると、ルート自体は動的にもできる。
fetch(url, { next: { revalidate: N } })（N > 0）	ISR（静的 + 再検証）	使う（期限付きで再検証）	有効（再検証単位で更新）	Data Cacheが再検証されると、結果的にルートのRSC/HTML（Full Route Cache）も再生成される。
fetch(url, { cache: 'no-store' })	動的レンダリング（SSR相当）	使わない	基本スキップ（※）	毎リクエストでデータ取得 → RSC/HTMLを再生成する方向になる。
fetch(url, { next: { revalidate: 0 } })	動的レンダリング（SSR相当）	使わない	基本スキップ（※）	「常に最新」指定。cache: 'no-store' と同じイメージでOK。

※ここで、「有効になりやすい」とか「基本スキップ」と書いているのは、Full Route Cache は「fetch の cache オプション単体で決まる」というより、最終的にそのルートが「静的にできるか/できないか」で決まるという意図です。
　例えば、fetch(..., \\{ cache: 'force-cache' \\}) を書いていても、ルート側で dynamic = 'force-dynamic' を指定したり、cookies() や headers() を使ったりしていると、そのルートは動的レンダリング扱いになり、結果として Full Route Cache は使われなくなるという状態になります。
　なので、まずはそのルートが静的なのか動的なのかを切り分けたのち、chacheオプションを使った場合にキャッシングがどうなるのか、という順序で考えるとスムーズかもしれません。

最後に

鬼退治、成功しましたか？（逆にややこしくなってたらすみません・・・）

自身まだまだですが、調べながらまとめたこの記事を自分でも見返しながら使っていこうと思います！
あと、ドキュメント見ながらまとめてますが、もし間違ってるところあればぜひご指摘いただきたいです＞＜

それでは、また！

HTNCode