Dynamics 365 Commerce 開発のベスト プラクティス
この記事では、Dynamics 365 Commerce カスタマイズを開発する際に従ういくつかのベスト プラクティスについて説明します。
Dynamics 365 Commerce プラットフォームは、開発者の拡張性のために豊富なオンライン ソフトウェア開発キット (SDK) を提供します。 カスタム モジュール、データ アクション、およびテーマを作成したり、コマースモジュール ライブラリのモジュールを拡張することもできます。 コマースのカスタマイズを構築する際は、Web サイトのパフォーマンスを考慮することが重要です。 HTML、JavaScript、および CSS ファイルの最小化、画像の最適化など、Web サイトの開発に使用される標準的なベスト プラクティスを適用できます。
インフラストラクチャの設定
Dynamics 365 Commerce エコシステムは、Commerce Headquarters、Commerce Scale Unit、ノード レンダリング サービスを含むウェブストア、Commerce サイト ビルダー、製品推奨サービスなど、さまざまなサブシステムで構成されています。 最も高いパフォーマンスを実現するために、さまざまなコンポーネントを同じリージョンに配置する必要があります。 リージョンに関する特定の決定は、顧客のリージョンの場所に従って行う必要があります。
メモ
Commerce Scale Unit では、設定時に特定のリージョンを選択できます。
HTML、CSS、および JavaScript ファイル サイズの最小化
Dynamics 365 Commerce オンライン SDK は、TypeScript およびサッシー カスケード スタイル シート (SCSS) ファイルを使用する開発拡張機能を提供します。 yarn msdyn365 pack コマンドを使用して構成パッケージを作成する場合、または yarn start コマンドを使用してローカル開発環境でノード サーバーを起動する場合、TypeScript ファイルは JavaScript ファイルにコンパイルされ、SCSS ファイルはカスケード スタイル シート (CSS) ファイルにコンパイルされます。 これらのファイルは、ネットワーク帯域幅を削減するために縮小されます。 余分な未使用の JavaScript および CSS ファイルが拡張機能パッケージに含まれていないことを確認する必要があります。
使用されていないモジュールを除外して JavaScript を削減する
Dynamics 365 Commerce には、Commerce モジュール ライブラリと呼ばれる大規模なモジュール セットが含まれています。 E コマース サイトで使用しないモジュールがある場合は、そのモジュールを除外して JavaScript のチャンク サイズを削減することができます。 除外したモジュールは、実際の E コマース サイトでは表示されません。また、ページの作成時にCommerce サイト ビルダー内で使用することもできます。
次の例に示すように、SDK の "/src/settings/platform.settings.json" ファイルの excludeModules プロパティにモジュール名を追加することで、モジュールを除外できます。
{
"excludedModules": ["<EXCLUDED_MODULE_NAME1>","<EXCLUDED_MODULE_NAME2>"]
}
ビルド後に表示されるチャンク サイズを比較するか、モジュールを開発環境でテストすることで、モジュールが正常に除外されたことを確認できます。 後者の方法の場合は、URL http://localhost:4000/modules?type=<your-module-name> を使用して除外したモジュールが表示されないことを確認できます ("yarn start" コマンドを使用してノード サーバーを実行した後)。
画像の最適化
Web ページの最大パフォーマンス ヒットの 1 つが、画像のダウンロードです。 ボタンなどの項目の画像を生成するには、できる限り CSS を使用する必要がありますが、マーケティングや製品の画像が必要な場合は、Commerce サイト ビルダーメディア ライブラリに画像をアップロードする必要があります。 メディア ライブラリにアップロードされる画像は、すべての Web サイトの使用シナリオをカバーするために、高い品質と解像度である必要があります。 メディア ライブラリから提供される画像は、画像サイズ変更サービスを使用して自動的にサイズが変更されます。
画像サイズ変更サービス
モジュール内で表示される場合、提供された画像は、Commerce レンダリング エンジンに含まれる画像サイズ変更サービスによって処理されます。 画像サイズが小さくなると、画像は特定のモジュールごとに最適なサイズに自動的に縮小されるため、これはレスポンシブ デザインにとって重要です。
画像のサイズが正しく変更されるように、いくつかのガイドラインに従うことが重要です。 モジュールは、theme.settings.json ファイルで特定のビュー ポートの画像サイズを指定できます。 詳細については、テーマ設定を構成する を参照してください。
画像を含むモジュールを作成する場合、HTML には常に幅と高さのパラメーターを含める必要があります。 幅と高さを指定しない場合、画像キャッシュは画像サイズ変更によって最適化されません。
画像のタイプとファイル サイズ
画像のファイル サイズを決定する際に重要な 3 つの側面があります。
- 画像の解像度 (幅と高さ)。
- 画像がエンコードされる方法 (JPEG、GIF、または PNG)。
- 品質パラメーター (JPEG のみ)。
JPEG は非可逆圧縮を使用し、画像の詳細を破棄してファイルサイズを小さくします。 破棄される詳細の量は、品質パラメーターによって制御されます。品質パラメーターは 0 ~ 100 の間の数で、100 が最も高い品質です。 品質が低いパラメーター番号を使用すると、画像の品質は低下しますが、ファイル サイズは小さくなります。
PNG は可逆形式なので、画像の詳細は失われますが、画像ファイルのサイズは大きくなります。 テキスト、シャープな線、または色のグラデーションを含む画像の場合、JPEG 形式では日か逆圧縮の結果として望ましくないコンポーネントが表示される可能性があるため、PNG を選択することをお勧めします。
GIF も可逆形式ですが、1 つの画像でサポートされるのは 256 色のみです。 テキストやシャープな線があり、色数も少ない画像の場合は、PNG または JPEG よりも GIF を選択することをお勧めします。 GIF は、単純なアニメーションもサポートしています。
最終的な目的は、画像サイズをできるだけ小さく保ちながら画質を維持するための適切なバランスを探ることです。
イメージとモジュールの遅延読み込み
遅延読み込みは、必要に応じてリソースの初期化を延期し、Web ページの読み込みを高速化します。 画像またはビデオを表示するほとんどのモジュール ライブラリのモジュールには、遅延読み込みを有効または無効にする構成プロパティがあります。 Web ページの読み込み時にすぐに表示する必要がある画像は、遅延読み込みを無効にして、すばやく表示されるようにすることをお勧めします。 ページの下部に表示されるような画像は、遅延読み込みを有効にする必要があります。
画像の遅延読み込みを無効にする
コンテンツ ブロック モジュールなどの画像を表示するモジュールは、通常、必要になるまで画像を読み込みません。 ユーザーが画像を表示する準備が整ったときに画像が読み込まれないため、この「遅延読み込み」動作により、パフォーマンスの問題が認識される可能性があります。 たとえば、ユーザーがカルーセル モジュールで「次」の矢印を選択した場合、遅延読み込みが有効になっていると、次の画像が読み込まれるまでに 1 ~ 2 秒かかる場合があります。 そのため、画像を表示するこれらのタイプのモジュールには、遅延読み込みを無効にできる構成設定があります。 その後、画像は必要になる前に読み込まれ、一部のシナリオではユーザーがパフォーマンスの向上を認識する場合があります。
次の図のイメージは、Commerce サイト ビルダーのコンテンツ ブロック モジュールに対して遅延読み込みの無効化オプションが有効になっている例を示しています。
モジュールの遅延読み込みの有効化
折り畳みの下にあるモジュール (つまり、ユーザーがページを下にスクロールするときにのみ表示されるモジュール) は、JavaScript を読み込みユーザーがページを下にスクロールした時に、必要に応じて表示されるように構成できます。 スクロールせずに表示される部分より上のモジュールが下のモジュールよりも先に表示されるため、ページの表示部分の読み込みが速くなります。
モジュールの遅延読み込みでは、モジュールごとに JavaScript バンドルを生成する必要があります。 この機能を有効にするには、"enableModuleEntryPoints": trueプラットフォーム設定を、src/settings/platform.settings.json ファイルに追加してください。
モジュールの遅延読み込みを有効にするには、サイト ビルダーで、次の例に示すようにモジュールのプロパティ ウィンドウでモジュール クライアント側をレンダリング オプションが有効になっていることを確認します。
メモ
製品収集モジュールの遅延読み込みは、別の方法で処理されます。次のセクションを参照してください。
製品収集モジュールに対する遅延読み込みの有効化
製品収集モジュールを呼び出すデータ アクションにより、ページの読み込み時間がわずかに増加する可能性があります。 したがって、製品収集モジュールには、ページが表示された後にクライアント側でモジュールを表示できるようにするモジュールの遅延読み込みの有効化構成設定があります。 この方法により、すぐにユーザーがページを操作できるようになります。 ただし、ページ上部近くに製品収集モジュールを配置した場合は、遅延読み込みを無効にして、Web ページの読み込み時に画像がすぐに表示されるようにすることをお勧めします。 この機能をするために、enableModuleEntryPoints プラットフォーム設定を src/settings/platform.settings.json ファイルに追加する必要はありません。
次の図は、Commerce サイト ビルダーの製品収集モジュールに対してモジュール遅延読み込みの有効化オプションが選択されている例を示しています。
ユーザー コンテキストを必要とするモジュールがクライアント側で読み込む必要があります
ユーザー コンテキストを必要とするカスタム モジュール (カスタム Cookie コンプライアンス モジュールなど) の場合は、モジュールがクライアント側で表示されるようにする必要があります。
キャッシュ コンフィギュレーション
キャッシュは、多くの場合、イメージ、製品コンテンツ、JavaScript と CSS ファイルなど、頻繁に変更しない静的コンテンツで使用されます。 パフォーマンスを最大限高めるために、カスタム キャッシュ設定が必要なシナリオがあります。
画像キャッシュ
画像の既定のコンテンツ配信ネットワーク (CDN) キャッシュ時間は 5 分に設定されています。 これは、5 分後に特定の画像を取得するための要求をオリジンから取得する必要があるため、処理が遅くなることを意味しています。 キャッシュ時間の設定を増やすことは可能ですが、サポート チケットを開いて行う必要があります。
データ キャッシュ
製品固有のデータは、E コマース表示ノード レイヤーにキャッシュされます。 キャッシュ時間はエンティティ タイプごとに異なり、SDK "/src/settings/" ディレクトリにある cache.settings.json ファイル内で構成できます。 詳細については、データ キャッシュの設定を参照してください。
ページ キャッシュ
ページ キャッシュを使用すると、E コマース サイトをサーバーにキャッシュしてそこからサイト ユーザーに提供できるため、パフォーマンス時間が大幅に向上します。 ページ キャッシュとキャッシュの期間は、サイト ページに対して Commerce サイト ビルダーで有効にして構成するか、複数のサイト ページに適用されるテンプレートに対して構成することができます。 詳細については、ページ キャッシュの構成 を参照してください。
ブラウザー ヒント メタ タグ
preconnect および dns-prefetch などのブラウザー ヒント メタ タグを使用して、ページを表示するために事前に必要なリソースをブラウザに伝えることができます。 そのようなタグを使用すると、ブラウザーは通常よりも早くネットワーク接続を開始し、時間のかかるネットワーク呼び出しを早く行うことができます。 これは、ページ内で使用される画像、フォント、またはファイルのエンドポイントの表示を追加する場合に役立ちます。
ページが外部元またはドメインからのリソースに依存して TCP 接続を開始する場合は、preconnectブラウザー ヒント メタ タグを使用できます。 これにより、DNS ルックアップ、TCP ハンドシェイク、および TLS ネゴシエーションが、HTML ドキュメントでの参照の前に発生します。
次は、HTML で使用される preconnect メタ タグ ヒントの例です。
<link rel="preconnect" href="https://<DOMAIN_TO_PRECONNECT>">
dns-prefetch ブラウザー ヒント メタ タグは、リソースがページ上で移動または使用される可能性が高い場合に使用できます。 DNS プリフェッチを使用すると、通常より早くドメインのアドレスを解決できるため、この時間のかかるステップを後で回避できます。
次は、HTML で使用される dns-prefetch ブラウザー ヒント メタ タグの例です。
<link rel="dns-prefetch" href="https://<DOMAIN_TO_PREFETCH>">
ページにメタ タグの追加は、Metatags モジュールを使用して、Commerce サイト ビルダーで行うことができます。 Metatags モジュールは、ページ テンプレートの ”HTML ヘッド” セクションに追加する必要があります。 詳細については、テンプレートの使用を参照してください。
パフォーマンス分析
E コマース サイトのページを公開する前にパフォーマンス テストを行うことは非常に重要です。 この目的のために、さまざまな既存の Web ページ パフォーマンス テスト ツールを使用できます。 少なくとも、Web ブラウザーの F12 開発者ツールを使用して、ページの個々の部分のネットワーク負荷を調べることができます。 この方法は、パフォーマンス ボトルネックを特定して、さらに調査するのに役立ちます。
E コマースの Web サイトが外部 Web サイトの HTML iframe 要素内に読み込まれないように制限する
frame-ancestors ディレクティブを使用して、外部 Web サイトのHTML iframe 要素内での E コマース サイトの読み込みを制限できます。 Commerce サイト ビルダーでこの機能を構成する方法の詳細については、コンテンツ セキュリティー ポリシーの管理を参照してください。
Top(N) 改ページ位置の自動修正のパラメーターを指定して、Retail API へのデータ アクション API 呼び出しを最適化する
Retail データ アクションを使用して検索、リスト、またはその他の改ページ位置の自動修正の結果を返すモジュールの場合、Top(N) パラメーターが Web パフォーマンス用に最適化されていることを確認する必要があります。 これらのデータアクションを呼び出すネイティブ ライブラリ モジュール (たとえば、リスト ページに使用される検索結果コンテナー モジュール) には、ページあたりの品目数プロパティを設定できる作成コントロールがあります。 このプロパティはモジュールの Retail API データ アクションに、Top(N) パラメーターとして渡されます。
モジュールにTop(N) パラメーターを設定しない場合、データ アクションは、サイト ビルダー > [Web サイト] > サイト設定 > 拡張機能 > 一般で定義された既定のページ サイズのアプリ設定に操作を戻します。 その設定も構成されていない場合、フォールバックは、Retail API によって設定された既定値になります。
ほとんどのページ設定された Retail API では、Top(N) パラメーターの既定値は 1000 であり、多くの Web シナリオでパフォーマンス上の問題を引き起こす可能性があります。 したがって、ベスト プラクティスとしてサイトのパフォーマンス要件およびユーザー エクスペリエンス要件に対して既定のページ サイズ設定が適切に構成されていることを確認する必要があります。
次の図は、Commerce サイト ビルダーの既定のページ サイズ設定を示しています。
次の図は、データ アクション (Retail API の Top(N) ページ パラメーター) の例を示しています。
