Open2
Stale-While-Revalidateに関するメモ
やましたStale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新
を読んだまとめのメモ①
前提
Webキャッシュの意義
- リソース取得の高速化
- サーバへの負荷を減らす
キャッシュのコントロール方法
- 保持するキャッシュを利用する
-
Cache-Control+max-age：期限を期間で指定 -
Expires：期限を日付で指定
-
- サーバにキャッシュの有効性を問い合わせる
-
ETag：ローカルキャッシュとサーバ上のオリジナルコンテンツが一致するかどうか判断するための識別子 -
Last-Modified：サーバ上のコンテンツの最終更新日時
-
現状のキャッシュの仕組みの問題
キャッシュが切れるまでサーバが介入できない
バグがあっても更新できない、など。
対応としてクエリ文字列を利用したURLのコンテンツをキャッシュさせ、更新があったらクエリ文字列を書き換える、といった運用をする必要がある。
※ URL単位でキャッシュされるため
リソースのURLを含むコンテンツ自体がキャッシュされると更新できない
上記のクエリ文字列対応も、その文字列を含むコンテンツ（要はHTMLなど）がキャッシュされてしまうと、クエリ文字列そのものが書き換わらなくなりキャッシュが更新されなくなる。
設定が難しい
設定に対して慎重になりすぎるとキャッシュされないし、大胆に設定してしまうとキャッシュが更新されなくなる。
やましたStale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新
を読んだまとめのメモ②
Stale-While-Revalidate（SWR）とは
仕組み
-
Cache-Controlの拡張 - キャッシュから表示する
- が、裏で非同期にキャッシュを更新しておく
キャッシュは使いたい、が、なるべく鮮度の高いリソースを返したい、というニーズに応える仕組み。
Stale（古くなったもの）-While（〜の間）-Revalidate（再検証）ということなので、「再検証している間は古いキャッシュを返す」って認識でいい気がする。
SWRの戦略（≒ 指定できるディレクティブ）
-
stale-while-revalidate：指定された期間に行われるキャッシュの再検証中は古いキャッシュを返す -
stale-if-error：指定された期間にネットワークエラーがあった場合古いキャッシュを返す
ディレクティブ利用例
キャッシュが古くなったらサーバにリソースの鮮度を問い合わせ、キャッシュを更新する
Cache-Control: max-age=3600, stale-while-revalidate=360
- 取得後
max-ageで指定した時間経過する - キャッシュがstaleとなる
- そこから
stale-while-revalidateでした時間はそのstaleなキャッシュを引き続き使用する - staleなキャッシュが利用されたら裏でサーバのリソースの鮮度を確認する
- サーバから新しいリソースを取得したらキャッシュを更新する
サーバのリソース取得時にエラーがあった場合は引き続きキャッシュを利用する
Cache-Control: max-age=3600, stale-if-error=360
- まず1つ前の例と同様、
max-ageで指定した時間経過するとキャッシュがstaleとなる - staleなキャッシュが利用されたら裏でサーバのリソースの鮮度を確認する
- リソース取得に失敗する
-
stale-if-errorで指定した時間はstaleなキャッシュを引き続き使用する