AEM サイトキャッシュの最適化
AEMアーキテクチャ内でキャッシュを最適化することは、パフォーマンスを大幅に向上させる最も迅速な方法のひとつです。 この記事では、AEM アーキテクチャ内で利用可能なさまざまなキャッシュを最適化する方法について説明します。
説明 description
環境
Adobe Experience Manager 6.5
問題/症状
AEMのサイトキャッシュを最適化する方法?
AEMのアーキテクチャとキャッシュ
あらゆるAEMアーキテクチャでは、サイトを訪問すると複数のキャッシュレイヤーが表示されます。 標準的なAEMアーキテクチャでは、4つのキャッシュレイヤーを考慮する必要があります。 これには、Web ブラウザー、CDN、Dispatcher、AEM インスタンスが含まれます。
解決策 resolution
A. ブラウザーキャッシュ
サイトを繰り返し訪れたユーザーが最初に遭遇するキャッシュのレベルは、ユーザー自身のブラウザーです。 ブラウザーレベルでのキャッシュは、通常、Cache-Control: max-age=…応答 ヘッダーを介して実行されます。 max-age設定は、ブラウザーに対して、ファイルを「再検証」またはサイトから再要求する前に、ファイルをキャッシュする時間を秒単位で示します。 このキャッシュ max-ageの概念は、一般的に「キャッシュの有効期限」またはTTL (「有効期間」)と呼ばれます。
Cache-Control ヘッダー内には、キャッシュの実行方法に影響する様々なオプション(または「ディレクティブ」)があります。 一般的なディレクティブを以下に示します。
-
private - Cache-Control ヘッダーのprivate ディレクティブを使用すると、ファイルはCDNなどの中間キャッシュではなく、ブラウザーにのみキャッシュされます。 このディレクティブの実用的な使い方は、ページにパーソナライズされた/ユーザー固有のコンテンツが含まれている場合です。
使用例:
Cache-Control: max-age=300, private -
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から存在し、キャッシュに影響を与える可能性があります。 これらのヘッダーは 有効期限 および Pragma です。 非常に古いブラウザーをサポートする必要がない場合は、これらの応答ヘッダーを送信しないでください。
キャッシュに加えて、再検証も重要な概念です。 再検証は、Last-Modified (response) / If-Modified-Since (request)ヘッダーとETag (response) / If-None-Match (request)ヘッダーに依存しています。
ブラウザーテストに関する注意:
Google Chromeでキャッシュをテストする際に、https経由でテストを行っていて、自己署名証明書がある場合、何もキャッシュされません。 信頼されていない証明書または無効な証明書がある場合、Chromeは応答をキャッシュしたり、再検証を実行したりしません。
Dispatcherに関するメモ:
AEM Dispatcher v4.2.3以前のバージョンで、/enableTTLがmax-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でファイルを最適にキャッシュするには、いくつかの手順があります。
-
Cache-Control ヘッダーの stale-while-revalidate およびstale-if-error ディレクティブをサポートするCDNを使用します。
- stale-while-revalidate – このディレクティブは、キャッシュファイルの有効期限が切れた後に新しいバージョンを取得する際に、CDNにファイルの古い(既にキャッシュされている)バージョンを提供するように指示します。
- stale-if-error – 同様に、このディレクティブは、オリジンが再検証中にエラーで応答した場合に、古い(既にキャッシュされた)バージョンのファイルを提供するようにCDNに指示します。
-
事前に圧縮されていないすべてのファイルタイプに対するGZip圧縮応答。
これは、Dispatcher レベルから実行する必要があります。 これにより、CDNに送信されるバイト数が減ります。 CDNでは、通常、転送されたバイト単位で課金されるため、応答を圧縮するとコストが削減されます。
-
Dispatcher レベルでGZip圧縮を有効にします。Apache - mod_deflateを使用します。 mod_deflateのVaryの使用には注意してください。 Vary ヘッダーによって、CDNとブラウザーがキャッシュを完全にスキップする場合があります。
-
Microsoft IIS - Dynamic Compressionを使用します。
-
大きなファイルや既に圧縮されているファイルの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 プロバイダーを次に示します。
- Microsoft Azure CDN
- Amazon Cloudfront
- Akamai
- Google Cloud CDN
- Rackspace CDN
- Stackpath CDN (旧称:Max CDN)
- Cloudflare
- Fastly
- F5 Networks CDN
他にもいくつかあり、それぞれ特徴が異なります。
注意:
Vary応答ヘッダーに注意してください。 場合によっては、Varyにより、CDNとブラウザーの両方がキャッシュを完全にスキップする可能性があります。 一般的な経験則として、Vary: Accept-Encoding以外の Vary を追加しないでください(応答がgzip圧縮されている場合にのみ適用されます)。 つまり、レスポンスの出力を「変更」する必要がある場合は、別のURLを使用します。
例えば、HTML モバイル版とデスクトップ版が異なる場合は、別のURLを使用します。 これにより、CDNとブラウザーがより効果的にキャッシュできるようになります。
C. AEM Dispatcherのキャッシュ
CDN キャッシュの有効期限が切れた場合、リクエストはAEM Dispatcher キャッシュに到達します。 このレベルでは、キャッシュを最適化するために実行できることがたくさんあります。 手順については、Dispatcher キャッシュを最適化する方法を参照してください。
D. AEM パブリッシュインスタンス
AEM レベルでは、さまざまなキャッシュ レイヤーを最適化するために行うべきことがいくつかあります。
-
デフォルトでAEMによって設定されていない次のHTTP レスポンスヘッダーを設定します。
- Cache-Control: max-age=… – このヘッダーを設定するには、ACS Commons - Dispatcher TTLを使用するか、カスタムコードを実装して設定します。
- Last-Modified - ページのコンテンツが記事など比較的静的な場合、最終変更ヘッダーをcq:lastModifiedの日時(記事が最後に変更された時間)に設定できます。 ただし、コンポーネントコンテンツに含まれるJCR クエリ結果を使用してページが動的な場合は、現在の日時を使用するように設定することをお勧めします。
- ETag - Last-Modifiedの代わりにこれを使用する場合は、ページアクティベーションをリッスンし、ページコンテンツのmd5 ハッシュを生成するReplicationEventListenerを記述できます。 これは、オーサーインスタンス上のページのjcr:content ノードのプロパティとして設定できます。 ページがレプリケートされると、パブリッシュインスタンスに送信されます。 比較的静的なコンテンツを持つページコンポーネントの場合、これは問題なく機能する可能性がありますが、ページが少し動的な場合や大量のコンテンツを参照する場合は、ETagを省略(または計算)する必要があります。
-
サイトにパーソナライズされた/動的なコンテンツがある場合:
-
Apache Sling Dynamic Includesを使用してコンテンツを分割し、ページのさまざまな部分を異なる期間キャッシュできるようにします。
-
キャッシュは、次のテクノロジーで実行できます。
- CDN上のEdge側インクルード(ESI)
- サーバーサイドのインクルード(SSI) web サーバー上
- ブラウザー上の非同期JavascriptとXML (AJAX)
-
ページ上のコンポーネントを個別のリクエストに分割し、異なる期間キャッシュすることができます。 ページ内で比較的静的な部分は、より長い期間キャッシュできます。
-
-
ACS Commons🔗のHTTP キャッシュ機能の使用を検討してください。
-
-
クライアントライブラリの最適化:
-
クライアントライブラリで縮小を有効にします。
-
クライアントライブラリ内のファイルが事前に縮小されている場合は、そのクライアントライブラリの縮小を無効にします。 cq:ClientLibraryFolder ノードを編集します。
- 値がmin:noneのString
[]型のプロパティ jsProcessorを設定します - プロパティ cssProcessorを値min:noneのString
[]型で設定します - 詳細については、こちらを参照してください。
- 値がmin:noneのString
-
クライアントライブラリ を埋め込んで、jsおよびcss ファイルを縮小および縮小します。
-
ACS Commons🔗から バージョン管理されたclientlibsを実装して、CDNおよびDispatcherがjsおよびcss ファイルを長時間キャッシュできるようにします。
-