HTTP キャッシュ の 良い点 と 問題点 および 対策

キャッシュ無効化 はすぐにやってしまいがちですが…キャッシュも正しく使いこなせばとても便利な機能だと思います。 正しく使いこなせていないから問題になるのであって、その原因をつきとめ改善できればより良いサービスが構築できる ハズ と個人的には思っています。

問題点を改めて述べるほどでもないとは思いましたが…一応、列挙してみました。 これらの問題が解決できれば、ユーザーは幸せになれる ハズ です。 以下では、それぞれ問題点について少し考察してみます。

新しい情報に書き換わらない 問題

[原因]

レスポンス ヘッダーに Cache-Control、Pragma が正しく設定されていないことが原因。

[対策１]

サーバー側で キャッシュ 無効化 を行います。 具体的にはサーバーからの レスポンス ヘッダー に以下の設定をします。 HTML なら METAタグ で、C# ASP.NET や Java, PHP 等 であればコードで キャッシュ しないことを明示的に指定します。 リクエスト ヘッダー ではないことに注意します。

• Cache-Control: no-cache, no-store
• Pragma: no-cache

[対策２]

クライアント側で キャッシュ 無効化 を行います。 クライアントからサーバーへリクエストする際の URL クエリパラメター に無意味な文字列を付加します。

見られてはいけない情報が見えてしまう 問題

Proxy サーバー、キャッシュサーバー などを利用していると発生する問題。 個人用ページ等が キャッシュサーバー に残ってしまい、他の人がアクセスしたとき別の人の キャッシュ が配信されてしまう問題。

[原因]

レスポンス ヘッダーに Cache-Control が正しく設定されていないことが原因。

[対策]

サーバー側で キャッシュ 無効化 を行います。 サーバーからの レスポンス ヘッダーに以下の設定をします。

• Cache-Control: private, no-store, no-cache, must-revalidate

思うようにキャッシュの良さを享受できない 問題

ロードバランサ、DNSラウンドロビン等を利用しているときに発生する問題。 キャッシュ が効かず、毎回ダウンロードが発生している問題。

[原因]

サーバーが異なると、同じファイルでも異なる ETag が設定されてしまうことが原因。

[対策１]

サーバー側の設定を変更します。 すべてのHTTPサーバーで ETag を明示的に同じにしてしまいます。

• Appache の場合（FileEtag MTime Size）
• IIS の場合

[対策２]

サーバー側の実装を変更します。 具体的には、 ETag を削除し、 Last-Modified および If-Modified-Since を利用するよう実装を変更します。

今回、参考にしたサイトは以下の通りです。

• HTTP Header Fields
• ブラウザキャッシュでパフォーマンス向上―負荷分散装置の落とし穴に注意－
• IPA プロキシキャッシュ対策
• Webサイトの高速化 ルール13　ETagを正しく設定する!

最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！

• Facebook ページ
• twitter