HTML と送信データでは、ヘッダー、コンテンツ、タグ、有効期限、Cookie などに関連するオーバーヘッドのため、大量のデータを頻繁に送信しないことが推奨されます。ユーザー エクスペリエンスを向上させ、ラグを減らすには、大きなメッセージを送信することをお勧めします。頻繁に小さな更新よりもまれに。
しかし、これはWebSocketの場合ですか? 現在、私の Web ページでは、大量のピクセル データを非常に頻繁に送信しているため、クライアントは途切れることがあまりありません。しかし、アップデートを送信する頻度を減らした方がよいでしょうか?
私の質問は、「WebSockets では、小さなメッセージを頻繁に送信するよりも、大きなメッセージを頻繁に送信するよりも効率的ですか?」ということになると思います。このテクノロジーは、常時接続を維持し、全二重であるため、メッセージの送受信に関連するオーバーヘッドのほとんどを取り除いたと聞いたと思います。
読んでくれてありがとう。
編集：コンピューターを助けて
私が言いたい主なポイントは、おしゃべりなインターフェイスと分厚いインターフェイスは、テクノロジー スタック (WebSockets、HTTP、UDP、その他のネットワーク関連のプロトコル) に限定されないということです。それらはすべて同じプロパティを共有し、多くのリクエストとより大きなリクエストの影響は、（同一ではないにしても）同様の方法で比較検討する必要があります。これは、このテーマについてさらに読むための素晴らしい記事です。
最後に注意すべきことは、アプリケーションの性質も決定に最も影響を与えるということです。リアルタイムの株式取引システムは、単純なユーザー入力フォームよりもずっとおしゃべりです。
編集
WebSocket のパフォーマンスに関連する同様の質問を次に示します。オーバーヘッドに関する HTTP と Websockets の比較
サイズが 125 オクテット以下の WebSocket (クライアントからサーバーへ) メッセージの送信のオーバーヘッドは、6 オクテットです。最大 64k のペイロードでは 8 オクテットになり、14 オクテット以上になります。
WebSocket は TCP ベースのプロトコルであるため、ストリーミング/動的ウィンドウ サイズ調整により、多くの小さなメッセージを高速で送信すると、大きなサイズの TCP セグメントと IP パケットが送信されます。ネットワーク上では、大きな WS メッセージをよりゆっくりと送信するのと似ています。
もちろん、これは送信が非同期で行われる場合にのみ適用されます。つまり、別のメッセージを送信する前に、送信されたメッセージの応答を待たずに行われます。