キャッシュについては、それは、次のカテゴリに分けることができます。
①CDNキャッシュ
②DNSキャッシュ
③クライアントキャッシュ（メモリキャッシュ、要求せずにディスクキャッシュ;のEtag /ラスト・Modified304要求する認証が必要）
④サービスワーカーキャッシュとオフラインキャッシュ
⑤Ajaxのキャッシュとページキャッシュ
、CDNキャッシュ
CDNは、各郡や町チケットアウトレットに配布され、ユーザーがサイトを閲覧し、CDNは、ユーザノードに最も近いユーザ要求CDNエッジに応答を選択すると理解することができます。利点は、クロス地域とオペレータ間のアクセスの問題を解決するための明白な（1）CDNノードであり、アクセスレイテンシを大幅に低減される;（2）CDNエッジノードで完了した要求の大部分は、CDNは発信局を低減、分流効果を果たしていますロード。
CDNキャッシュについて、ローカルブラウザのキャッシュの無効化した後、ブラウザがCDNエッジノードに要求を送信します。同様のブラウザキャッシュは、CDNエッジノードは、キャッシュメカニズムが存在します。CDNエッジキャッシングノードとサービスプロバイダのポリシーは異なるが、一般的に標準のHTTPプロトコル、HTTP応答キャッシュ制御ヘッダに続く：MAX-年齢フィールドは、時間データキャッシュCDNエッジノードを設定します。
クライアントは、CDNのノードからデータを要求すると、CDNのノードは、キャッシュデータの有効期限が切れていない場合、キャッシュされたデータは、クライアントにキャッシュされたデータに直接、その後、期限が切れているかどうかを判断し、そうでない場合、CDNのノードから、元に戻し発信局にリクエストを送信します発信局は、データにプルローカルキャッシュを更新し、クライアントに最新のデータを返します。
CDNサービスプロバイダは、典型的には、より洗練されたキャッシュ管理をユーザーに提供するために、ディレクトリより緯度の時間を、ファイルの拡張子を指定するには、キャッシュベースのCDNを提供します。
CDNのキャッシュのリフレッシュ：
CDNエッジノードは、「リフレッシュキャッシュは、」CDNエッジキャッシュノードを達成するためのインタフェースをクリーンアップする開発者はCDNサービスプロバイダを通じて提供することができ、ローカルブラウザのキャッシュの無効化のリフレッシュを強制するために、ブラウザのCTRL + F5に比べて、開発者には透過的です目的。最新のデータをプルダウンし、データを更新した後、あなたは、クライアントがアクセスすることを保証するために、有効期限が切れるデータキャッシュにCDNのノードを強制的に「リフレッシュキャッシュ」機能を使用することができ、開発者はそう。
二、DNSキャッシュ
DNS（ドメインネームシステム）：サーバホストのIPへのドメインのURLを担当します。
DNSルックアッププロセス：ブラウザのキャッシュが存在する最初のチェック、ローカルDNSキャッシュへのアクセスがない、それは、ローカルのDNSサーバへのアクセスを存在しません。したがって、DNSは、指定されたURLのIPアドレスがDNSルックアップが完了する前に、ブラウザがホストから何かをダウンロードすることができない、20-120msを取る場所をブラウザには通常、オーバーヘッドです。
TTL（生存時間）は：DNSルックアップがレコードが生存時間はDNSレコードが破棄されます、その後期限切れ含ま返し表します。ブラウザは、独自のDNSキャッシュの有効期限があり、この時間は、クロムのみ約1分として、比較的短いまた、ローカルDNSキャッシュとは無関係です。
DNSのパフォーマンスの最適化のベストプラクティス
クライアントのDNSキャッシュが空である場合には、Webページの数のDNSルックアップは、固有のホスト名の数に等しいです。だから、DNSルックアップの数を減らすことができますユニークなホスト名の数を減らします。
そして、時には、ホストDNS負荷分散ポイントの数を増やすため、DNSルックアップを削減し、矛盾関係は、戦闘DNSホスト名は2-4でベストです設定ホストの数を増やすために複数の設定が必要です。その他の負荷分散は、nginxの負荷分散を使用するなど、他の方法で達成することができます。
三、顧客のブラウザのキャッシュポリシーサイドのキャッシング
1.キャッシュコントロール：最大エージング
あなたのサイトは、スクリプトファイルの年引用されたものと変わりませんし、ブラウザがサーバーが同じコンテンツを返すたびに要求しない、スクリプトファイルをキャッシュしたいです。これは、帯域幅コストを節約し、パフォーマンスを高めることができます。
キャッシュコントロール：最大年齢= 31536000キャッシュ制御設定ファイルには、HTTPヘッダに設定されて返す必要があります。//は、キャッシュ時間を制御することができます
標準では、最大最大エージング値が1年を超えることはできません指定し、理由秒であり、その値は31536000です。
このアドレスがある場合は、同じスクリプトがwww.haorooms.com/never-expire.jsので、次の各時間は、ユーザーがアドレスを要求した場合、ブラウザはもはやなく、直接、地元のブラウザから、サーバーを要求しないであろうキャッシュを取ります。または1年後までのユーザー手動でクリア。
しかし、スクリプトの内容中に発見されたどのように行うように変更する必要がありますか？例えば、のようなファイル名を変更する要求、決して期限切れになりませ-v2.js。
キャッシュ制御はHTTP1.1の機能、キャッシュ制御だけでなく、他の情報です。
（1）キャッシュなしを：、キャッシュ内に新鮮な、新鮮なキャッシュが使用されているかどうかを確認するために、Webサーバへのキャッシュ要求をファイルを読みません。
（2）無店舗を：クライアントがキャッシュを使用してクライアントのキャッシュを持っている場合つまり、これは一般的にするときがないネットワークに使用されます。このフィールドは非常に重要であり、それがキャッシュされただけ-IF-ではありません、一時的にハードディスクに格納されたデータを表し、
（3）MAX-古いは：キャッシュMAX-古い時間が規定時間を超えない限り、使用することは、ロードすることができます。ネットワーク状況のマスト再検証せずに使用することができます：キャッシュの使用に関する合意、すべての要求キャッシングとサーバーのソースファイルと同じ効果を、より厳格なチェック、現在まで取ることが矛盾しています。
（4）S-MAXAGE MAXAGEと、MAXAGE /有効期限を覆うだけ共有キャッシュのために、プライベートキャッシュは無視されます。白公共レスポンスはキャッシュ任意のオブジェクト（クライアント、プロキシサーバなどの送信要求）を示すかもしれません。民間が応答は、単一のユーザー（おそらくオペレーティング・システム・ユーザーは、ブラウザのユーザー）キャッシュ、非共有することができることを示して、プロキシサーバーのキャッシュにすることはできません。
2.有効期限
有効期限は、ブラウザの設定を回避し、時間が経過するまでサーバがリクエストを送信します。
注意：有効期限HTTP1.0の特性、以前よりもキャッシュ制御で、いくつかの欠点があります。故障時間ので、絶対時間であるので、クライアントのローカル時刻が変更されたときに、サーバとクライアントの時間のずれが大きくなり、それが混乱のキャッシュにつながります。
二つ以上のバッファは、レベル3のキャッシュ、キャッシュ制御の原理に従うと同時に満了すると同時に、高いキャッシュ制御優先順位を有効にすると、サーバー側のいずれかを有効にするか、または可能にするように構成することができます。
3. Last-Modifiedの304回の協議キャッシュ
現在のファイルのサーバブラウザのバージョンを知らせるために、それは例えば、最終更新時刻タグを送信します。
最終更新：火、2018年1月6日午前8時26分32秒GMT
キャッシュが304交渉であれば、以下のように、検証手順は次のとおりです。
①ブラウザ：それは最終-変更された場合ねえ、私は、この文書をjquery.min.jsを必要とする：2018年1月6日午前8時26分32秒GMT後に修正火、私を送ってください
②サーバー：ファイルの修正時刻をチェック
③サーバー：ねえ、この文書は、その時点の後に変更されていない、あなたはすでに最新バージョンを持っています
④ブラウザ：今、私はそれをユーザーに紹介します
4.のETag
たEtagと304似ていますが、レベルはいくつかのLast-Modifiedよりも高く、
リクエストプロセス：
①ブラウザ：ねえ、私はこの文書のhaoroomsのあるmain.cssを必要とし、不一致「61213-1762a-50bf790757204」この文字列が存在しません
ETagをチェック②サーバー...）
③サーバー：ねえ、ここでは「61213-1762a-50bf790757204」の私のバージョンである、あなたは、最新のバージョンを持っています
④ブラウザ：さて、あなたはローカルキャッシュを使用することができます
四、サービス労働者のキャッシュとオフラインキャッシュ
サービス労働者（以下、SWと記す）規範と人気で、キャッシュは、インターフェースSW代替HTTPキャッシングを提供するために使用することができます。もちろん、SW機能は、バッファリング機能に加えて、強力ですが、また、オフラインで、データの同期、バックエンドのコンパイラなど。
SWキャッシュコードの標準バージョンでは、次のコードを持っている必要があります。
const version = '2';
self.addEventListener('install', event => {
event.waitUntil(
caches.open(`static-${version}`)
.then(cache => cache.addAll([
'/styles.css',
'/script.js'
]))
);
});
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(response => response || fetch(event.request))
);
});HTTPキャッシュミスに転送する場合、ネットワークは、SWスクリプトに到達する最初のを要求します。
このコードは、インストール段階で、我々はキャッシュにSWとStyles.cssををscript.jsだろう、ということを意味し、そうでない場合は、リクエストに開始、フェッチステージリソースのキャッシュを経由するURL内の一致を見つけるために、すぐに成功を返します通常のネットワーク要求プロセスを取ります。
しかし、彼らはどこから来インストール段階でのリソースのコンテンツ？それでもHTTPキャッシュから来ます。そのようなSWキャッシングとHTTPキャッシュは以前のように落ちることがあり、バージョンの不一致は述べています。
解決策は、要求SWがサーバーに認証しなければならないようにすることです。
self.addEventListener('install', event => {
event.waitUntil(
caches.open(`static-${version}`)
.then(cache => cache.addAll([
new Request('/styles.css', { cache: 'no-cache' }),
new Request('/script.js', { cache: 'no-cache' })
]))
);
});いないすべてのブラウザは、キャッシュ構成オプションをサポートしていますが、我々は間接的なキャッシュの無効化するように、各要求されたURLが同じでないことを確認するために乱数を追加することによってできます。
self.addEventListener('install', event => {
event.waitUntil(
caches.open(`static-${version}`)
.then(cache => Promise.all(
[
'/styles.css',
'/script.js'
].map(url => {
// cache-bust using a random query string
return fetch(`${url}?${Math.random()}`).then(response => {
// fail on 404, 500 etc
if (!response.ok) throw Error('Not ok');
return cache.put(url, response);
})
})
))
);
});五、Ajaxをキャッシュ可能とページキャッシュ
AjaxのキャッシュのFacebookへの一つの解決策を提起することをページキャッシュ。
AJAXによって、キャッシュからの場合、（ページには、最初にすべてのAjaxコールバックの結果キャッシュおよびAJAXをロードされた後BigPipeに基づいて、ページのコンテンツは、ローカル.Facebookページに参加します推測）Facebookは、キャッシュからページかどうかを識別するためのフレームワークを設計します更新モジュール（：DIV ID事前定義されたコールバックハンドラ本JSによって支払わ対応する所望のページ、およびページがダウンダウンロード同時にダウンロードされた投機）を更新するために必要。
これは、更新の3種類を指し：増分更新、ユーザーの複製（例えば、ユーザーがページ上のコメントに返信）、クロスページ更新（例えば、既読メッセージへのメッセージ詳細ページでは、家庭にある必要はありません。未読のメッセージ）が更新されます。核となるアイデアは、AJAXに基づいて更新されます。
（1）増分更新：すべての事前定義された更新モジュールがすること、キャッシュからページ限り増分更新
（2）ユーザーの複製：ユーザーの操作を記録を通じて、すべてのキャッシュページの読み込み中に「再生可能」操作としてマークをHistoryManagerに再現
（3）クロスページの更新を：APIはクライアントに信号を送るinvaildデータベースとして特定のサーバーでキャッシュさ期限切れになります。情報を更新するために、AJAXを介してキャッシュの有効期限の情報を取得した後に更新する必要があります。
最初の場所にページコンテンツの変更/フリッカトリックを避けるために、更新のAjaxへの参照を渡しているFacebookは、直接その内容を更新するのではなく、空白に設定されている更新する必要があります。