HTTP
HTTPレスポンスのキャッシュ
サーチ…
備考
レスポンスは、URLとHTTPメソッドごとに個別にキャッシュされます。
HTTPキャッシングはRFC 7234で定義されています 。
用語集
- まだ有効期限切れではないキャッシュされた応答の新鮮な状態。通常、新鮮なレスポンスは、レスポンスが発信されたサーバに接続する必要なしにリクエストを満たすことができます。
- 失効 - 有効期限を過ぎたキャッシュ応答の状態。通常は、無効な応答を使用して、サーバーがまだ有効かどうかを確認せずに要求を満たすことはできません。
- 満足 -キャッシュされた応答は、要求内のすべての条件がキャッシュされたレスポンスと一致する要求を満たし 、例えば、それらが同じHTTPメソッドとURLを持っている、応答が新鮮であるか、要求が古くなったレスポンスを可能にする、リクエストヘッダは応答の中で列挙されたヘッダが一致し
Vary
など、ヘッダーを。 - 再検証 - キャッシュされた応答が新鮮であるかどうかをチェックする。これは、通常、
If-Modified-Since
またはIf-None-Match
および応答ステータス304
を含む条件付き要求で行われます。 - 単一のユーザのためのプライベートキャッシュ - キャッシュ、例えばウェブブラウザ。プライベートキャッシュには、パーソナライズされた応答を格納できます。
- パブリックキャッシュ - 多くのユーザー間で共有されるキャッシュ(プロキシサーバーなど)このようなキャッシュは、複数のユーザーに同じ応答を送信できます。
1年間全員のキャッシュ応答
Cache-Control: public, max-age=31536000
public
は、応答がすべてのユーザーに対して同じであることを意味します(個人化された情報は含まれません)。 max-age
は現在から秒単位です。 31536000 = 60 * 60 * 24 * 365。
これは決して変更するつもりのない静的資産にお勧めします。
パーソナライズされた応答を1分間キャッシュする
Cache-Control: private, max-age=60
private
は、リソースを要求したユーザーに対してのみ応答をキャッシュできることを指定し、他のユーザーが同じリソースを要求したときには再利用できません。これは、Cookieに依存するレスポンスに適しています。
最初にサーバーで確認せずにキャッシュされたリソースの使用を停止する
Cache-Control: no-cache
クライアントは、応答がキャッシュされていないかのように動作します。これは、いつでも予期せず変更される可能性のあるリソースや、最新のバージョンで常に表示される必要のあるリソースに適しています。
no-cache
するレスポンスは、使用するたびにサーバーに連絡する必要があるため、処理が遅くなります(待ち時間が長くなります)。
ただし、帯域幅を節約するために、クライアントは依然としてそのような応答を保存することがあります。 no-cache
レスポンスは、キャッシュされたレスポンスを再利用できるかどうかをチェックするたびに、サーバに連絡することなくリクエストを満たすために使用されません。
レスポンスをまったく格納しないよう要求する
Cache-control: no-store
クライアントnoに応答をキャッシュし、できるだけ早く応答を忘れるように指示します。
このディレクティブはもともと機密性の高いデータ用に設計されていましたが(今日はHTTPSを代わりに使用する必要があります)、再利用できないレスポンスを持つキャッシュの汚染を避けるために使用できます。
レスポンスデータが常に異なる特定のケース、たとえば大きな乱数を返すAPIエンドポイントでのみ適切です。さもなければ、 no-cache
およびrevalidationは "uncacheable"応答の振舞いを持っているが、まだいくらかの帯域幅を節約することができる。
廃止された、冗長で非標準的なヘッダー
Expires
- リソースが古くなった日付を指定します。正確なクロックとタイムゾーンをサポートしているサーバーやクライアントに依存しています。Cache-control: max-age
Expires
よりもCache-control: max-age
が優先され、一般に信頼性が向上します。post-check
とpre-check
指示は、古くなったレスポンスを使用できる非標準のInternet Explorer拡張機能です。標準的な代替策は、stale-while-revalidate
です。Pragma: no-cache
- 1999年に廃止されました。代わりにCache-control
を使用Cache-control
必要があります。
キャッシュされたリソースの変更
キャッシュをバイパスする最も簡単な方法は、URLを変更することです。これは、URLにリソースのバージョンまたはチェックサムが含まれている場合のベストプラクティスとして使用されます。
http://example.com/image.png?version=1
http://example.com/image.png?version=2
これらの2つのURLは別々にキャッシュされるので、 …?version=1
が永久にキャッシュされたとしても、新しいコピーはすぐに…?version=2
として取り出すことができます。
ランダムURLを使用してキャッシュをバイパスしないでください。 Cache-control: no-cache
またはCache-control: no-store
使用します。 no-store
ディレクティブを使用せずにランダムなURLの応答を送信すると、キャッシュに不必要な情報が格納され、キャッシュからより有用な応答が取り出され、キャッシュ全体のパフォーマンスが低下します。