ブラウザのキャッシュはそれぞれ、以下で説明されている、HTTPキャッシングとオフラインキャッシュに分けることができます
HTTPキャッシング
唯一のGETリクエストをキャッシュすることができ、POSTはキャッシュすることはできません。
変更された時間/ ETagを/有効期限/キャッシュは、キャッシュ戦略HTTPプロトコルです
最初の例
私たちは二度目Baiduのホーム・ページを訪問したときは、静的なファイルは、応答のステータスがありますChromeの[ネットワーク]パネルで開かれている：200（ディスク・キャッシュから）OK、304は変更されていない返す必要がありますがされていない、それは？あなたは答えを知っている場合、その記事を無視することができます。
Cache-Control
簡単な紹介
w3.org的定义是「のCache-Control一般ヘッダフィールドは、要求/応答チェーンに沿ったすべてのキャッシングメカニズムが従わなければならないディレクティブを指定するために使用されます。」
これは、HTTPキャッシュの動作を制御するために使用される一般的なヘッダフィールド（すなわち、要求パケットおよび応答パケットフィールドに過ごすことができる）、です。
例えば：
のCache-Control：MAX-年齢= 3600、国民はpublic誰のキャッシュが使用可能な応答があることを意味max-ageあなたのウェブサイトがキャッシュされることを可能にするキャッシュが大幅にダウンロード時間と帯域幅を削減するだけでなく、ブラウザを改善する秒の有効な数値を示し、読み込み速度です。
あなたもを設定することができno-cache、命令キャッシュ無効にするには：
のCache-Control：NO-キャッシュ
詳細については、
キャッシュ制御ヘッダフィールドは、別々に使用されるパケットと応答パケットを要求することができることを意味し、総称です。フォーマットのRFCキャッシュ制御仕様で：Cache-Control: cache-directive
要求ヘッダ、オプションのキャッシュ指令値は次のとおりです。
Cache-Control：リクエストヘッダがある場合は最大エージング = 0は、 （ETagの||のLast-Modified）キャッシュを検証する必要があることを示してキャッシュの有効期限が切れていない場合、使用することができます。
Cache-Control：リクエストヘッダがある場合はキャッシュなしには 、 ブラウザだけで、最新のファイルを取得表します。レスポンスヘッダーと対応する無店舗。
レスポンスヘッダとして、オプションのキャッシュ指令値は次のとおりです。
公共：、キャッシュプロキシサーバーは、CDNとして、キャッシュできるキャッシングの合計
プライベート：プライベートキャッシュは、プロキシのキャッシュとしてユーザーのブラウザであってもよいし、キャッシュプロキシサーバーのキャッシュの合計することはできません。
最大エージング= [秒]：この時間範囲内で更新することなく、新鮮なバッファを示しています。同様に時間を有効期限が、この時間は、絶対的、相対的ではありません。特定のリクエスト後にキャッシュが新鮮で何秒成功しています。
S-MAXAGE = [S]：のみ（例えばプロキシとして）共有キャッシュに適用されていること以外は同様MAXAGE、。
ノーキャッシュ：これはキャッシュされていないことを意味するものではないが、キャッシュを使用する前に、それぞれの時間は、（ここでは、実際にとのETag /最終ほとんど差）変化しなかったファイルを確認し、ソースサーバーに認証要求を送ることを余儀なくされていない
NO-ストアは：禁止されていますキャッシュ、ブラウザのキャッシュをコピーが保持させてはいけない
、再検証する必要があります。ブラウザを教えて、あなたはこの情報を再度確認期限が切れていることを確認する必要があり、リターンコードがない200が、304です。
プロキシ再検証：-再検証しなければならないと同様に、唯一のプロキシキャッシュに加えて適用することができます。
ノーキャッシュは最大エージング= 0と等価ではありません
Cache-Controlは、例えば、自由な組み合わせオプションの値を許可します。Cache-Control: max-age=3600, must-revalidate
これはリソースがオリジンサーバから取得されることを意味し、キャッシュ（新鮮）は、その後の1時間以内に1時間有効で、ユーザーに再アクセスリソースリクエストが送信される必要がないとき。
キャッシュのチェックフィールド
Cache-Controlフィールドには、このようなバッファ時間を設定すると、サーバーに要求を送信するかどうかを決定するために、クライアントは、その後、時間の期限が切れた場合、直接ローカル・キャッシュ（キャッシュからクロム200のパフォーマンス）からデータを取るために、自然やバッファを満了していないことができますリソースは、それが行くようにサーバに要求を送信し、キャッシュに直接行くべきではありません。
私たちは、クライアントがサーバにリクエストを送信した場合、それは実体がそれに戻って、リソースの内容全体を読まなければならないことを意味し、質問は今言うの？
私たちは、考えてみる - リソースデータが大きい場合、実際には、サーバーとリソースを更新されていないとき、リソースバッファ時間にクライアントを節約するために期限切れ、しかし、その後、クライアントは戻ってこの事を送信するためにサーバーを要求しますそれは、帯域幅と時間の無駄であるかどうか、何度も？
答えは、サーバーが今そこにクライアントのキャッシュファイルが、実際には、すべてのファイルが一致していると、クライアントが言っ伝えることを知らせるための方法があり、そうです这东西你直接用缓存里的就可以了，我这边没更新过呢，就不再传一次过去了。
キャッシュの再利用率を向上させるために、クライアントとサーバの間で更新されたキャッシュファイルを検証実現するために、お客様を有効にするためには、HTTPは、次の2つのチェック方法を定義します。
修正に基づいて、
リクエストヘッダフィールド
- 変更 - 開始：最後に更新されたリソースの比較が一致しています
レスポンスヘッダフィールドで
- 最終更新：最後の時間は、リソースが最後に変更されました
サーバーのリソースがクライアントに渡されると、最後の時間は、リソースが変化しますLast-Modified: GMTクライアントエンティティへのヘッダーに一緒に加えリターンの形。
時間値が同じ納期である場合、クライアントは、要求パケットに含まれる情報は、一緒にサーバー上のリソースを、チェックを行うためにサーバーをもたらす修正するだろう、要求を再びこの情報を、次回のリソースとしてマークされますそしてそれは直接ステータスコード304を返すことができ、リソースが変更されないことを示しています。
チェックコードに基づいて、
リクエストヘッダフィールド
- 場合 - なし - マッチ：ETagのは矛盾しているの比較
レスポンスヘッダフィールドで
- ETag：情報資源をマッチング。
（例えば一意の識別子に到着するためにリソースを計算するためのアルゴリズムを介して、サーバmd5标志、クライアントのリソースへの応答は、エンティティの最初の追加されますが、）ETag: 唯一标识符クライアントに一緒にリターンを。
クライアントは、ETagのフィールドを保持して、いつ次の1と過去を持つサーバに次の要求されます。サーバーは、同じサーバー上のリソースを自分かどうかのETagのETagに付属のクライアントを比較する必要が、あなたは非常によく、リソースが変更されているという点では比較的クライアントであるかどうかを判断することができます。
サーバはETagのが見つから一致しない場合、クライアントに（新しいETagをもちろん含む）200の新しいリソースをGET定期の形でパッケージに直接戻る;のETagが一致している場合は、直接、直接クライアント304に通知返さあなたは、ローカルキャッシュを使用することができます。
なぜにEtag
- いくつかのファイルは定期的に変更されることがありますが、彼は、コンテンツ（更新時刻が変更のみ）を変更しませんが、今回は、クライアントがこのファイルが変更されていることを考えるようにしたくない、と再取得します。
- 例えば、非常に頻繁に変更され、一部のファイルは、時間の秒以内に変更され、変更された場合-ので、粒径がレベルSをチェックできるようにするには、この変更を決定することができません（1S内のN回を修正言う）（またはUNIXは、MTIMEはわずか数秒に正確で前記記録）
- 一部のサーバーでは、正確なファイルが最後に変更された取得することはできません。
キャッシュポリシーの組み合わせ
キャッシュの練習
使用すると、キャッシュのより正確な使用のためのカテゴリ管理をのCache-Controlを使用して、古いブラウザとの互換性が有効期限：HTML、JS、CSS、写真 、フォント、 当時とのLast-Modified機能を使ったETagを開く（新しいnginxのではデフォルトでさ同時に、さらに複雑なキャッシングの流れを減少させるために）二つの機能を開きます。テンセントホームは60年代のキャッシュです。静的リソースは、長い時間の設定になります。
ファイル名やパラメータにMD5またはタグの束を持って来るために時間：静的リソースを取得できません。
の最初の例
今振り返ってみると資料の冒頭に問題が、一つは答えはそれらに答えることは非常に簡単だと思うかもしれません。
リソースのBaiduのホームは、実際ので、リフレッシュ後にすべての要求を送信しませんCache-Control 定义的缓存时间段还没到期。Chromeで何の送信要求は、しかし限り、ローカルキャッシュから取られて、ステータスがネットワークパネルとして表示されません場合でも、200且注明from cacheダミーの要求のみ、最後の休暇レスポンスコンテンツデータ。
施行ポリシーブラウザ
現在のほとんどのブラウザでは、[更新]ボタンまたは[F5]キーを押しをクリックし、プラスに要求することを余儀なくされCache-Control:max-age=0、それが指しリフレッシュするために言及ので、ここで、要求フィールドを选中url地址栏并按回车键（这样不会被强行加上Cache-Control）。
HTTPキャッシングはserviceWorkerによって制御され、
ここでは簡単なserviceWorker、およびwebWorkerブラウザのバックグラウンドスレッドで実行中の一種が、その大きな権威、可能であるとして拦截HTTP请求HTTPキャッシュを制御するプログラムで、（HTTPのキャッシュはJSにグローバルでありますオブジェクトcaches，其类型为cacheStorage）、これだけのhttpsサイトは、サービス労働者を使用することができ、もちろん、localhostが特殊なケースです。
完全準拠serviceWorkerまたfetchAPI。
オフラインキャッシュ
オフラインキャッシュシナリオは、いかなるネットワークAPPがない場合、正常動作に関連してもよいJSのグローバルオブジェクトですapplicationCache。
この機能を使用しないようにしてみてください、代わりにサービス労働者を使用し、一部のブラウザではまだそれをサポートしていますが、ウェブ標準から削除されましたが、それは、いくつかの将来の時間にサポートを停止することがあります。しかしchrome49 + firefox58 +の上に示された実験、caniuseの技術的な性質に属するサービスの労働者は、IEは、全体の家族をサポートしていない、新しい技術に属して傍観に滞在し、互換性がありません。
参考資料
ブラウザのHTTPキャッシュ機構に
サービスワーカー初めての経験
MDNサービス労働者
のベストプラクティス・サービスワーカー
CacheStorageの詳細ではJavaScriptを使用して
POSTリクエストが詳細は、Get HTTP
オリジナル：ビッグボックスの ブラウザでキャッシュメカニズム