【Web技術】キャッシュに関わるHTTPヘッダーについて

強いキャッシュ

基本的にクリアができないキャッシュになるので、HTML、CSS、JS、画像などの静的リソースに適用するのが一般的です。

Expiresヘッダー

リソースのキャッシュをブラウザに指示ができる。絶対日時。この日時を過ぎるまでブラウザはマシン内にキャッシュをします。

デメリット

キャッシュ日時を設定するため、サーバーとクライアントで時間設定がずれている場合にキャッシュ期限が意図通りに正しく設定されない。

Cache-Controlヘッダー

max-ageで指定する。600と指定した場合は600秒クライアントマシンに保持される。これならExpiredの弱点である時刻がずれている件にも対応できます。（ただ、ProxyやCDNを間に挟む構成になっている場合はそこを通過する場合もmax-ageを消費するので注意が必要です。）

ExpiresとCache-Controlの使い分け

どちらも設定されている場合は、Cache-Controlが優先されます。Cache-Controlの方が登場が遅かったので様々なブラウザに対応するためにどちらも対応するという手法が行われてきました。

ただ、モダンブラウザであれば全てCache-Controlには対応しているので現環境だとCache-Controlだけで良くなっています。

無理やりこれらのキャッシュをクリアするには？

画像URLにトークンを付与する手法です。PHPなどのサーバーサイド言語でトークンを付与を自動化する場合がほとんどです。現在日時などを付与します。

弱いキャッシュ

強いキャッシュだと一度ブラウザマシンで有効になるとWebサーバー側でキャッシュをクリアできないので扱いに困る。URLトークンで無理やりクリアできますが、HTMLにはトークンを加えられないので適用できません。その際に、使えるのが弱いキャッシュです。

具体的には、繰り返し変更されるようなリソース（動的リソース）に対して適用するのが一般的です。

HTTP/1.1から導入された「条件付きHTTPリクエスト」を用いることでWebサーバーからキャッシュをクリアできます。

Etagヘッダー

URLのリソースのバージョン（エンティティタグ）をもとにキャッシュ切れか判断します。

適当ですが、Webサーバーはレスポンスヘッダの中に以下のようなEtagを返します。リソースの一意のIDを示しています。

サーバーはこのEtagの値が変わっていなければ同じリソースであるとみなして304を返します。Etagが一致しなかった場合は新しいレスポンスを返します。

Last-Modifiedヘッダー

URLの最終更新日をもとにキャッシュ切れかを判定します。

そのURLのリソースが最後に変更されたのがいつなのか設定します。強いキャッシュのように全くサーバーに再要求しなくなるわけではなく、普通にクライアントからサーバーにリクエストを出した上でサーバー側が判断してキャッシュされていると判断した場合はその信号を小さなレスポンスで返すのでレスポンスサイズと少なくすることが可能です。

条件に合致した場合（キャッシュが残っている場合）にサーバーサイドは304を返します。そうじゃない場合は普通にレスポンスを返します。

EtagとLast-Modifiedヘッダーの使い分け

柔軟な仕組みを活かしたい場合はEtagが良いです。両方使った場合はEtagが優先されます。

理由としてはトークンさえあれば複数の結果をキャッシュできるためです。

ただ、EtagはWebサーバーが分かれている場合などは別々のサーバーで同じコンテンツで別のEtagが生成されないようにするために設計上の考慮が必要になります。