Is there much overhead with sending a large quanity of messages versus large messages with WebSockets?

Question

I know with HTML and sending data it is encouraged to send a lot of data infrequently because of the overhead associated with headers, content, tags, expiration dates, cookies, etc. For a better user experience and less lag, better to send large messages infrequently than small updates frequently.

However, is this the case with WebSockets? On my webpage right now I send a lot of pixel data very frequently so the clients don't experience much choppiness. However, would it be better if I sent updates less often?

I guess what my question boils down to is: "With WebSockets, is it still more efficient to send large messages infrequently than frequent small messages?" I think I heard the technology got rid of most of the overhead associated with sending and receiving messages as it maintains a constant connection and is full duplex, etc.

Thanks for reading.

Edit: help a computer

Answer 1

The main point I'd like to make is that chatty vs chunky interfaces are not restricted to a technology stack (WebSockets, HTTP, UDP, other network related protocols). They all share the same properties and the effects of many requests vs larger requests will have to be weighed in a similar (if not identical) manner. Here is a great article for more reading on the subject.

The last thing to note is that the nature of your application also will impact your decision the most. A real-time stock trading system will be much more chatty than a simple user input form.

EDIT

Here is a similar question related to WebSocket performance : HTTP vs Websockets with respect to overhead

Answer 2

The overhead of sending a WebSocket (client to server) message of size <=125 octets payload is 6 octets. With up to 64k payload it'll be 8 octets, and above 14 octets.

Since WebSocket is a TCP based protocol, due to the streaming / dynamic window size adjustments, sending many small messages fast will batch up into larged sized TCP segments and IP packets sent anyway. On the wire, it'll be similar to sending large WS messages more slowly.

Of course this will only apply when sending is done asynchronously, that is without waiting for a response for a sent message before sending another message.