caching - キャッシュされたままにする必要がある画像に対してHTTPリクエストを行うためにブラウザーを停止する-mod_expires
ここで多くの記事といくつかの質問を読んだ後、私はついにApacheのアクティブ化に成功しましたmod_expiresブラウザに画像を1年間キャッシュする必要があることを伝えるには.
<filesMatch "\.(ico|gif|jpg|png)$">
ExpiresActive On
ExpiresDefault "access plus 1 year"
Header append Cache-Control "public"
</filesMatch>
そしてありがたいことに、サーバーの応答は正しいようです。
HTTP/1.1 200 OK
Date: Fri, 06 Apr 2012 19:25:30 GMT
Server: Apache
Last-Modified: Tue, 26 Jul 2011 18:50:14 GMT
Accept-Ranges: bytes
Content-Length: 24884
Cache-Control: max-age=31536000, public
Expires: Sat, 06 Apr 2013 19:25:30 GMT
Connection: close
Content-Type: image/jpeg
そうですね、これでブラウザのダウンロードが停止し、サーバーに1年間画像について問い合わせることさえできると思いました。しかし、それは部分的に真実です：原因ブラウザを閉じて再度開くと、ブラウザは画像をダウンロードしませんもうサーバーから、ただし、ブラウザは引き続き各画像のHTTPリクエストでサーバーに問い合わせます.
ブラウザに各画像のHTTPリクエストの作成を強制的に停止させるにはどうすればよいですか？これらのHTTPリクエストの後に画像がダウンロードされていなくても、サーバーに対して行われたリクエストです。それは不必要に待ち時間を増やし、ページのレンダリングを遅くします！
私はすでにブラウザに画像を1年間キャッシュに保存しなければならないと言いました！なぜブラウザは（画像をダウンロードしなくても）各画像についてサーバーに問い合わせるのですか？！
FireBugのネットワークグラフを見ると（メニューFireBug>ネット>画像）、さまざまなキャッシュ動作を確認できます（明らかに、ブラウザーキャッシュを完全に空にして開始し、[すべての履歴をクリア]を使用してブラウザーでキャッシュを強制的に削除しました）。
ページが初めて読み込まれると、すべての画像がダウンロードされます（ブラウザの[ページの再読み込み]ボタンをクリックしてページの再読み込みを強制した場合も同じことが起こります）。意味あり！
サイトをナビゲートして同じページに戻ったとき画像はまったくダウンロードされず、ブラウザはサーバーに問い合わせさえしません画像のいずれか。これは理にかなっています（そして、ブラウザが閉じているときもこの動作を見たいです）！
ブラウザを閉じて同じページでもう一度開くと、ばかげたブラウザはとにかく画像ごとに1回サーバーにHTTPリクエストを送信します。画像をダウンロードしませんが、それでもHTTPリクエストを送信します。これは、ブラウザが問い合わせるようなものです。画像についてのサーバー（サーバーは200 OKで応答します）。これは私を苛立たせるものです！
興味があれば、以下のグラフも添付します。
編集：FireFox 3.6が古すぎるという問題ではないことを確認するために、FireFox11.0でもテストしました。同じことが起こります!!!GoogleサイトとStackoverflowサイトもテストしました、両方とも送信しますCache-Control: max-age=...だがブラウザを閉じて同じページで再度開くと、ブラウザは画像ごとにサーバーにHTTPリクエストを送信します。、サーバーの応答後、ブラウザは画像をダウンロードしませんが（上記で説明したように）、それでもページを表示する時間が長くなるような要求を行います。
EDIT2：そして削除するLast-Modified提案されたヘッダーここに、問題を解決しません、それは何の違いもありません。
すべての答え
リクエストの分析に間違ったツールを使用していました。
本当に便利なFirefoxアドオンをお勧めしますライブHTTPヘッダーそのため、ネットワーク上で実際に何が起こっているかを確認できます。
念のために言っておきますが、サーバーをssh / puttyして、次のようなことを行うことができます。
あなたが見ている振る舞いは意図されたものです（参照RFC7234詳細については）、指定された動作：
最新のブラウザはすべて、キャッシュステータスに関係なく、表示されるすべてのページ要素に対してHTTPリクエストをサーバーに送信します。これは、HTTPサーバーがすべての要素のすべての表示の記録を維持できるようにするために、Webサービス（特に広告ネットワーク）の要求に応じて行われた設計上の決定でした。
ブラウザがこれらの要求を行わなかった場合、画像がユーザーに表示されたことがサーバーに通知されることはありません。広告ネットワークの場合、これは壊滅的です。早い段階で、広告ネットワークはランダムに生成された名前を使用して同じ広告画像を配信することにより、これを回避する方法を「ハッキング」しました（例：「coke_ad_1_98719283719283.gif」）。ただし、ISPの場合、ISPが運用しているキャッシュ/プロキシサーバーをバイパスして、すべてのユーザーがこれらの同一の広告画像を再ダウンロードしていたため、この方法によりデータ転送が大幅に増加しました。
そのため、停戦に達しました。有効期限が切れていないキャッシュ要素であっても、ブラウザは常にHTTPリクエストを送信していました。サーバーはHTTP304ステータスコード（「変更なし」）で応答します。これにより、サーバーは画像がクライアントに表示されたという事実を記録できます。その結果、広告ネットワーク一般的にネットワークキャッシュサーバーをバイパスするためにランダム化されたイメージ名の使用を停止しました。
これにより、広告ネットワークに必要なもの（表示されたすべての画像の記録）が提供され、ISPにキャッシュ可能な画像と静的コンテンツが提供されました。
そのため、ブラウザがキャッシュされたページ要素に対してHTTPリクエストを送信しないようにするためにできることはあまりありません。
しかし、html5に付属している他の利用可能なクライアント側ソリューションを見ると、リソースの読み込みを防ぐ余地があります
「リロード」と「リフレッシュ」には違いがあります。通常、戻るボタンと進むボタンがあるページに移動するだけでは、新しいHTTPリクエストは開始されませんが、特にF5キーを押してページを「更新」すると、ブラウザはキャッシュを再確認します。これはブラウザに依存しますが、FFとChrome（つまり、ネットワークトラフィックを簡単に監視する機能を備えたブラウザ）の標準のようです。F6を押してEnterキーを押すと、URLアドレスバーにフォーカスしてから「移動」する必要があります。ページをリロードしますが、ページのアセットを再確認しないでください。
更新：前後のナビゲート動作の明確化。これは「バックフォワードキャッシュ」またはBFCacheブラウザで。戻る/進むボタンでナビゲートするときの目的は、自分のタイムラインでページを見たときとまったく同じように表示することです。サーバーのキャッシュヘッダーに特定のアイテムの有効期限が切れていると表示されている場合でも、前後の使用時にサーバー要求は行われません。
開発者のネットワークパネルに（200 OK BFCache）が表示されている場合は、サーバーがヒットすることはありません。
http://www.softwareishard.com/blog/firebug/firebug-tip-what-the-heck-is-bfcache/
F5またはF5 + Ctrlを使用して強制的に更新すると、リクエストが送信されます。ただし、ブラウザを閉じてURLをもう一度入力すると、要求は送信されません。リクエストが送信されるかどうかをテストする方法は、リクエストが送信されない場合でもサーバーでリクエストの開始時にブレークポイントを使用することでした。Firebugでは7ミリ秒の待機を行ったと表示されるので注意してください。
ここで説明していることは、私の経験を反映していません。コンテンツがno-storeディレクティブで提供されるか、明示的な更新を行う場合は、はい、元のサーバーに戻ることを期待します。そうでない場合は、ブラウザーの再起動時にキャッシュする必要があります（許可されており、書き込みが可能であると想定しています）。キャッシュファイル）。
滝をもう少し詳しく見ると（少し小さくてぼやけているので注意が必要です）、ブラウザーは正確に本来の動作をしているように見えます。持っている画像のエントリ-しかし、これらはロード中ですローカルキャッシュからオリジンサーバーからではありません-応答の「Date」ヘッダーを確認してください（なぜ秒ではなくミリ秒かかると思いますか？）。そのため、色が異なります。
妥当な答えを探すのにかなりの時間を費やした後、私は以下のリンクが最も有用であることがわかりました、そしてそれはここで尋ねられた質問に答えます。
https://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests
それが生死にかかわる問題である場合（この方法でページの読み込みを最適化したい場合、またはサーバーの負荷を可能な限り減らしたい場合）、回避策があります。
HTML5を使用するローカルストレージ初めて要求された後に画像をキャッシュします。
[+]ブラウザがHTTPリクエストを送信しないようにすることができます。これは、ユーザーがどれほどハードに試行しても（F5、ctrl + F5、単にページを再訪するなど）、99％で304（変更なし）を返します。
[-]これを行うには、JavaScriptのサポートにさらに努力する必要があります。
[-]画像はbase64に保存されます（バイナリデータは保存できません）。そのため、クライアント側で毎回デコードされます。これは通常かなり高速で大したことではありませんが、それでもクライアント側での追加のCPU使用率であり、覚えておく必要があります。
[-]ローカルストレージは限られています。ドメインごとに最大5MBのデータを使用することを目指すことができます（注：base64は画像の元のサイズに最大30％を追加します）。
[？]による支援過半数ブラウザの。http://caniuse.com/#search=localstorage
例
テスト
Chromeに表示されているのは、実際のHTTPリクエストの記録ではなく、アセットリクエストの記録です。 Chromeはこれを実行して、アセットが実際にページからリクエストされていることを示します。ただし、このビューは、要求が行われているかどうかを実際に示しているわけではありません。アセットがキャッシュされている場合、Chromeが実際に基になるHTTPリクエストを作成することはありません。
タイムラインの紫色のセグメントにカーソルを合わせると、これを確認することもできます。キャッシュされたリソースには
(from cache)ツールチップで。実際のHTTPリクエストを確認するには、下位レベルを調べる必要があります。一部のブラウザーでは、これはプラグイン（Live HTTPヘッダーなど）を使用して実行できます。
ただし、実際には、リクエストが実際に行われていないことを確認するには、サーバーログを確認するか、CharlesやFiddlerなどのデバッグプロキシを使用する必要があります。これはHTTPレベルで機能し、リクエストが実際に発生していないことを確認します。
キャッシュ検証と304応答
Internet Explorerが、キャッシュされたエントリが有効かどうかを確認する必要がある状況はいくつかあります。
キャッシュされたエントリには有効期限がなく、コンテンツはブラウザセッションで初めてアクセスされます
キャッシュされたエントリには有効期限がありますが、有効期限が切れています
キャッシュされたエントリに最終変更日がある場合、IEはそれをGET要求メッセージのIf-Modified-Sinceヘッダーで送信します。
サーバーはIf-Modified-Sinceヘッダーをチェックし、それに応じて応答します。指定された日時以降にコンテンツが変更されていない場合は、ステータスコード304と、ヘッダーのみを含む応答メッセージで応答します。
応答にはコンテンツが含まれておらず、IEが必要なデータをキャッシュから読み取るため、応答をすばやくダウンロードできます。事実上、これはローカルブラウザキャッシュへのリダイレクトのようなものです。
要求されたオブジェクトがIf-Modified-Sinceヘッダーの日付/時刻以降に実際に変更された場合、サーバーはステータスコード200で応答し、変更されたバージョンのリソースを提供します。
この質問にはもっと良い答えがありますここにウェブマスターのスタック交換サイトで。
上記のリンクにも引用されている詳細情報は、httpwatch
記事によると：
Internet Explorerが、キャッシュされたエントリが有効かどうかを確認する必要がある状況はいくつかあります。
ユーザーが[更新]ボタンをクリックするか、F5キーを押して、ページの更新をリクエストしました
ここにコードを入力してください
Leave a Reply