Cache-Controlとは? | キャッシュの概要

Webサイトのキャッシュ動作を管理するCache-Controlは、ローカルに保存されているリソースを更新する頻度をブラウザーに知らせます。

学習目的

この記事を読み終えると、以下のことができるようになります。

  • キャッシュ制御を定義する
  • ブラウザーキャッシングを説明する
  • いくつかのCache-Controlディレクティブを概説する

関連コンテンツ


さらに詳しく知りたいとお考えですか?

是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください!

当社がお客様の個人データをどのように収集し処理するかについては、Cloudflareのプライバシーポリシーをご確認ください。

記事のリンクをコピーする

Cache-Controlとは?

Cache-Controlとは、ブラウザーのキャッシュ動作を管理するHTTPヘッダーのことです。簡単に言えば、誰かがWebサイトを訪問すると、ブラウザーはキャッシュと呼ばれるストアに画像やWebサイトデータといった特定のリソースを保存します。そのユーザーが同じWebサイトを再度訪問すると、Cache-Controlは、そのユーザーにローカルキャッシュからリソースを読み込ませるか、またはブラウザーがサーバーに新しいリソースを要求する必要があるかを決めるルールを設定します。Cache-Controlをより深く理解するには、ブラウザキャッシュおよびHTTPヘッダーの基本を理解する必要があります。

ブラウザーキャッシュとは?

前述のように、ブラウザーキャッシュは、WebブラウザーがWebサイトのリソースを保存することで、サーバーから再度取得しなくても済むようにするものです。たとえば、Webサイトの背景画像はキャッシュにローカルに保存されるため、ユーザーがそのページを再度訪問したときに、画像はユーザーのローカルファイルから読み込まれるのでページ読み込み速度はずっと速くなります。

そうしたリソースをブラウザーはTime To Live(TTL)と呼ばれる一定期間だけ保存します。ユーザーがTTLの期限が切れた後でキャッシュされたリソースを要求した場合、ブラウザーはサーバーに再度アクセスしてリソースの新しいコピーをダウンロードしなければなりません。ブラウザーとWebサーバーは、各リソースのTTLをどのように見分けるのでしょうか?ここで登場するのがHTTPヘッダーです。

HTTPヘッダーとは?

Hypertext Transfer Protocol(HTTP)は、World Wide Web上の通信方法を示すものです。この通信は、クライアントからサーバーへのリクエストとサーバーからクライアントへのレスポンスで構成されます。こうしたHTTPリクエストとHTTPレスポンスには、ヘッダーと呼ばれる一連のキーと値のペアが追加されます。

こうしたヘッダーには、各通信に関する重要な情報が含まれています。たとえば、リクエストヘッダーには次のような情報が含まれていることが多いです:

  1. 要求されているリソースに関する情報
  2. クライアントが使用しているブラウザー
  3. クライアントが受け入れるデータ形式

レスポンスヘッダーには次のような情報が含まれていることが多いです:

  1. リクエストが正常に処理されたかどうか
  2. レスポンスの本文にあるリソースの言語と形式。

Cache-Controlヘッダーは、HTTPリクエストとHTTPレスポンスの両方に使用できます。

Cache-Controlヘッダーとは?

ヘッダーは、コロンで区切られたキーと値のペアで構成されます。Cache-Controlヘッダーの場合、コロンの左側の部分である「キー」は常に「cache-control」です。コロンの右側の部分にあるのが「値」であり、キャッシュ制御のために1つまたは複数のコンマで区切られた値がある場合があります。

Cache-Controlヘッダーの例

ディレクティブ(指示)と呼ばれるこうした値は、リソースをキャッシュできるユーザーと、更新が必要になる前にリソースをキャッシュできる期間を指定します。以下では、最も一般的なCache-Controlディレクティブについて説明します:

cache-control: private

「private」ディレクティブを含むレスポンスは、クライアントのみがキャッシュでき、CDNやプロキシのような仲介エージェントは決してキャッシュできません。多くの場合、これらは、ユーザーの個人情報を表示するWebサイトのようにプライベートデータを含むリソースです。

Cache-Control: public

逆に、「public」ディレクティブは、リソースを任意のキャッシュに保存できることを意味します。

Cache-Control: no-store

「no-store」ディレクティブを含むレスポンスは、キャッシュに保存することが許可されません。つまり、ユーザーがこのデータを要求するたびに、新しいコピーを取得するためにリクエストをオリジンサーバーに送信しなければなりません。通常、このディレクティブは、銀行口座情報のような非常に機密性の高い情報を含むリソース用です。

cache-control: no-cache

このディレクティブは、更新されたバージョンがあるかどうかを確認してからでないと、要求されたリソースのキャッシュされたバージョンを、使用できないことを意味します。通常、この確認はETagを使用して行われます。

ETagは、要求された時点のバージョンに固有のトークンを含むもう一つのHTTPヘッダーです。このトークンは、リソースが更新されるたびに、オリジンサーバーで変更されます。

ユーザーが「no-cache」リソースのあるページに戻ると、クライアントは必ずオリジンサーバーに接続して、キャッシュされたリソースのETagとサーバー上のそれを比較しなければなりません。2つのETagsが同一である場合は、キャッシュされたリソースがユーザーに提供されます。同一でない場合は、リソースが更新されたことを意味するので、クライアントは新しいバージョンをダウンロードしてユーザーに提供する必要があります。このプロセスを行うことで、ユーザーは不要なダウンロードをせずに、そのリソースの最新バージョンを常に取得することができます。

cache-control: max-age

このディレクティブは、ダウンロード後にキャッシュからリソースを提供できる秒数、つまり寿命を指示します。たとえば、最大寿命が1800に設定されている場合、リソースをサーバーに最初に要求してから1,800秒(30分)の間、ユーザーには後続のリクエストでそのリソースのキャッシュされたバージョンが提供されます。ユーザーが30分経過後に、そのリソースを再度要求した場合、クライアントはオリジンサーバーに新しいコピーを要求しなければなりません。

キャッシュ制御:s-maxage

「s-maxage」ディレクティブは、CDNのような共有キャッシュ専用のものであり、その共有キャッシュがキャッシュからリソースを提供し続けることができる期間を指示します。このディレクティブは、個々のクライアントの「max-age」ディレクティブをオーバーライドします。

キャッシュ制御が重要な理由

ブラウザーキャッシングは、リソースを保存してインターネット上のユーザー体験を向上させる優れた方法ですが、キャッシュを制御しないと、非常に脆化する恐れがあります。すべてのサイトのすべてのリソースは、同じキャッシュルールに制約されています。つまり、機密情報は公開情報と同じ方法でキャッシュされ、頻繁に更新されるリソースは、めったに変更されないリソースと同じ期間だけキャッシュされます。

キャッシュ制御は、ブラウザーのキャッシュが真に有用になり、開発者が各リソースのキャッシュ方法を決定できるようにする柔軟性を追加します。また、開発者は仲介者に関する特別なルールを設定することができます。これは、Cloudflare CDNのようなCDNを使用するサイトが、CDNを利用しないサイトよりも高いパフォーマンスを示す傾向がある理由とされています。