【Web技術】Cache-Control調査

静的コンテンツへの指定例

サイトA

36日半の指定

must-revalidate

キャッシュは期限が切れたからといって必ず再取得が行われるわけではないです。ただ、このオプションを使えば強制的にキャッシュの再取得を行わせることができます。「キャッシュの期限が切れたら再検証を行う」という意味になります。

next.jsの静的コンテンツ

next/imageの画像以外の静的コンテンツは以下の設定になる。（jsやcssなど）

immutable

キャッシュしたオブジェクトが変更されないという意味になります。なので、後からキャッシュの期限を短めに変更するなどしてキャッシュを変更することができなくなります。（再度新しいデータを取得したければ新しいURLを取得してくださいねというという意味になる。）

next/Image

キャッシュされないようにしている。ただ、ETagで弱いキャッシュが使われていて画像の差し替えがない限りは304が返るので通信量が減るというような設定になっている。

public, max-age=0, must-revalidate

個人情報を含むAPIなどでキャッシュさせない場合（ログイン後のマイページのフェッチングなど）

サイトA

next/Image

個人情報を含む場合は他人にデータが漏洩するとまずいのでWebサーバーやCDNのCache-Contorlでキャッシュしないようにしますが、React-Queryなどのクライアントサイドのキャッシュ機構を使えば同じようにキャッシュができるので強い整合性が必要のないページであれば活用してみても良いです。

主に個人情報を含まないが、整合性がそこまで強くなくてもよいページの場合(例：ブログ内容、商品一覧など誰が見ても検索結果が同じもの)

初回リクエストでは最新データを表示、10秒間は何度更新しても古いデータになる。11秒以降にアクセスすると、新しいキャッシュが作られる。その次のアクセスで最新になる。

86400秒（1日）で自動的にキャッシュは破棄される。

なので1日の間は数時間とかアクセスの間隔が空いたとしても数時間前にアクセスしたデータでページを表示させることができます。

Next.jsのstale-while-revalidateをRailsやLaravelなど他のフレームワークでも実現できます。（ただ、Next.jsのSG+ISRの方が、SSRやRailsやLaravelなどの毎回動的生成に比べたら描画は遅くなる。）

個人情報を含まないAPIフェッチ

その際もサーバー側でCache-Controlを設定してコントロールは可能です。画面ごとにキャッシュを細かくコントロールしたい場合もあるかとは思います。

その場合は、React-QueryやSWRなどでローカルでキャッシュコントロールができるライブラリが最近はあるので検討することになります。（ただ、その場合サーバーで設定されているCache-Controlのキャッシュと競合しないようにする必要があります。基本的にAPI作る際は個人情報のあるなしに限らずキャッシュしないことにしている現場が多いと思うのでそこまで心配はないかもしれませんが。）