Next.js/レンダリング/Lesson 05
データフェッチング — fetchのキャッシュポリシー4種 + revalidate
35分·theory
このチャプター
2/5
TypeScript
データフェッチング — fetchのキャッシュポリシー4種 + revalidate
💡 なぜ学ぶのか? — 「キャッシュポリシー」がページ速度を決める
🎯
Pages Router の `getStaticProps`(SSG)・`getServerSideProps`(SSR)・ISR のオプションがすべて **fetch の単一オプション** に統合されました。
💼
fetch が自動的に重複排除・キャッシングされるため、「同じデータを複数のコンポーネントから呼び出すと非効率」という従来の懸念がなくなりました。
⚡
`revalidate`(時間ベース)と `tags`(手動無効化)の組み合わせにより、ページごとにデータの鮮度ポリシーを正確に設定できます。
🔗
これを理解していないと、すべてのページがデフォルトで SSG としてキャッシュされ「新しい記事を書いたのに表示されない」という問題が起きたり、逆に `no-store` を多用してサーバー負荷が増加したりします。
🏢 실무에서는
codemaster40 の学習コンテンツはほとんど変更されないため、SSG(`force-cache`)が適しています。一方、ユーザーの進捗やブックマークはユーザーごとに異なり頻繁に変わるため `no-store` が適切です。掲示板やコメントのようなコンテンツは、1〜5分の `revalidate` がバランスの取れた選択肢です。この判断を fetch の呼び出し単位で行えることが、App Router の大きな強みです。
fetchのキャッシュポリシー4種 + revalidateの方法
1. デフォルト — force-cache (SSG)
高速ですが、データが変わっても反映されません。ほぼ変化しないデータに適しています。
2. no-store (SSR)
常に最新。ユーザーごとのデータ・リアルタイム価格・在庫など、リクエストのたびに新鮮さが求められるデータに最適。
3. revalidate (ISR — Incremental Static Regeneration)
キャッシュの高速性と新鮮さを両立。ブログ・ドキュメント・頻繁には変わらないが時々更新されるコンテンツに最適。
4. tags + revalidateTag (手動無効化)
突発的な更新(記事公開直後など)に最適。ISR + tagsが実務の標準的な組み合わせ。
5. パス単位の無効化 — revalidatePath
6. まとめ — いつ何を使うか
💡 💡 Next.jsデータフェッチング 実践5選
1. デフォルトはforce-cache — 指定しなければキャッシュされる
ビルド時にfetchして永続キャッシュ。データが変わっても表示が更新されない原因の第1位。
2. revalidate時間の決め方のヒューリスティック
- ▸コンテンツが1分に1回未満しか変わらない → 60
- ▸1時間に数回 → 300
- ▸ほぼ変わらない → 3600以上または無制限(force-cache + tags)
3. tagsとrevalidateTagの組み合わせが最も強力
記事の作成・編集・削除アクションでrevalidateTag('posts')の一行だけで関連キャッシュをすべて無効化。
4. 同じURLは自動的に重複排除 — 呼び出し回数を気にしなくてOK
同じレンダリング内で複数のコンポーネントがfetch('/api/me')を呼んでも、実際のネットワークリクエストは1回だけ。
5. cookies()やheaders()を呼び出すと自動的にdynamicになる
fetchのキャッシュモードに関係なく、ページがdynamicモードに切り替わります。
⚡ 実際に試してみよう — キャッシュポリシーシミュレーター
各fetchのキャッシュポリシーがページの新鮮さにどう影響するかをシミュレーションします。
✏️ JS 코드
📟 コンソール出力
▶ 実行ボタンを押してください
⚠️ ブラウザのサンドボックスで実行 — console.log()のみ対応、alert/fetchは不可
確認クイズ
Next.js App Routerで`fetch(url)`(オプションなし)を呼んだときのデフォルトのキャッシュ動作は何ですか?
先に読むとよい概念: Server Component — DB直接アクセス、0KBバンドル