序章
インテリジェントコンテンツキャッシングは、サイトの訪問者のエクスペリエンスを向上させるための最も効果的な方法の1つです。 キャッシュ、または以前のリクエストからのコンテンツを一時的に保存することは、HTTPプロトコル内に実装されたコアコンテンツ配信戦略の一部です。 配信パス全体のコンポーネントは、コンテンツに対して宣言されたキャッシュポリシーに従って、すべてのアイテムをキャッシュして後続のリクエストを高速化できます。
このガイドでは、Webコンテンツキャッシングの基本的な概念のいくつかについて説明します。 これは主に、インターネット全体のキャッシュがコンテンツを正しく処理できるようにするためのキャッシュポリシーの選択方法について説明します。 キャッシングがもたらす利点、注意すべき副作用、およびパフォーマンスと柔軟性の最適な組み合わせを提供するために採用するさまざまな戦略について説明します。
キャッシングとは何ですか？
キャッシングは、後続のリクエストを高速化するために再利用可能な応答を保存するための用語です。 利用可能なキャッシュにはさまざまな種類があり、それぞれに独自の特性があります。 アプリケーションキャッシュとメモリキャッシュはどちらも、特定の応答を高速化する機能で人気があります。
このガイドの焦点であるWebキャッシングは、別のタイプのキャッシュです。 Webキャッシングは、システム全体の知覚応答性を向上させながら、ネットワークトラフィックを最小限に抑えることを目的としたHTTPプロトコルのコア設計機能です。 キャッシュは、元のサーバーからブラウザへのコンテンツの移動のすべてのレベルで見つかります。
Webキャッシングは、特定のルールに従ってリクエストのHTTP応答をキャッシュすることで機能します。 キャッシュされたコンテンツに対する後続の要求は、要求をWebサーバーに送り返す代わりに、ユーザーに近いキャッシュから実行できます。
利点
効果的なキャッシュは、コンテンツコンシューマーとコンテンツプロバイダーの両方を支援します。 キャッシングがコンテンツ配信にもたらす利点のいくつかは次のとおりです。
- ネットワークコストの削減：コンテンツは、コンテンツコンシューマーとコンテンツオリジンの間のネットワークパスのさまざまなポイントでキャッシュできます。 コンテンツがコンシューマーの近くにキャッシュされる場合、要求によってキャッシュ以外のネットワークアクティビティが追加されることはありません。
- 応答性の向上：ネットワーク全体のラウンドトリップが不要なため、キャッシュによりコンテンツをより高速に取得できます。 ブラウザのキャッシュのように、ユーザーの近くに保持されているキャッシュを使用すると、この取得をほぼ瞬時に行うことができます。
- 同じハードウェアでのパフォーマンスの向上：コンテンツが発信されたサーバーの場合、積極的なキャッシュを許可することで、同じハードウェアからより多くのパフォーマンスを引き出すことができます。 コンテンツ所有者は、配信パスに沿った強力なサーバーを活用して、特定のコンテンツの負荷を軽減できます。
- ネットワーク中断中のコンテンツの可用性：特定のポリシーでは、キャッシュを使用して、オリジンサーバーから短期間利用できない場合でもエンドユーザーにコンテンツを提供できます。
用語
キャッシングを扱う場合、なじみのない用語に出くわす可能性があります。 より一般的なもののいくつかを以下に示します。
- オリジンサーバー：オリジンサーバーはコンテンツの元の場所です。 Webサーバー管理者として機能している場合、これはユーザーが制御するマシンです。 リクエストルートに沿ってキャッシュから取得できなかったコンテンツを提供し、すべてのコンテンツのキャッシュポリシーを設定する責任があります。
- キャッシュヒット率：キャッシュの有効性は、キャッシュヒット率またはヒット率の観点から測定されます。 これは、行われたリクエストの総数に対する、キャッシュから取得できるリクエストの比率です。 キャッシュヒット率が高いということは、コンテンツの高い割合がキャッシュから取得できたことを意味します。 これは通常、ほとんどの管理者にとって望ましい結果です。
- Freshness ：Freshnessは、キャッシュ内のアイテムがクライアントに提供する候補と見なされるかどうかを説明するために使用される用語です。 キャッシュ内のコンテンツは、キャッシュポリシーで指定された鮮度の時間枠内にある場合にのみ応答に使用されます。
- 古いコンテンツ：キャッシュ内のアイテムは、キャッシュポリシーのキャッシュフレッシュネス設定に従って期限切れになります。 期限切れのコンテンツは「古くなっています」。 一般に、期限切れのコンテンツを使用してクライアントの要求に応答することはできません。 新しいコンテンツを取得するか、少なくともキャッシュされたコンテンツがまだ正確であることを確認するには、オリジンサーバーに再接続する必要があります。
- 検証：キャッシュ内の古いアイテムは、有効期限を更新するために検証できます。 検証には、キャッシュされたコンテンツがまだ最新バージョンのアイテムを表しているかどうかを確認するために、オリジンサーバーにチェックインすることが含まれます。
- 無効化：無効化は、指定された有効期限より前にキャッシュからコンテンツを削除するプロセスです。 これは、アイテムがオリジンサーバーで変更されており、古いアイテムがキャッシュにあるとクライアントに重大な問題が発生する場合に必要です。
他にもたくさんのキャッシュ用語がありますが、上記のものはあなたが始めるのに役立つはずです。
何をキャッシュできますか？
特定のコンテンツは、他のコンテンツよりもキャッシュに適しています。 ほとんどのサイトで非常にキャッシュに適したコンテンツは次のとおりです。
- ロゴとブランド画像
- 一般的な非回転画像（ナビゲーションアイコンなど）
- スタイルシート
- 一般的なJavascriptファイル
- ダウンロード可能なコンテンツ
- メディアファイル
これらは頻繁に変更されない傾向があるため、長期間キャッシュすることでメリットが得られます。
キャッシングで注意しなければならないいくつかの項目は次のとおりです。
- HTMLページ
- 回転する画像
- 頻繁に変更されるJavascriptとCSS
- 認証Cookieで要求されたコンテンツ
ほとんどキャッシュされるべきではないいくつかのアイテムは次のとおりです。
- 機密データに関連する資産（銀行情報など）
- ユーザー固有で頻繁に変更されるコンテンツ
上記の一般的なルールに加えて、さまざまな種類のコンテンツを適切にキャッシュできるポリシーを指定することができます。 たとえば、認証されたユーザー全員がサイトの同じビューを表示する場合、そのビューをどこにでもキャッシュできる可能性があります。 認証されたユーザーに、しばらくの間有効になるサイトのユーザーセンシティブビューが表示された場合は、ユーザーのブラウザにキャッシュするように指示できますが、中間キャッシュにはビューを保存しないように指示できます。
Webコンテンツがキャッシュされる場所
コンテンツは、配信チェーン全体のさまざまなポイントでキャッシュできます。
- ブラウザキャッシュ：Webブラウザ自体は小さなキャッシュを維持します。 通常、ブラウザは、キャッシュする最も重要なアイテムを指示するポリシーを設定します。 これは、ユーザー固有のコンテンツ、またはダウンロードに費用がかかり、再度要求される可能性が高いと見なされるコンテンツである可能性があります。
- 中間キャッシュプロキシ：クライアントとインフラストラクチャの間にある任意のサーバーは、必要に応じて特定のコンテンツをキャッシュできます。 これらのキャッシュは、ISPまたはその他の独立した関係者によって維持される場合があります。
- リバースキャッシュ：サーバーインフラストラクチャは、バックエンドサービス用に独自のキャッシュを実装できます。 このようにして、リクエストごとにバックエンドサーバーにアクセスする代わりに、連絡先からコンテンツを提供できます。
これらの各場所は、独自のキャッシュポリシーとコンテンツのオリジンで設定されたポリシーに従って、アイテムをキャッシュできます。
ヘッダーのキャッシュ
キャッシングポリシーは、2つの異なる要因に依存しています。 キャッシングエンティティ自体が、受け入れ可能なコンテンツをキャッシュするかどうかを決定します。 キャッシュが許可されているよりも少なくキャッシュすることを決定できますが、それ以上になることはありません。
キャッシュ動作の大部分は、コンテンツ所有者によって設定されたキャッシュポリシーによって決定されます。 これらのポリシーは、主に特定のHTTPヘッダーを使用して明確に表現されています。
HTTPプロトコルのさまざまな反復を通じて、さまざまなレベルの洗練度を備えた、キャッシュに焦点を合わせたいくつかの異なるヘッダーが発生しました。 あなたがおそらくまだ注意を払う必要があるものは以下の通りです：
- 期限切れ：
Expiresヘッダーは非常に単純ですが、範囲はかなり制限されています。 基本的には、コンテンツの有効期限が切れる将来の時間を設定します。 この時点で、同じコンテンツに対するリクエストはすべてオリジンサーバーに戻る必要があります。 このヘッダーは、おそらくフォールバックとしてのみ使用するのが最適です。 - Cache-Control ：これは
Expiresヘッダ。 それは十分にサポートされており、はるかに柔軟な設計を実装しています。 ほとんどの場合、これはExpires、ただし、両方の値を設定しても問題はない場合があります。 設定できるオプションの詳細について説明しますCache-Control少しあと。 - Etag ：
Etagヘッダーはキャッシュ検証で使用されます。 起源はユニークを提供することができますEtag最初にコンテンツを提供するときのアイテムの場合。 キャッシュが期限切れ時に手元にあるコンテンツを検証する必要がある場合、キャッシュはEtagそれは内容のために持っています。 オリジンは、コンテンツが同じであることをキャッシュに通知するか、更新されたコンテンツを送信します（新しいコンテンツを使用してEtag). - Last-Modified ：このヘッダーは、アイテムが最後に変更された時刻を指定します。 これは、新鮮なコンテンツを確保するための検証戦略の一部として使用できます。
- Content-Length ：特にキャッシングには関与していませんが、
Content-Lengthヘッダーは、キャッシュポリシーを定義するときに設定することが重要です。 特定のソフトウェアは、スペースを予約する必要があるコンテンツのサイズを事前に知らない場合、コンテンツのキャッシュを拒否します。 - Vary ：キャッシュは通常、要求されたホストとリソースへのパスを、キャッシュアイテムを格納するためのキーとして使用します。 The
Varyヘッダーを使用して、リクエストが同じアイテムに対するものであるかどうかを判断するときに、追加のヘッダーに注意を払うようにキャッシュに指示できます。 これは、キャッシュにキーを指定するために最も一般的に使用されます。Accept-Encodingヘッダーも同様に、キャッシュが圧縮コンテンツと非圧縮コンテンツを区別することを認識できるようにします。
Varyヘッダーについての脇
The Vary ヘッダーは、キャッシュ内のエントリを希釈することを犠牲にして、同じコンテンツの異なるバージョンを保存する機能を提供します。
の場合 Accept-Encoding、設定 Vary ヘッダーを使用すると、圧縮されたコンテンツと圧縮されていないコンテンツを明確に区別できます。 これは、圧縮されたコンテンツを処理できないブラウザにこれらのアイテムを正しく提供するために必要であり、基本的なユーザビリティを提供するために必要です。 あなたにそれを伝える1つの特徴 Accept-Encoding の良い候補かもしれません Vary 可能な値は2つか3つしかないということです。
のようなアイテム User-Agent 一見すると、モバイルブラウザとデスクトップブラウザを区別して、サイトのさまざまなバージョンを提供するのに適しているように思われるかもしれません。 しかし、 User-Agent 文字列は非標準であるため、中間キャッシュに同じコンテンツの多くのバージョンがあり、キャッシュヒット率が非常に低くなる可能性があります。 The Vary 特に、制御する中間キャッシュでリクエストを正規化する機能がない場合は、ヘッダーを慎重に使用する必要があります（たとえば、コンテンツ配信ネットワークを利用している場合など）。
キャッシュ制御フラグがキャッシングに与える影響
上記で、どのように Cache-Control ヘッダーは、最新のキャッシュポリシー仕様に使用されます。 このヘッダーを使用して、複数の命令をコンマで区切って、さまざまなポリシー命令を設定できます。
いくつかの Cache-Control コンテンツのキャッシュポリシーを指示するために使用できるオプションは次のとおりです。
- no-cache ：この命令は、キャッシュされたコンテンツをクライアントに提供する前に、リクエストごとに再検証する必要があることを指定します。 これにより、事実上、コンテンツはすぐに古くなったものとしてマークされますが、再検証手法を使用して、アイテム全体を再度ダウンロードすることを回避できます。
- no-store ：この命令は、コンテンツをキャッシュできないことを示します。 これは、応答が機密データを表す場合に設定するのに適しています。
- public ：これは、コンテンツをパブリックとしてマークします。これは、コンテンツをブラウザーおよび任意の中間キャッシュでキャッシュできることを意味します。 HTTP認証を利用したリクエストの場合、レスポンスはマークされます
privateデフォルトでは。 このヘッダーはその設定を上書きします。 - private ：これはコンテンツを次のようにマークします
private. プライベートコンテンツはユーザーのブラウザによって保存される場合がありますが、中間者によってキャッシュされてはなりません。 これは、ユーザー固有のデータによく使用されます。 - max-age ：この設定は、コンテンツを再検証するか、オリジンサーバーからコンテンツを再ダウンロードする前にコンテンツをキャッシュできる最大経過時間を設定します。 本質的に、これは
Expires最新のブラウジング用のヘッダーであり、コンテンツの鮮度を判断するための基礎となります。 このオプションの値は秒単位で、有効な最大更新時間は1年（31536000秒）です。 - s-maxage ：これは
max-ageコンテンツをキャッシュできる時間を示すという点で、設定。 違いは、このオプションが中間キャッシュにのみ適用されることです。 これを上記と組み合わせると、より柔軟なポリシー構築が可能になります。 - must-revalidate ：これは、
max-age,s-maxageまたはExpiresヘッダーは厳密に従わなければなりません。 古いコンテンツは、いかなる状況でも提供できません。 これにより、ネットワークの中断や同様のシナリオでキャッシュされたコンテンツが使用されるのを防ぎます。 - proxy-revalidate ：これは上記の設定と同じように動作しますが、中間プロキシにのみ適用されます。 この場合、ユーザーのブラウザを使用して、ネットワークが中断した場合に古いコンテンツを提供できる可能性がありますが、この目的で中間キャッシュを使用することはできません。
- no-transform ：このオプションは、パフォーマンス上の理由から、どのような状況でも受信したコンテンツを変更できないことをキャッシュに通知します。 これは、たとえば、キャッシュが圧縮されたオリジンサーバーから受信しなかったコンテンツの圧縮バージョンを送信できず、許可されないことを意味します。
これらをさまざまな方法で組み合わせて、さまざまなキャッシュ動作を実現できます。 相互に排他的な値は次のとおりです。
no-cache,no-store、およびいずれかがないことによって示される通常のキャッシュ動作publicとprivate
The no-store オプションは no-cache 両方が存在する場合。 認証されていない要求への応答については、 public 暗示されます。 認証されたリクエストへの応答については、 private 暗示されます。 これらは、反対のオプションをに含めることでオーバーライドできます。 Cache-Control ヘッダ。
キャッシング戦略の開発
完璧な世界では、すべてが積極的にキャッシュされる可能性があり、コンテンツを検証するためにサーバーに接続されるのはたまにしかありません。 ただし、これは実際にはあまり発生しないため、長期的なキャッシュの実装と変化するサイトの要求への対応のバランスをとることを目的とした、適切なキャッシュポリシーを設定する必要があります。
一般的な問題
コンテンツの生成方法（ユーザーごとに動的に生成される）またはコンテンツの性質（機密性の高い銀行情報など）が原因で、キャッシュを実装できない、または実装すべきでない状況は数多くあります。 キャッシュを設定するときに多くの管理者が直面するもう1つの問題は、新しいバージョンが公開されていても、古いバージョンのコンテンツがまだ古くなっていない状態で公開されている状況です。
これらは両方とも頻繁に発生する問題であり、キャッシュのパフォーマンスと提供するコンテンツの精度に深刻な影響を与える可能性があります。 ただし、これらの問題を予測するキャッシュポリシーを開発することで、これらの問題を軽減できます。
一般的な推奨事項
状況によって使用するキャッシュ戦略が決まりますが、次の推奨事項は、いくつかの合理的な決定に向けてガイドするのに役立ちます。
使用する特定のヘッダーについて心配する前に、キャッシュヒット率を上げるために実行できる特定の手順があります。 いくつかのアイデアは次のとおりです。
- 画像、css、共有コンテンツ用の特定のディレクトリを確立する：コンテンツを専用のディレクトリに配置すると、サイトのどのページからでも簡単に参照できるようになります。
- 同じURLを使用して同じアイテムを参照する：キャッシュはホストと要求されたコンテンツへのパスの両方をキーオフするため、すべてのページで同じ方法でコンテンツを参照するようにしてください。 以前の推奨事項により、これは非常に簡単になります。
- 可能な場合はCSS画像スプライトを使用する：アイコンやナビゲーションなどのアイテムにCSS画像スプライトを使用すると、サイトのレンダリングに必要なラウンドトリップの数が減り、サイトがその単一のスプライトを長期間キャッシュできるようになります。
- 可能な場合はローカルでスクリプトと外部リソースをホストする：JavaScriptスクリプトとその他の外部リソースを利用する場合、正しいヘッダーがアップストリームで提供されていない場合は、それらのリソースを独自のサーバーでホストすることを検討してください。 ローカルコピーを更新できるように、アップストリームのリソースに加えられた更新に注意する必要があることに注意してください。
- フィンガープリントキャッシュアイテム：CSSやJavascriptファイルなどの静的コンテンツの場合、各アイテムにフィンガープリントを付けることが適切な場合があります。 これは、ファイル名に一意の識別子（多くの場合ファイルのハッシュ）を追加して、リソースが変更された場合に新しいリソース名を要求できるようにすることを意味します。これにより、要求はキャッシュを正しくバイパスします。 フィンガープリントを作成し、HTMLドキュメント内でそれらへの参照を変更するのに役立つさまざまなツールがあります。
さまざまなアイテムの正しいヘッダーを選択するという点で、以下は一般的なリファレンスとして役立ちます。
- すべてのキャッシュに汎用アセットの保存を許可する：静的コンテンツおよびユーザー固有ではないコンテンツは、配信チェーンのすべてのポイントでキャッシュでき、キャッシュする必要があります。 これにより、中間キャッシュが複数のユーザーのコンテンツに応答できるようになります。
- ブラウザがユーザー固有のアセットをキャッシュできるようにする：ユーザーごとのコンテンツの場合、ユーザーのブラウザ内でのキャッシュを許可することは、多くの場合、受け入れられ、便利です。 このコンテンツは、中間のキャッシュプロキシにキャッシュするのには適切ではありませんが、ブラウザでキャッシュすると、その後のアクセス時にユーザーが即座に取得できるようになります。
- 重要な時間に敏感なコンテンツの例外を作成する：時間に敏感なコンテンツがある場合は、上記のルールに例外を設けて、古いコンテンツが重大な状況で配信されないようにします。 たとえば、サイトにショッピングカートがある場合、カート内のアイテムをすぐに反映する必要があります。 コンテンツの性質に応じて、
no-cacheまたno-storeオプションはで設定することができますCache-Controlこれを達成するためのヘッダー。 - 常にバリデーターを提供する：バリデーターを使用すると、リソース全体を再度ダウンロードしなくても、古いコンテンツを更新できます。 の設定
EtagそしてそのLast-Modifiedヘッダーを使用すると、キャッシュはコンテンツを検証し、元の場所で変更されていない場合はコンテンツを再予約できるため、負荷がさらに軽減されます。 - コンテンツをサポートするための長い鮮度時間を設定する：キャッシュを効果的に活用するために、リクエストを満たすためにサポートコンテンツとしてリクエストされる要素は、多くの場合、長い鮮度設定を持つ必要があります。 これは通常、ユーザーが要求したHTMLページをレンダリングするために取り込まれる画像やCSSなどのアイテムに適しています。 フィンガープリントと組み合わせてフレッシュネス時間を延長することで、キャッシュはこれらのリソースを長期間保存できます。 アセットが変更された場合、変更されたフィンガープリントはキャッシュされたアイテムを無効にし、新しいコンテンツのダウンロードをトリガーします。 それまでは、サポートアイテムを遠い将来にキャッシュすることができます。
- 親コンテンツの鮮度を短く設定する：上記のスキームを機能させるには、含まれているアイテムの鮮度を比較的短くする必要があります。そうしないと、キャッシュされない場合があります。 これは通常、他の支援コンテンツを呼び出すHTMLページです。 HTML自体は頻繁にダウンロードされるため、変更に迅速に対応できます。 その後、サポートコンテンツを積極的にキャッシュできます。
重要なのは、変更が行われたときに将来エントリを無効にする機会を残しながら、可能な場合は積極的なキャッシュを優先するバランスをとることです。 あなたのサイトはおそらく以下の組み合わせを持っているでしょう：
- 積極的にキャッシュされたアイテム
- 更新時間が短く、再検証できるキャッシュされたアイテム
- まったくキャッシュしてはいけないアイテム
目標は、許容可能なレベルの精度を維持しながら、可能な場合はコンテンツを最初のカテゴリに移動することです。
結論
サイトに適切なキャッシュポリシーが設定されていることを確認するために時間をかけると、サイトに大きな影響を与える可能性があります。 キャッシングを使用すると、同じコンテンツを繰り返し提供することに関連する帯域幅コストを削減できます。 サーバーは、同じハードウェアでより多くのトラフィックを処理することもできます。 おそらく最も重要なことは、クライアントがサイトでより速く体験できるようになることです。これにより、クライアントはより頻繁に戻ってくる可能性があります。 効果的なWebキャッシングは特効薬ではありませんが、適切なキャッシングポリシーを設定すると、最小限の作業で測定可能な利益を得ることができます。
