web-dev-qa-db-ja.com

ブラウザがキャッシュをクリアするのはいつですか。また、304応答をさらに活用するにはどうすればよいですか？

頻繁に変更されるいくつかのコンテンツを含むWebサイトがあります。

これが変わらない場合は適切なキャッシングの恩恵を受けたいので（理想的には長いCache-Controlヘッダーを使用します）、最新の情報が使用されるようにします（したがって理想的には短いCache-Controlヘッダーを使用します） 。これらは明らかに矛盾しています。

データをキャッシュすることには2つの利点があります。

  1. すべての呼び出しを減らし、キャッシュから直接バージョンを使用します（キャッシュ制御ヘッダーの時間枠内でリソースが使用される場合）。

  2. 使用期限が切れたコンテンツのリクエストへの応答として304-Not Modifiedが使用されますが、それはまだ最新バージョンであり、ブラウザーのキャッシュに残っています（リクエストのETagまたはLast-Modifiedヘッダーに基づく）。これは、データを要求し、ラウンドトリップとレイテンシの問題を意味する304応答を受信する必要があることを意味します（パフォーマンスヒットを過小評価しないでください！）ので、最初のオプションほど良くはありませんが、少なくとも完全ダウンロードし、最新バージョンを使用していることを確認します。

だから私の質問は：

HTMLページまたはコンテンツ（CSS、JavaScript、画像、フォントなど）がキャッシュコントロールヘッダー時間を過ぎて期限切れになった場合、ブラウザーは304応答を利用するためにコンテンツを保持し続ける期間はどのくらいですか？

サーバーまたはアプリケーションレベルで、長時間にわたって304応答でデータを使用できるようにするためにできることはありますか？つまり長い時間（たとえば30日）ブラウザにデータをキャッシュしておくことができますが、304応答の恩恵を受けるためにはるかに短い時間（たとえば3時間後）で再要求されますか？短い間しか使用できないCache-Controlヘッダー以外に、「キャッシュに保存」するHTTPヘッダーはないと思うので、これは純粋にブラウザーの実装に依存していると思いますか？私はブラウザが定期的に期限切れデータのキャッシュをクリアしてディスク使用量を抑えることを想定しており、どのウェブサイトリソースにもっと積極的にクリアしたいのか、ブラウザにアドバイスしたいのかどうかに影響があるかどうかを尋ねている304を後で使用できることを期待して、より長くラウンドを続けます。

追伸タイムスタンプまたはその他の一意のコードをファイル名と長いキャッシュ制御ヘッダーに追加し、ファイルの変更時にこの一意の部分を更新して、目的を達成できることを認識しています。これは、ブラウザから見ると、新しいリソースのように見えるため、フェッチされることを意味します。ただし、さまざまな理由から、これは常に実装するのが最も簡単なわけではありません（サーバー側のリダイレクトなしでデフォルトの「index.html」ページで実行することはできません）。

performancecachebrowsershttp-headerscache-control
2
Barry Pollard

HTMLページまたはコンテンツ（CSS、JavaScript、画像、フォントなど）がキャッシュコントロールヘッダー時間を過ぎて期限切れになった場合、ブラウザーは304応答を利用するためにコンテンツを保持し続ける期間はどのくらいですか？

ブラウザは、有効期限を超えて一時ディレクトリまたはキャッシュディレクトリのディスクに保存されたコンテンツを保持する場合がありますが、ブラウザは期限切れ（「新鮮」ではない）であると見なし、それを参照してから再検証を試みますファイルを再ダウンロードします。残念ながら、仕様はブラウザが期限切れファイルを処理する方法をカバーしておらず、ディスク上のファイルの実際のクリーンアップはブラウザとユーザーの設定（キャッシュファイルのディスク領域制限など）に依存し、変化する可能性がありますが、ブラウザが閉じています。

Mark Ameryは、別の質問に対処しながら、HTTP 304応答とブラウザーキャッシュ動作の関係を明確かつ正確に説明する優れた回答（ ブラウザーキャッシュ-304を返す要求を防ぐ ）を作成しました。

サーバーまたはアプリケーションレベルで、長時間にわたって304応答でデータを使用できるようにするためにできることはありますか？つまり長い時間（たとえば30日）ブラウザにデータをキャッシュしておくことができますが、304応答の恩恵を受けるためにはるかに短い時間（たとえば3時間後）で再要求されますか？短い間しか使用できないCache-Controlヘッダー以外に、「キャッシュに保存」するHTTPヘッダーはないと思うので、これは純粋にブラウザーの実装に依存していると思いますか？

Cache-Control: public, max-age=1080, must-revalidate（コメントから18分）を指定することをお勧めします。ブラウザはその時間後にコンテンツを確実に再検証しますが、この時間中またはユーザーがリロードするためにリフレッシュを押すと、独自の裁量で再検証することもできますページ。

