👏

ブラウザのキャッシュについて

2022/11/16に公開約1,600字

概要

ブラウザのキャッシュの挙動で困ったので調べてみました。
既存の記事のまとめみたいな記事です。
詳細は参考に張った記事を参照してください。

強いキャッシュ

以下のヘッダーが指定された場合、ブラウザ側でリソースを保持し、期限が来れるまでサーバーにHTTPリクエストを発行しない。
そのため、ブラウザにキャッシュされるとサーバー側からハンドリングできない。

  • Cache-Controlヘッダー
  • Expiresヘッダー

弱いキャッシュ

以下のヘッダーが指定された場合、リソースが更新されているかどうかチェックされる。更新されていなければブラウザはキャッシュされているリソースを再利用する。
そのため、ブラウザにキャッシュされても、サーバー側でハンドリングできる。

  • Last-Modifiedヘッダー
  • ETagヘッダー

Cache-Control

max-age

その期間キャッシュを保持する。

no-cache

キャッシュがあっても更新を確認する。弱いキャッシュに近い。

no-store

キャッシュを一切保持しない。

指定なし

ブラウザによって挙動は異なるが、キャッシュされる可能性がある。
Google Chromeでは、 Last-Modifiedヘッダの日時とDateヘッダの日時の差の10%の値を有効期間として定める というやり方で算出している。
リソースの変更がない期間が長くなるほどキャッシュの有効期限が長くなる。

ETag

強いETagと弱いETag

「強いETag」と「弱いETag」がある

"123456789"   -- 強いETag値
W/"123456789"  -- 弱いETag値

強いETagの場合、バイト単位で同じであれば同じとみなされる。
弱いETagの場合、バイト単位では同じでなくても意味的に同等であれば同じとみなされる。

また、Range Requestの場合、弱いETagは使うことができない。

CloudFrontを利用する場合、オブジェクトを圧縮する際に、強いETagから弱いETagに変換される。

Cache-Controlの指定

Cache-Controlの指定がなければ、ETagの検証をしてくれない。
no-cache、または、must-revalidateなどを指定して、検証させる必要がある。

参考

https://christina04.hatenablog.com/entry/2017/06/23/190000
https://christina04.hatenablog.com/entry/2017/06/23/195318
https://zenn.dev/kawakawaryuryu/articles/75af6ae44d2939
https://ja.wikipedia.org/wiki/HTTP_ETag#強いETag値と弱いETag値
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html#compressed-content-cloudfront-etag-header
https://blog.redbox.ne.jp/http-header-tuning.html
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control

Discussion

ログインするとコメントできます