HTTP キャッシュ
過去に取得したリソースを再使用すると、ウェブサイトやアプリケーションのパフォーマンスが大きく向上するでしょう。ウェブキャッシュは遅延やネットワークのトラフィックを削減して、リソースを表示するために必要な時間も短縮します。HTTP キャッシュを使用すると、ウェブサイトの応答性が高まります。
キャッシュの基本
キャッシュしない
Cache-Control: no-store
キャッシュを検証する
キャッシュした複製を渡す前に検証のため、キャッシュは生成元のサーバーにリクエストを送信します
Cache-Control: no-cache
または
Cache-Control: max-age=0, must-revalidate
有効期限
設定期間が過ぎたら、サーバーにリクエストして、リソースをダウンロードします。
Cache-Control: max-age=31536000
キャッシュの検証
Cache-Control: must-revalidate
Last-Modified/If-Modified-Since
リソースのレスポンスのheaderにLast-Modifiedがもらえる
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600
<!doctype html>
…
3600秒に過ぎたら、リソースをまたリクエストして、If-Modified-Since を設定します。
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-Modified-Since: Tue, 22 Feb 2022 22:00:00 GMT
もしリソースは新しくにならなければ、304返して、フロントエンドの方はキャッシュしているリソースを使います。
HTTP/1.1 304 Not Modified
Content-Type: text/html
Date: Tue, 22 Feb 2022 23:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600
ETag/If-None-Match
リソースのレスポンスのheaderにETagがもらえる
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
ETag: "33a64df5"
Cache-Control: max-age=3600
<!doctype html>
…
3600秒に過ぎたら、リソースをまたリクエストして、IIf-None-Match を設定します。
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-None-Match: "33a64df5"
もしリソースは新しくにならなければ、304返して、フロントエンドの方はキャッシュしているリソースを使います。
HTTP/1.1 304 Not Modified
Content-Type: text/html
Date: Tue, 22 Feb 2022 23:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
ETag: "33a64df5"
Cache-Control: max-age=3600
フロントエンドエンジニアはキャッシュのことはあまり気にしなかった → なぜ
デフォルトキャッシュStragegyがあります: Heuristic caching
Js Bundle
- Webpack
- Vite
Webフレームワーク対応してくれます
- Rails
- Laravel
Webサーバー対応してくれます。
- Cloudfront
- CDN
リソースのレスポンスHeaderにキャッシュの設定はなにもない場合、クライアントは自分で判断します。
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2021 22:22:22 GMT
<!doctype html>
…
エンジニアは何もしなくてもキャッシュしてくれます。
Commonのキャッシュ方法
キャッシュしたくない場合、
Cache-Control: no-cache, no-store, must-revalidate
- 例: APIのリクエスト
- 例: index.htmlファイル
リソースを変更するときに、リソースパースを変更します。
# version in filename
bundle.v123.js
# version in query
bundle.js?v=123
# hash in filename
bundle.YsAIAAAA-QG4G6kCMAMBAAAAAAAoK.js
# hash in query
bundle.js?v=YsAIAAAA-QG4G6kCMAMBAAAAAAAoK
- リソースパスが変わったら、クライアントはリクエストを送信して、リソースをダウンロードします。
- フロントエンドのJsビルドライブラリーにはあります。
実際に画像はキャッシュしてくれない問題があります。
S3のpresigned urlを使います。
- S3のpresigned urlは毎回に変わるため、クライアントは毎回にリクエストを送信して画像をダウンロードします。
- 対策は: バックエンドで画像ごとに画像リンクを固定します。バックエンドでS3のpresigned urlにredirectします。
バックエンドで画像リンクがありますが、キャッシュの設定はno-cache, no-store, must-revalidateでした。
- バックエンドのAPIはデフォルトのヘッダーの設定はキャッシュしないため、画像リンクが変わらなくても毎回にリクエストを送信します。
- 対策は画像のリンクのヘッダーはキャッシュしない設定を外します。