サーチ…


備考

レスポンスは、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-checkpre-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の応答を送信すると、キャッシュに不必要な情報が格納され、キャッシュからより有用な応答が取り出され、キャッシュ全体のパフォーマンスが低下します。



Modified text is an extract of the original Stack Overflow Documentation
ライセンスを受けた CC BY-SA 3.0
所属していない Stack Overflow