Next.js × WordPress REST API でキャッシュする・しないを理解する

WordPress をヘッドレス CMS として使い、Next.js でフロントを作るとき、REST API から記事を取得する場面はよくあります。
ただし、API を叩くときの キャッシュ設定 によって、ユーザーに見える記事の鮮度やパフォーマンスが大きく変わります。
今回は、Next.js でのデフォルト挙動と、{ next: { revalidate } } を使った ISR（Incremental Static Regeneration）の違いを解説します。

デフォルトキャッシュの挙動

const res = await fetch("http://host.docker.internal:8000/wp-json/wp/v2/posts?_embed");

何も指定しない場合、Next.js はビルド時に API を取得してキャッシュします。
つまり、ページをリロードしても新しい記事は反映されません。開発中に記事を追加しても見えないのはこのためです

キャッシュなしで毎回取得

const res = await fetch("http://host.docker.internal:8000/wp-json/wp/v2/posts?_embed", { cache: "no-store" });

キャッシュを無効化すると、毎回 WordPress API にリクエストして最新記事を取得します。メリットは常に最新データが取得できますが、デメリットはアクセス数が増えると API サーバーへの負荷が高くなる、ページ表示がやや遅くなります。

ISR（Incremental Static Regeneration）でバランスを取る

const res = await fetch(
  "http://host.docker.internal:8000/wp-json/wp/v2/posts?_embed",
  { next: { revalidate: 60 } } // 60秒ごとに更新
);

初回アクセス時に API を取得してキャッシュし、その後 60 秒経過後に最初にアクセスしたタイミングでバックグラウンド更新します、メリットは、ユーザーに高速なレスポンスを提供することとAPI 負荷を軽減することです。デメリットは指定秒数は古いキャッシュが表示されることです。

まとめ

Next.js はデフォルトで ビルド時キャッシュ が効くため、更新が反映されない場合があります。毎回最新にしたい場合は cache: "no-store"、バランスよく運用するなら next: { revalidate } を使った ISR が便利です。ブログ記事やコーポレートサイトなら ISR（数分〜数十分キャッシュ）が最も使いやすく、ニュースサイトや速報系ならキャッシュなしが適しています。更新頻度や運用ポリシーに合わせて適切な方法を選びましょう。