AEMのサイトキャッシュの最適化

AEM アーキテクチャ内のキャッシュの最適化は、パフォーマンスを大幅に向上させる最も迅速な方法の 1 つです。 この記事では、AEM アーキテクチャ内で使用できる様々なキャッシュを最適化する方法について重点的に説明します。

説明 description

環境

Adobe Experience Manager 6.5

問題/症状

AEMのサイトキャッシュを最適化するにはどうすればよいですか?

AEMのアーキテクチャとキャッシング

すべてのAEM アーキテクチャでは、サイトを訪問すると、複数のキャッシュレイヤーが発生します。 標準のAEM アーキテクチャで考慮すべき 4 つのキャッシュレイヤーがあります。 これには、Web ブラウザー、CDN、Dispatcher、AEM インスタンスが含まれます。

解決策 resolution

A. ブラウザーのキャッシュ

サイトの繰り返し訪問時にユーザーが遭遇するキャッシュの最初のレベルは、ユーザー自身のブラウザーです。 ブラウザーレベルでのキャッシュは、通常、Cache-Control: max-age=… 応答 header を使用して行われます。 max-age 設定は、「再検証」を試みたり、サイトから再リクエストを試みるまでの、ファイルをキャッシュする秒数をブラウザーに指示します。 このキャッシュの概念 max-age は、一般的に「キャッシュの有効期限」または TTL (「有効期間」)と呼ばれます。

Cache-Control ヘッダーには、キャッシュの実行方法に影響を与える様々なオプション(または「ディレクティブ」)があります。 次に、一般的なディレクティブを示します。

  1. private - Cache-Control ヘッダーの private ディレクティブでは、ファイルが CDN などの中間キャッシュではなく、ブラウザーにのみキャッシュされるようにします。 このディレクティブは、ページにパーソナライズされたユーザー固有のコンテンツが含まれる場合に使用すると効果的です。

    使用例:Cache-Control: max-age=300, private

  2. s-maxage - Cache-Control ヘッダーの s-maxage ディレクティブを使用すると、CDN などの共有キャッシュに異なる TTL を設定できます。 この値が設定されている場合、ブラウザーは max-age で設定されたものを使用し、他のキャッシュは代わりに s-maxage の設定を適用します。

    使用例:Cache-Control: max-age=600, s-maxage=300

最新のブラウザーはすべて Cache-Control ヘッダーをサポートしていますが、HTTP/1.0 から古い非推奨ヘッダーが存在する場合は、キャッシュに影響する可能性があります。 これらのヘッダーは ExpiresPragma です。 非常に古いブラウザーをサポートする必要がない場合は、それらの応答ヘッダーを送信しないでください。

キャッシュに加えて、再検証も重要な概念です。 再検証は、Last-Modifiedresponse)/If-Modified-Sincerequest)ヘッダー、および ETag (応答)/If-None-Match (リクエスト)ヘッダーに依存します。

ブラウザーテストに関する注意:

Google Chromeでキャッシュをテストする場合、https 経由でテストしており、自己署名証明書がある場合、何もキャッシュされません。 信頼できない証明書または無効な証明書がある場合、Chromeは応答をキャッシュしたり、再検証を実行したりしません。

Dispatcher に関するメモ:

AEM Dispatcher v4.2.3 以前のバージョンでは、/enableTTLmax-age ディレクティブを使用してのみキャッシュされる問題があります。 つまり、private または s-maxage ディレクティブが設定されていても、max-age が設定されていれば、キャッシュされます。 この問題はDispatcher 4.2.4 以降のバージョンで解決されています。

B. CDN キャッシュ

