(Unity 5.1 からは UNET の使用を推奨しています。下記の情報は旧ネットワークシステムのものです。)
ゲームの他の部分と比較するとネットワーク通信は遅いため、最小に抑えることが重要です。このため、データ交換を行っている量や発生の頻度を考慮することがとても重要です。
使用されるネットワーク帯域幅は Unreliable （非信頼）か Reliable Delta Compression （信頼差分圧縮）、どちらのモードを使用してデータの同期を行っているかに大きく依存します。（モードは Network View コンポーネントからセットします）
Unreliable （非信頼）モードでは、同期されるオブジェクトの全体がネットワーク更新ループのすべての反復ごとに送信されます。この更新頻度は Network.sendRate の値により決定され、デフォルトでは 1 秒ごとに 15 更新にセットされてます。Unreliable モードは頻繁な更新を保証する一方でパケットの逸失や遅延は単に無視されます。頻繁に更新が行われ、更新を逃しても影響する時間的長さが短いオブジェクトにとっては最適の同期方法です。しかし更新ごとに発生するデータ量は頭に入れておく必要があります。例えば Transform の同期は 9 つの浮動小数点データ（ 3 つの Vector3 に各々 3 つの浮動小数点）を伴い、更新ごとに 36 バイトを意味します。もしサーバーが 8 クライアントで実行していてデフォルトの更新頻度を使用している場合 4,320KBytes/s （ 8 × 36 × 15 ）あるいは 34.6Kbit/s を受信し、30.2KBytes/s （ 8 × 7 × 36 × 15 ）あるいは 242Kbits/s を送信します。帯域幅の消費量を大きく減らすために更新頻度を下げることはできますが、アクションが素早いゲームにおいて 15 というデフォルト値は大体適切なものです。
Reliable Delta Compressed モードでデータは信頼性をもって正しい順番で受信されることが保証されてます。もしパケットを逸失した場合再送信され、順番が正しくない場合、すべてのパケットが一連のパケットがすべて到着するまでバッファリングされます。これにより送信されたデータが正しく受信されることを保証するものの、この待機および再送信が帯域幅を消費しがちです。しかしデータは差分圧縮され、前回の状態と現在の状態の差分のみが送信されます。もし状態がまったく同一である場合何も送信されません。差分圧縮はどのプロパティーがどれだけ変化するかに依存します。
すべてのクライアントで実際に同じでない状態を同じである かのように ゲーム設計を工夫する余地があります。具体例としてはアニメーションを動機する例です。もしアニメーションコンポーネントが Network View により発見されると、プロパティーは正確に同期され、すべてのクライアントでフレームが同期するようになります。これが望ましいケースもありますが、通常はキャラクターが歩いたり、走ったり、ジャンプしていたり、のどれかで十分です。アニメーションの同期を削るするためにはどのアニメーションシーケンスを再生するか integer の値を送信して指定するのみです。これによりアニメーション全体を送信するよりネットワーク帯域幅が節約できます。
通常、ゲームをすべてのクライアントで完全に同期することは不要で、たとえば、プレイヤーがゲーム世界の別エリアに一時的にいて互いに遭遇することのないケースがあったとします。この場合帯域幅だけでなくサーバーの負荷を削減するには、遭遇することができるクライアントのみ同期します。このコンセプトは Relevant Sets （関連セット）と呼ばれます（すなわち、特定のクライアントのある特定の時間で、ゲーム全体のうち実際に関連するサブセットが一部ある状態）。クライアント同期を Relevant Set にもとづいて同期させることは RPC によって、同期の更新対象をより強力にコントロールしたうえで、ハンドリングすることができます。
レベルをロードするときは、通常各クライアントが使用する帯域幅を気にする必要があることは稀で、すべてのクライアントがプレイするレベルを初期化できるまで単に待たせればよいです。レベルローディングはかなり大きなデータアイテムの送信を伴うことがあります（画像や音声データなど）。