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