キャッシュ ヘッダーを遠い将来 (今から 1 年後) に設定し、YSlow ( http://developer.yahoo.com/performance/rules.html#etags ) のアドバイスに従って ETag を無効にしましたが、Googleのページ速度はキャッシュされたヘッダーが設定された後でも ETag (または最終変更) が必要です。
「キャッシュ可能なすべてのリソースに対して、Expires または Cache-Control max-age のいずれか、および Last-Modified または ETag のいずれかを指定することが重要です。」
2 つのルールは互いに矛盾しているように見えます。
YSlow は一般的に ETag を削除することを推奨していませんが、一部の環境では推奨しています。ETag を使用しない場合は、Last-Modified代わりに使用する必要があります。
ETagすでにキャッシュされていて期限切れの可能性があるリソースを再リクエストするときの条件付き GET リクエストLast-Modified用です。
Cache-Control max-ageキャッシュされたアイテムが再確認せずに確実に有効である期間を定義するためのものです。(このルールによって有効期限が切れると、ブラウザは条件付き GET を行います ...)
だからあなたの場合：
Cache-Controlヘッダー設定を使用します。)HTTP 304何も変更されていない場合、サーバーは空のボディで応答します。その場合、ブラウザは再送信の必要なく、キャッシュされたアイテムを引き続き使用します。(ETagおよび/またはLast-Modifiedヘッダー設定を使用)(ブラウザはあなたのデータを尊重する場合と尊重しない場合があります。たとえば、1 年が経過していない場合でも、ブラウザが条件付きリクエストを行う可能性があります。)
高度に最適化されたサイトの場合、Cache-Controlこれははるかに重要です。なぜなら、faaaar future expire ヘッダーを設定し、リソースが変更された場合に備えてリソースの URL を変更するだけだからです。これにより、条件付きリクエストの使用が妨げられますが、Expires ヘッダーを定義するときに非常に積極的になることができ、リソースの新しいバージョンをすべての人に同時に提供することができます。これは、新しい URL のため、ブラウザのビューでは新しいリソースのように見えます。
Java には、サイト開発に悪影響を与えることなくこれらの概念やその他の概念を利用する、jawrと呼ばれるフレームワークが存在します。
ETagCache-Controlヘッダーは排他的ではありません。リンク先のページで ETag の削除を推奨している理由は、HTTP ヘッダーのサイズを小さくするためです。これにより、せいぜい数バイトを節約できます。両方を使用することが理にかなっているユースケースとその理由を次に示します。
application.js1週間の有効期限とetagフィンガープリントを提供しますETagまたはを指定しない場合Last-Modified、ブラウザはファイル全体を要求してダウンロードする必要があります。
良い関連リソース: https://developers.google.com/speed/articles/caching