HTTP
HTTPレスポンスのキャッシュ

備考

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