−ゆめログ− | ゆめみスタッフブログ

初めまして、石原です。
モバイル端末において、webページを効率よくキャッシュさせるということは、パケット代の節約や応答性の観点から考えてとても重要なことだと思います。
今回は、コンテンツ内容の検証を毎回行い、変更がない場合はキャッシュを使用させる方法と、注意点について投稿させていただきたいと思います。

はじめに

キャッシュを制御する方法は大きく分けて、METAタグによる制御とHTTPヘッダによる制御の２種類があります。
今回は、HTTPヘッダを使用した制御を行いたいと思います。
HTTPヘッダを使用した制御には、キャッシュの有効期限を定め、有効期限内ならばキャッシュを使用するという期限モデルと、キャッシュサーバがWEBサーバーに条件付きリクエストを行う事でリソースの検証を行い、リソースの変更がされていなければキャッシュを使用するという検証モデルがあります。

今回のケースでいうと、検証モデルを使用したいところなのですが、、、後に記述する問題点の為に、検証モデルと期限モデルの両方を使用します。

ヘッダの種類と注意点

ヘッダは、以下のものを使用します

【検証モデル】
　　　　Last-Modified
　　　　ETag

【期限モデル】
　　　　Cache-Control:max-age=0
　　　　Expiers

Last-ModifiedとETagヘッダを追加すると、２回目以降のアクセスで、If-Modified-SinceとIf-None-Matchという条件付きリクエストを返すようになります。
この条件付きリクエストにより、サーバーにキャッシュを使用するのか、否かという指示を行います。

さて、なぜ期限モデルを使用しなければならないのかというと、auはEtagを使用することができないからです。Last-Modifiedのみで対応しなければなりません。

しかし、Last-Modifiedのみでは、ローカル、またはGW側のキャッシュを参照してしまいます。
そこで、期限モデルを使用して、毎回通信を行うようにするわけです。(max-age=0だけでは不安なので、念のためExpiersも追加します。。)

実際の挙動

それでは、実際の挙動について見ていきたいと思います。
まずは、docomoとSoftBankの初回リクエスト・レスポンスと２回目のリクエスト・レスポンスにを見てみましょう。

ｽﾃｰﾀｽｺｰﾄﾞ：304 が返されるとキャッシュを使用したということになります。  

【docomo】

初回リクエスト

サーバーからの初回レスポンス (ｽﾃｰﾀｽｺｰﾄﾞ：200)

2回目のリクエスト

サーバーからの2回目のレスポンス (ｽﾃｰﾀｽｺｰﾄﾞ：304)

【SoftBank】

初回リクエスト

サーバーからの初回レスポンス (ｽﾃｰﾀｽｺｰﾄﾞ：200)

2回目のリクエスト

サーバーからの2回目のレスポンス (ｽﾃｰﾀｽｺｰﾄﾞ：304)

docomoとSoftBankは２回目からのリクエストでIf-Modified-SinceとIf-None-Matchが追加されている事がわかります。
次にauを見てみましょう。

【au】

初回リクエスト

サーバーからの初回レスポンス (ｽﾃｰﾀｽｺｰﾄﾞ：200)

2回目のリクエスト

サーバーからの2回目のレスポンス (ｽﾃｰﾀｽｺｰﾄﾞ：304)

２回目のリクエストでIf-Modified-Sinceしか送られていませんが、max-age=0(とExpiers)により、無事リクエストしています。

Last-Modifiedだけでキャッシュの使用するか、否かを決める場合は、ファイルの更新日付を参照しています。
ファイルを更新を更新した場合でも、更新日付が変わらない場合(同じ内容を更新した場合など)があるので、注意しましょう。