switch_to_blog（）のパフォーマンスに関する考慮事項と代替方法
私は現在マルチサイトネットワークの概念段階にあります。
大まかな考えは次のとおりです。複数のネットワークサイトがあり、すべて独自の投稿を公開しています。ネットワーク管理者は各ブログ間の「コンテンツリンク」を確立することができます。 「コンテンツリンク」とは、管理者がバックエンドのブログ間で投稿の共有を設定できることを意味します。片方（-->）または両方向（<->）。これにより、ブログのリストページに他のブログからの投稿も表示されます。
たとえば、ブログが3つある場合、「コンテンツリンク」は次のように設定できます。
_ a _ <-> _ b _
_ a _ - > _ c _
これは次のようになります。
_ a _ は _ b _ の内容も表示します
_ b _ は _ a _ の内容も表示します
_ c _ は _ a _ および _ b _ からの内容も表示します（祖先関係を通じて _ b _ - > _ a _ - > _ c _ ）
個人的には、WP_Query（）を使い続けたいと思います。私はそれに付随する機能が好きです。
- ページネーションのサポート
- 分類法の問い合わせ
- post_metaクエリ.
しかし、WP_Query（）を使用したいのであれば、switch_to_blog（）を大量に使用することに固執しているようです。システムは約1〜5年間レイアウトする必要があります。それぞれ200の投稿を持つ100のブログ、つまり最悪の場合、switch_to_blog（）を99回呼び出して単一の投稿リスト/カテゴリページを表示する必要があります。
誰もがネットワーク化されたブログ間で大規模なコンテンツ共有をしたことがありますか、またはこのタスクのためにまともなパフォーマンスを達成する方法についてのアイデアを持っていますか？
あなたが最初に読む必要があります（私の強調）：
マルチサイトネットワークのサイトは、WordPress.comの別々のブログのように、別々のです。それらは他の種類のネットワークでは相互接続されていないのようなものです（たとえプラグインがサイト間でさまざまな種類の相互接続を作成できるとしても）。強く相互接続されたサイト、データを共有するサイト、またはユーザーを共有するサイトの作成を計画している場合は、マルチサイトネットワークが最善の解決策ではないかもしれません。
もしあなたがマルチサイトにそれが意図されていないことをやらせることを主張し、その代わりにほとんどの人がそれをしたいと思うようなことをするなら、あなたはやるべき仕事がたくさんあります。あなたはあなたのサイトスイッチを尊重するためにWP_Queryを得ることができるはずです その多数のフィルタを通して 、特に これら 。そして いくつかの関数は独自のクエリを実行します したがって、あなたはそれらを個別に処理しなければならないでしょう。
マルチサイトはこれに近づくための間違った方法であるように思えます。このようなものが必要なときは、カスタム投稿タイプを使用する傾向があります。同じサイトに100個のCPTを作成しようとしたことは一度もないことを認めなければなりませんが、「ブログ」ごとに1つのCPTを作成します。生の投稿合計（20,000）は問題にならないはずです。テンプレートを賢く使用すると、視覚的にほぼ独立したサイトにそれらを「仮想化」できます。
あなたが「ドメインマッピング、別々のユーザーベースと別々の管理領域」を必要としているというあなたの下のあなたのコメントを考えると、私はそれがうまくいくかわからない。おそらくドメインマッピングを機能させることができますが、別々のユーザーベースと管理領域は多くの作業になります。それは私が考えることができる唯一の他の選択肢の一つです。