CDN (「コンテンツ配信ネットワーク」 ​ は、コンテンツをキャッシュしてユーザーに最も近い場所から提供するように設計された、web サーバーの分散ネットワークです。 これにより、ネットワークホップやユーザーのコンピューターからコンテンツまでの距離が減少し、​ ラウンドトリップ時間」(RTT) ​ が短縮されます。 RTT は、ブラウザーがリクエストをサイトに送信して応答を受け取るまでにかかる時間です。 CDN プロバイダー領域における競争により、CDN は非常にコスト効率に優れています。 これにより、サイトに CDN を使用するかの決定が容易になります。 まだ CDN を使用していない場合は、サイトに CDN を組み込む必要があります

CDN プロバイダーは多数あり、それぞれが異なる機能と設定を提供します。

CDN キャッシュはどのように機能しますか?

CDN は、ブラウザーと同様のルールに従ってコンテンツをキャッシュします。 Cache-Control HTTP response ヘッダーに依存し、通常、Cache-Control ヘッダーが見つからない場合は Expires ヘッダーにフォールバックします。

ほとんどの CDN は、キャッシュの手動フラッシュをトリガーにする何らかの方法を提供します。  多くの場合、キャッシュフラッシュは、ファイルを持つすべてのエッジサーバーへの伝播に関して、ある程度の遅延(例:15 分)を伴います。

CDN 使用の最適化

CDN でファイルを最適にキャッシュするには、次のようないくつかの手順があります。

  1. Cache-Control ヘッダーの stale-while-revalidate および stale-if-error ディレクティブをサポートする CDN を使用します。

    • stale-while-revalidate – このディレクティブは、キャッシュファイルの有効期限が切れた後に新しいバージョンを取得する間、ファイルの古い(既にキャッシュされている)バージョンを提供するように CDN に指示します。
    • stale-if-error – 同様に、このディレクティブは、オリジンが再検証中にエラーを応答したときに、CDN にファイルの古い(既にキャッシュされている)バージョンを提供するように指示します。
  2. 事前に圧縮されていないすべてのファイルタイプの応答を GZip で圧縮します。

    これは、Dispatcher レベルから実行する必要があります。 これにより、CDN に送信されるバイト数を確実に減らすことができます。 CDN は通常、転送されたバイト数で課金されるため、応答を圧縮するとコストが削減されます。

    • Dispatcher レベルで GZip 圧縮を有効にする:Apache - use mod_deflate mod_deflate の Vary の使用には注意してください。 場合によっては、Vary ヘッダーが原因で、CDN とブラウザーがキャッシュを完全にスキップすることがあります。

    • Microsoft IIS - ​ 動的圧縮 ​ を使用します。

    • 大きなファイルや既に圧縮されているファイルの gzip 圧縮は許可しないでください。 ほとんどの画像およびビデオ形式は、既に圧縮済みです。 Web サーバーレベルでその場で圧縮すると、パフォーマンスに非常に高いコストがかかります。

      • Apache では、AddOutputFilterByType ディレクティブ(AddOutputFilterByType ディレクティブ) DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript を使用して実行できます。
      • IIS では、< dynamicTypes> 設定を使用して制御できます。
    • CDN プロバイダーが Edge側インクルード ​ (ESI)をサポートしている場合は、この機能を活用します。 AEMのコンポーネントは、ESI を使用して分割できます。 これをおこなうには、Apache \[ Sling Dynamic Includes を使用するか \] カスタムソリューションを実装します。 これは、かなり静的なページであっても、ページの一部でより動的なコンテンツを提供している場合に便利です。 このような場合、基本的にページを複数の CDN ファイルに分割します。 これにより、ページの様々な部分を異なる期間キャッシュできます。

一般的な CDN プロバイダー

一般的な CDN プロバイダーのリストを以下に示します。

その他にもいくつかあり、それぞれ異なる機能を備えています。

注意:

Vary 応答ヘッダーには注意が必要です。 場合によっては、Vary によって、CDN とブラウザーの両方がキャッシュを完全にスキップする可能性があります。 一般的な経験則として、Vary: Accept-Encoding を除き Vary を追加しないでください(応答が gzip で圧縮されている場合にのみ適用されます)。 つまり、応答の出力を「変更」する必要がある場合は、別の URL を使用します。

例えば、モバイル用とデスクトップ用でHTMLのバージョンが異なる場合は、別の URL を使用します。 これにより、CDN とブラウザーがより効果的にキャッシュできるようになります。

C. AEM Dispatcherのキャッシュ

CDN キャッシュの有効期限が切れると、リクエストはAEM Dispatcher キャッシュに到達します。 このレベルでは、キャッシュを最適化するために実行できる処理が多数あります。 手順については、Dispatcher キャッシュを最適化する方法 ​ を参照してください。

D. AEM パブリッシュインスタンス

AEM レベルでは、様々なキャッシュレイヤーを最適化するために行うべきことがいくつかあります。

  1. AEMでデフォルトとして設定されていない HTTP 応答ヘッダーを以下のように設定します。

    1. Cache-Control: max-age=… – このヘッダーを設定するには、ACS Commons - Dispatcher TTL を使用するか、カスタムコードを実装して設定することができます。
    2. Last-Modified - ページコンテンツが記事のように比較的静的な場合、last-modified ヘッダーを cq:lastModified 日時(記事が最後に変更された日時)に設定できます。 ただし、ページが動的で、JCR クエリ結果がコンポーネントコンテンツに含まれる場合は、現在の日付/時刻を使用するように設定することをお勧めします。
    3. ETag - Last-Modified の代わりにこれを使用することにした場合、ページのアクティベーションをリッスンしてページコンテンツの md5 ハッシュを生成する ReplicationEventListener を記述できます。 これは、オーサーインスタンスのページの jcr:content ノードでプロパティとして設定できます。 ページがレプリケートされると、そのページはパブリッシュインスタンスに送信されます。 比較的静的なコンテンツを含むページコンポーネントの場合は正常に機能しますが、ページがある程度動的な場合や、ロットのコンテンツを参照する場合は、ETag を省略(または計算)する必要があります。
  2. サイトにパーソナライズされた動的コンテンツがある場合:

    1. Apache Sling Dynamic Includes を使用してコンテンツを分割し、ページの異なる部分を異なる期間キャッシュできるようにします。

      1. キャッシュは、次のテクノロジーで実行できます。

        • CDN のEdgeサイドインクルード(ESI)
        • Web サーバー上のサーバーサイドインクルード(SSI)
        • ブラウザーでの非同期 JavaScript および XML (AJAX)
      2. ページ上のコンポーネントは、異なる期間キャッシュできる個別のリクエストに分割できます。 ページの比較的静的な部分は、はるかに長い期間キャッシュできます。

    2. ACS Commons の HTTP キャッシュ機能 ​ の使用を検討してください。

  3. クライアントライブラリを最適化します。

    1. クライアントライブラリで縮小を有効にします。

    2. クライアントライブラリのファイルが事前に縮小されている場合は、そのクライアントライブラリで縮小を無効にします。 cq:ClientLibraryFolder ノードを編集します。

      1. 文字列型のプロパティ jsProcessor を設定します [ 値は min:none]
      2. 文字列タイプの cssProcessor プロパティを設定します []min:none です
      3. 詳しくは、​ こちら ​ を参照してください。
    3. ​ クライアントライブラリを埋め込む ​js ファイルと css ファイルを縮小および縮小します。

    4. ACS Commons のバージョン管理された clientlibs を実装して、CDN とDispatcherが JS ファイルと CSS ファイルを長期にわたってキャッシュできるようにします。

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f