本当に必要な場合は、ファイルの内容が変更されない限りファイルが再ダウンロードされないことを確認するために、最後に変更された日付/時刻をチェックするのではなく、MD5ハッシュでETagマッチングを使用することもできます。大量のトラフィックが発生した場合、各リクエストのETagを計算する際にわずかなパフォーマンスヒットが発生する可能性があります。また、多くの人は、わずかなパフォーマンスの低下と、MD5を使用するように設定していないため、この方法に反対しています（このためにサーバー側のスクリプトを使用する場合）、最後に変更された日付/時刻のチェックよりも実質的な利点はなく、ファイルが複数のサーバーから配布されると不安定に動作する可能性があります。正しく構成されているとはいえ、ETag比較と長い有効期限を組み合わせると、必要なファイルのダウンロードを減らすことができます。パフォーマンスの悪影響を受けないようにするため、ETagを設定する前に、Webサーバーの設定が永続的な接続を使用するように設定されていることを確認してください。サーバーがセットアップされている場合、これ。

私はブラウザが定期的に期限切れデータのキャッシュをクリアしてディスク使用量を抑えることを想定しており、どのウェブサイトリソースにもっと積極的にクリアしたいのか、ブラウザにアドバイスしたいのかどうかに影響があるかどうかを尋ねている304を後で使用できることを期待して、より長くラウンドを続けます。

実際、Webサイト上の異なるリソースに対して異なるキャッシュ時間を指定できます。たとえば、jQuery、requireJS、FontAwesomeなどのサードパーティのライブラリ/コードを格納するサブフォルダー（libなど）がある場合、次を含めることができます。フォルダー名のバージョン（例：http://www.example.com/lib/fontawesome-4.3.0/）そして、このlibフォルダー内のすべてに対して、最大または少なくとも非常に長いキャッシュ時間を設定しますサードパーティのコード/ファイルに直接変更を加えると、将来のバージョンが新しいフォルダーの下に導入され、バージョン名が含まれます。変更される可能性のあるWebサイトテンプレートに使用される静的リソース（。js、。css、。jpg、。pngなど）キャッシュ時間をより短く設定できる場合があります。

# Cache third party files for 1 year (31536000 seconds)
<Directory "/var/www/public_html/lib">
  <IfModule mod_expires.c>
    Header set Cache-control max-age=31536000
  </IfModule>
</Directory>

# Cache template files for 1 day (86400 seconds)
<Directory "/var/www/public_html/tpl">
  <IfModule mod_expires.c>
    Header set Cache-control max-age=86400
  </IfModule>
</Directory>

追伸タイムスタンプまたはその他の一意のコードをファイル名と長いキャッシュ制御ヘッダーに追加し、ファイルの変更時にこの一意の部分を更新して、目的を達成できることを認識しています。これは、ブラウザから見ると、新しいリソースのように見えるため、フェッチされることを意味します。ただし、さまざまな理由から、これは常に実装するのが最も簡単なわけではありません（サーバー側のリダイレクトなしでデフォルトの「index.html」ページで実行することはできません）。

間違いなく、これらは効果的かつ効率的な方法で実装するのは容易ではなく、意図したとおりにHTTPプロトコルヘッダーを使用するよりも多くの労力/コードを必要とします。この種のソリューションが好まれる唯一のシナリオは、コンテンツ管理システムなど、さまざまなウェブサーバー環境を一貫してサポートしたいクロスプラットフォームソフトウェアの場合です。たとえば、ソフトウェアがPHPで作成されている場合、.htaccessルールを使用するのではなく、PHPで完全に実現できるソリューションを実装する可能性があります。

2015年6月4日に追加：

期限切れの（「古い」）キャッシュファイルのブラウザの動作について：

「保存された応答は、「検証」なしで再利用できる場合、セクション4.2で定義されているように「新鮮」と見なされます（キャッシュされた応答がこの要求に対して有効かどうかをOriginサーバーで確認します）。再利用されるたびにレイテンシとネットワークオーバーヘッドの両方を削減します。キャッシュされた応答が新鮮ではない場合、検証（4.3節）で更新できる場合、またはオリジンが利用できない場合（4.2.4節）でも再利用可能です。

出典： RFC 7234：HTTP Caching 、紹介の最後の段落

Must-revalidateディレクティブの動作について：

「 "must-revalidate"応答ディレクティブは、古くなったキャッシュは、Originサーバーでの検証に成功せずに後続の要求を満たすために応答を使用してはならないことを示します。」

出典： RFC 7234：HTTP Caching 、5.2.2.1。改定する必要があります。

2
richhallstoke

静的ページ（html拡張子を持つファイルなど）を扱う場合、ヘッダー構成はサーバー構成ファイルにのみ適用でき、サーバーによっては構成オプションが制限される場合があります。

サーバーを台無しにすることなく柔軟性を高めるには、PHPなどのサーバー側スクリプト言語を使用します。

また、キャッシュ制御の場合は、キャッシュの有効期限が切れたときにブラウザーが必要なリソースをサーバーで再確認するように、「must-revalidate」オプションを使用する必要があります。

304に関しては、ブラウザがリソースを再度要求すると、eTagsまたはlast-modifiedヘッダーを使用するかどうかに応じて、サーバー環境変数if-modified-sinceまたはif-none-matchに値を発行します。サーバー（またはサーバーによって実行されるスクリプト）は、変数に必要なデータが含まれていると判断した場合、304を発行します。 Googleでif-modified-sinceとif-none-matchを検索すると、それらの機能の詳細が表示されます。

0
Mike