私の知る限り、これはユースケースに基づく決定であり、すべてのシナリオに適合する単一のアプローチはありません-
コンポーネント レベルでの CSS の読み込み
コンポーネント レベルで CSS を読み込むと、ページ レンダリング プロセスが開始されたときに HEAD セクションで CSS を使用できません。body タグのどこかでコンポーネント CSS が検出された場合にのみ、コンポーネント CSS をレンダリングします。
コンポーネントに基づいて CSS を条件付きで読み込むことは、デフォルトでは利用できません。これを実現するには、カスタム ロジックを記述する必要があります。この投稿から、
これを実現する 1 つの方法は、その動作を傍受することです。フィルターを使用して、メモリ内の出力バッファーに書き込まれたすべてのデータをバッファーします。その後、すべてのコンポーネントを安全にレンダリングできます。特別なコンポーネントに遭遇した場合は、リクエスト属性にフラグを設定できます。フィルターはこれらの属性をチェックし、それに応じてバッファーを変更してから、すべてを送信できます。このアプローチは、大量のメモリを消費する可能性があるため、少し危険
です。また、ページのレンダリング パフォーマンスと動作が変わります。でも試してみる価値はあるかもしれません。
また、コンポーネント レベルの CSS では、コンポーネントのスタイルが別のコンポーネントのスタイルに影響を与えないようにする必要があります。つまり、狭いセレクターを使用してこれを行う必要があり、プロセスで他のものを壊さないようにする必要があります。
また、コンポーネント レベルの CSS では、コンポーネントのスタイルが別のコンポーネントのスタイルに影響を与えないようにする必要があります。つまり、狭いセレクターを使用してこれを行う必要があり、プロセスで他のものを壊さないようにする必要があります。
その他のアプローチ
ページ コンポーネントの使用- 多くのスタイルを持つコンポーネントがあり、これを他のすべてのページにロードしたくない場合は、ページ コンポーネント (異なるテンプレート) を使用してこれを実現できます。各ページ コンポーネントは、その用途に基づいて異なるクライアント ライブラリのグループをロードできます。
deferred clientlibs の使用- レイアウトが頻繁に変更され、clientlibs ファイルがどれだけ大きくなったか心配な場合は、deferred clientlibs の方が適している可能性があります。以下のリンクの例 -
… [Navigation component logic]
<ici:js-defer>
<cq:includeClientLib js=”icidigital.components.navigation”/>
</ici:js-defer>
[Navigation component end]
… [Sitemap component logic]
<ici:js-defer>
<cq:includeClientLib js=”icidigital.components.siteMap”/>
</ici:js-defer>
[Sitemap component end]
becomes…
<div class=”footer” />
<script type=”text/javascript” src=”path/to/programmatically/combined/deferred/clientlib.js”></script>
</div>
どのようなアプローチを取るにしても、キャッシュ、ページの読み込み時間、メンテナンス、パフォーマンスなどが考慮されていることを確認してください。
さらに読む
AEM の clientlibs への最適なアプローチ
clientlibs の CSS ベスト プラクティス