| Query Selector perf test - https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Compare the results of that in Firefox versus Chrome as the results are interesting. As for HTTP the issue is two-fold. The first thing is that HTTP imposes a round trip: request and response. That means the connection traffic starts with a request, waits for the application at the remote end to do what it needs, the application at the remote end sends a response whether you want it or not. Secondly, in the case with keep alive all requests on that socket must wait for the prior round trip to fulfill before sending the next request. The primary advantage of HTTP 2 over HTTP 1 is more massively parallel requests, which greatly flatten the waterfall chart of asset requests and thus speeds page load time. In HTTP 1.1 there is typically a maximum of 8 parallel requests. The advantage of Web Sockets is two fold. First, there is no round trip. Each message is fire and forget. This allows messages to be sent more rapidly without waiting (with a caveat). Secondly, Web Sockets is completely bidirectional. The local end and distant end can send messages independently of each other or other timing. The big limitation of Web Sockets is message processing speed. In the Web Socket library I wrote for Node.js performance is memory bound and I can send messages as fast as 470,000 per second on my laptop with DDR4 memory per socket. The problem is not sending, but receiving. Firefox tends to separate frame headers from frame body so you have to account for that. If messages come in too rapidly Node.js will concatenate multiple messages together, so you have to account for that. In TLS the maximum message frame size is 16384 bytes irrespective of the actual message size, so you have to account for that too. There are a few other scenarios to be aware. This processing takes time to parse the binary frame headers and examine the message body length. Even still I can process up to 9000 messages per second on the same machine. The greatest limitation with web sockets though is message queuing. I solved for this on the Node side because there is an event, the drain event, to account for a message leaving the buffer associated with the socket on the local end. As a result I know when to send a message immediately or queue for sending after the current messages completely leave the buffer. Without a queue any message that comes into a socket before a prior message drains from the buffer will overwrite the prior. On the browser side there is no queue and no event to indicate when to send from a queue, so you just have to manually slow things down with a timer. |