Thanks for the detailed report.

This looks very similar to issue 441885, but I will keep them separate for now.

I tried the attached server. It works very well. On my workstation, Firefox is 3 times faster than Chrome.

Generally we've considered localhost performance for WebSockets unimportant. In real use cases we expect the network to be the bottleneck.

Do you have a use case where localhost performance is important?

We develop a medical imaging application, consisting of a database server (storing images), application server (which caches & renders images) and a web client. 

In most cases, the database and app server are connected via a fast connection (e.g 10Gbit) and the app server-web client connection is indeed one of the main bottlenecks. We deal with this bottleneck by reading ahead images and caching a small portion of them in the web client. This works well with medium to high bandwidth networks (e.g around 50Mbit - 1000Mbit).

However, when the network connection is very poor, this architecture becomes problematic, and we are unable to provide adequate interactivity when scrolling through the images. We are limited in the amount of compression that can be applied to the images, as most clinician's require lossless compression. We are also limited in the amount of data that can be cached in the browser, especially in Chrome where it's impossible to guess how much memory is available. 

A solution to this scenario would be to move the app server to the desktop and bundle it with the web client. The user will then need to wait until all images are cached in the desktop app server, and from then on, will have good performance as server-client communication runs internally on their.

This is where localhost performance becomes important. Our assumption was that websockets will run almost as fast as the native TCP loopback, so we planned to send decompressed images from the app server to the client, by this eliminating also the compression/decompression bottleneck. 

With other browsers it seems possible, but not with Chrome.  
Do see think this issue will be resolved in the near future?

We have an enterprise system that we ported from native to web (using google angular). our system is using network intensively and we have very demanding customers when it coms to response time. one of the things we suggested the customers is to upgrade the network lines from 1GB connection to 10GB connection. We tried it in the labs to make sure that the customers are not wasting their money and found that at 10GB the websocket is becoming the bottleneck. We tested all the other browsers to make sure it's not a problem with our network and found that IE and firefox are MUCH better than chrome, firefox being the leader with x2 bandwidth.
From our perspective, although not very popular but 10GB is becoming more and more available inside enterprises, and not just in the backend.

 Issue 870965  has been merged into this issue.

#30 - where does localhost come into play in your case?

Just wanted to make things clearer - this is not just on localhost! it is a bottleneck in the implementation of websockets. the reason it is more visible on localhost is because the network is not a bottleneck by itself, and so is the case when you use 10GB network instead of 1GB network. so we don't need it for the localhost, but rather just for fast networks!