構築しているアプリケーションに追加のデータをロードするためのアプローチを決定するのに少し苦労しています。このアプリは、1つのページが多くのフラグメントで構成されているCMSです。一部は再利用可能で、その他は排他的です。
排他的フラグメントの例は、description / authorメタタグである可能性がありますが、再利用可能なフラグメントは、リンクのリストである可能性があります。
私の現在のアプローチは、ページの大部分を構成する重要なデータ（本文のコンテンツ、タイトル、スラッグ、日付（公開/有効期限/変更）など）をロードすることです。その部分が読み込まれ、UIの準備ができたら、2つの追加のデータセットを読み込みます。メタタグのコレクション。フラグメントのコレクション。
私の会議は次のとおりです。1。スケーラビリティ2.速度3.保守性
私のアプローチは健全ですか、それとも別のアプローチを検討する必要がありますか？
上記の遅延読み込みにAJAXを使用していることを前提としています。
あなたのアプローチは健全ですか？あなたの質問に対する答えは、ページ全体（フラグメントを含む）の読み込み速度によって異なります。あなたのテクニックは、ページが読み込まれているという認識を作成したいときに使用されます。これにより、ユーザーは心理的に待つ気がしなくなります。
この手法は、ページ全体をロードするには長すぎると見なされる場合に使用されます。「ロードするには長すぎる」という対策は主観的なものなので、例として8秒を考えてみましょう。ページ全体の読み込みに8秒かかり、本体などの一部のページの読み込みに3秒かかる場合は、心理的に8秒待つ気にならないように、最初にそれらの部分を読み込むのが賢明です。
あなたの3つの基準について：
スケーラビリティ：遅延読み込みを使用すると、サーバーに戻るhttp呼び出しの数が増えるため、サーバーへの呼び出しの総数と、同時接続の数を占める可能性の観点から、追加の負荷が発生します。そのため、遅延読み込みはサーバーに追加のオーバーヘッドをもたらします。ただし、展開環境が適切にクラスター化されていれば、大きな問題は発生しません。
スピード：これは私が前に言ったことに戻ります。ページ全体の読み込みが非常に速い場合、サーバーに対して追加のHTTP呼び出しを行うため、フラグメントの遅延読み込みを実行すると、実際には（合計秒数で）速度が低下する可能性があります。この場合、ユーザーの認識も支援していません。ただし、ページ全体を読み込む速度が長い場合は、速度の読み込みの合計時間が長くても、ユーザーの速度の認識が向上するため、この手法は理にかなっています。
保守性：優れた実装では、いくつかの単純なコードでページ全体をロードするか、フラグメントでロードするかを選択できます。これは、保守可能で柔軟なコードを作成したことを意味します。