4

HTTP 経由で提供され、時々変更されるいくつかのファイルがあります。

ブラウザの読み込み速度を最適化すると同時に、ブラウザに最新バージョンのファイルがあることを確認させるために HTTP 応答で返すべき、キャッシングに関連する HTTP ヘッダーはどれですか?

過去の日付を含む "Expires" ヘッダーを既に設定しています (この時点ではコンセンサスがあるようです)。

ただし、このヘッダーを設定することを推奨する人もいます。

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

しかし、このヘッダーの問題は、ブラウザがファイルのローカル コピーを保持できないため、ファイルが変更されていなくても毎回ダウンロードされ、応答コード 200 が返されることです。

私がちょうど使用する場合:

Cache-Control: no-cache

次に、ブラウザー (少なくとも Firefox 14 および Chrome 20) はローカル コピー、送信If-Modified-Since、およびIf-None-Matchヘッダーを保持し、サーバーは 304 コードを返し、ファイルの内容はダウンロードされません。 これは、いつでも変更できるこれらのファイルの最適な動作です。

問題は、「no-cache」を設定するだけで、すべてのブラウザー (古いがまだ使用されているバージョンを含む) とプロキシ サーバーがローカルにキャッシュされたコピーをサーバーで再検証するのに十分かどうかわからないことです。

最後にPragma: no-cacheヘッダーは?HTTP 応答にも含める必要がありますか?

4

3 に答える 3

5

Google 開発者向けドキュメントには、キャッシュに関する優れたドキュメントがあり、使用する優れたパターンがいくつか提供されています。

たとえば、最適なキャッシュ制御ポリシーを定義するためのフローチャートがあります。

ここに画像の説明を入力

さらに、ファイルにフィンガープリントを追加し、1 年などのより長い有効期限を設定するための適切なパターンを定義します。

  • リソースが「期限切れ」になるまで、ローカルにキャッシュされた応答が使用されます
  • URL にファイル コンテンツ フィンガープリントを埋め込むことで、クライアントに強制的に新しいバージョンのレスポンスを更新させることができます。
  • 各アプリケーションは、最適なパフォーマンスのために独自のキャッシュ階層を定義する必要があります

ここに画像の説明を入力

リソースごとのキャッシング ポリシーを定義する機能により、「キャッシュ階層」を定義できます。これにより、それぞれがキャッシュされる期間だけでなく、新しいバージョンが訪問者に表示される速度も制御できます。たとえば、上記の例を分析してみましょう。

  • HTML は「no-cache」でマークされています。つまり、ブラウザはリクエストごとに常にドキュメントを再検証し、コンテンツが変更された場合は最新バージョンを取得します。また、HTML マークアップ内では、CSS および JavaScript アセットの URL にフィンガープリントを埋め込みます。これらのファイルのコンテンツが変更されると、ページの HTML も変更され、HTML 応答の新しいコピーがダウンロードされます。
  • CSS は、ブラウザーおよび中間キャッシュ (CDN など) によってキャッシュされることが許可されており、1 年で有効期限が切れるように設定されています。
    ファイル フィンガープリントをそのファイル名に埋め込むため、1 年の「遠い将来の有効期限」を安全に使用できることに注意してください
    。CSS が更新されると、URL も変更
    されます。
  • JavaScript も 1 年で有効期限が切れるように設定されていますが、プライベートとしてマークされています。これはおそらく、
    CDN がキャッシュしてはならないプライベート ユーザー データが含まれているためです。
  • イメージはバージョンまたは一意のフィンガープリントなしでキャッシュされ、1 日で期限切れになるように設定されています。

ETag、Cache-Control、および一意の URL の組み合わせにより、有効期限の延長、応答をキャッシュできる場所の制御、オンデマンドの更新など、すべての世界で最高のものを提供できます。

于 2015-01-28T12:12:14.430 に答える
1

最善の方法は、ニーズに 100% 適合しない可能性があるため、次のとおりです。

Cache-Control:max-age=315360000, public
Expires:Tue, 23 Aug 2022 10:53:13 GMT

そして、ファイルに stylesheet_v32.css などの「コンテンツ依存のファイル名」を付けます。コンテンツが変更されるとすぐに、ファイル名 + への参照を変更すると、ブラウザーは最新バージョンを取得します。ファイル名が残っている場合、ブラウザはそれを要求する必要はありません。

これはブラウザ全体で安全で一貫しています。

とにかくそれを保存するブラウザーに依存するCache-Control: no-cacheことは、私がやりたくないことです。

于 2012-08-25T10:57:37.413 に答える
0

クライアントによるキャッシュの再チェックを強制する 2 つの方法を見つけました。

Cache-Control: max-age=0, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT

これは、少なくとも Firefox で動作します。IE と Chrome も適切に反応すると思います。HTTP/1.0 を使用する古いブラウザでも動作するはずです。

HTTP 1.1 では、ETag. その場合、クライアントがあたかもそこにあるかのように反応させるのに十分でmust-revalidateあるため、オプションは必要ありません。ETagmust-revalidate

Cache-Control: max-age=0
ETag: 123
Expires: Thu, 01 Jan 1970 00:00:00 GMT

これにより、クライアントは 123 でデータのキャッシュ バージョンを作成し、ETagそのデータのコピーが必要になるたびにサーバーを再チェックするように指示されます。その後、 で返信できます304 Not Modified

確実に使用できない 2 つのオプションはno-cache、 とno-storeです。

中間キャッシュがデータをキャッシュしないようにする場合は、必ずオプションに追加privateしてください。Cache-Control

興味深い機能として、たとえば数分の小さな max-age を使用して、クライアントがその時間の間データをキャッシュできるようにしてから、 でGET応答できる を送信することもでき304ます。

Cache-Control: max-age=300
ETag: 123
Expires: Tue, 29 Mar 2015 15:05:00 GMT

この場合、ブラウザは 5 分間新しいデータをチェックしないと予想されます。その後、それはあなたに送信しますIf-None-Match: 123

于 2016-03-29T22:01:09.380 に答える