Is Sending Messages Through WebSockets Slow on Chrome?

Is Sending Messages Through WebSockets Slow on Chrome?It wasn’t long ago that I ran into a strange issue with Chrome. My Jasmine tests were failing because the timeout on the asynchronous actions was too short for Chrome, even though they worked perfectly fine for Firefox. This led to me writing some tests to see if Chrome’s WebSocket implementation was slow which gave some pretty interesting results. I’ve also heard some interesting results from my readers, so I decided to investigate some more.

The New Issue

This time we’re looking at the time it takes to send and receive messages. I had some people tell me that they were getting slow messaging speeds, so I decided to add another little test into the project that I had already made to test Socket.IO connections. The project is on GitHub if you’d like to run it on your own computers.

Let’s take a look at the code for the test. I probably should have done this in the last post, so that there might actually be something to learn, but oh well.

function runMessageTest() {
	var start, end;
	var socket = io.connect(":8080", {
		'force new connection': true,
		'auto connect': false

	socket.on('connect', function() {
		start = new Date();
		socket.emit('1', 1);

	socket.on('2', function() {
		socket.emit('3', "1");

	socket.on('4', function() {
		socket.emit('5', {one:1});

	socket.on('6', function() {
		socket.emit('7', {one:1, two:'2'});

	socket.on('8', function() {
		end = new Date();

	socket.on('disconnect', function() {
		var time = end - start;
		output.append("Time to finish all messages: "+ time +"ms\n");


It’s really really simple. When we connect, send a message (named with an odd number) to the server with some miscellaneous data. We do the same thing whenever we receive any messages (with even number names) from the server: just send another message back (with odd number). We do this 8 times, and then disconnect. The server is set up exactly the same way. When it receives a message (with odd number), it sends a message back (with even number).

var io = require('').listen(8080);

io.sockets.on('connection', function(socket) {

	socket.on('1', function(){
		socket.emit('2', 1);

	socket.on('3', function(){
		socket.emit('4', '1');

	socket.on('5', function() {
		socket.emit('6', {one:1});

	socket.on('7', function() {
		socket.emit('8', {one:1, two:'2'});

Super simple, right? Well, I ran these tests and I couldn’t find a browser that didn’t get through all of these messages in more than 10ms on average. That seems REALLY fast, and it is, but it’s on a local machine, so it’s not like the messages had far to go.

Anyway, the results seemed pretty conclusive to me: sending messages isn’t hindered in any way. Then again, I only had the connection slowness on a single browser on a single computer, while all the other browsers on all the other computers ran just fine. So there might be someone out there who will run this test and see very different results.

New Test Format and a Side Note on Firebug

Just to let you all know, the tests work a little differently than before. Previously the tests ran automatically and were output in the console, but I’ve changed that for several reasons.

  1. I added another test, so I wanted the user to be able to choose a test and run just the one.
  2. If the console wasn’t open when the test first ran, you might have to refresh after opening the console in order to get the results to show up.
  3. Consoles are slow (especially Firebug). When running the connection test in Firefox with different consoles open, I got these average results for the WebSocket connection speed:
Without Console 15-35ms
With Built-In Console 30-85ms
With Firebug Console 450-800ms

I love Firebug, but this has been bugging (no pun intended) the heck out of me. Firebug’s performance has been horrible in the last several months. I’m glad that (especially in the Nightly Firefox release) the built-in console and web developer tools have gotten so much better recently. This allows me to not need to open up the slow monolith that Firebug has become for most of the quick things that I need to do.

Anyway, due to these reasons, I moved the test output into a textarea and the tests run when you click a button. No big deal, but I thought it was worth mentioning.


It doesn’t seem to me that there are problems with the message sending aspect of WebSockets to me, but there’s no reason to believe that it isn’t causing problems on someone else’s computers, especially considering it only impacted Chrome on one of my computers. Let me know your results in the comments below. Maybe try setting up the server on a separate machine so we can add some lag time in to see if that makes a difference. God Bless and happy coding.

About the Author

Author: Joe Zim

Joe Zim

Joe Zimmerman has been doing web development ever since he found an HTML book on his dad's shelf when he was 12. Since then, JavaScript has grown in popularity and he has become passionate about it. He also loves to teach others though his blog and other popular blogs. When he's not writing code, he's spending time with his wife and children and leading them in God's Word.

  • yuanchuan

    Yeah, the messages through websocket may delayed at some time or another in chrome. I noticed it when i tested for using websocket to communicate between browsers.

    • Joe Zimmerman

      Have you run any real tests on it? Or have you just noticed it while playing SMB?

  • GG405

    I came here because I’ve been running into the same problems. I was testing a bare bones client/server implementation:

    var socket = io.connect(‘http://localhost’);
    var clientTime = (new Date()).getTime();
    socket.emit(‘clientEvent’, {timestamp: clientTime});


    socket.on(‘clientEvent’, function(data) {
    var serverTimestamp = (new Date()).getTime();
    console.log(serverTimestamp – data.timestamp);

    In chrome, this is *always* > 1 second. Running the same client in IE gives me times < 80 ms.

    client and server are on the same box, so timestamps should be ok. also, the delay is noticeable and real. with the client running in chrome, you can count off a second till it logs. add in some express wrapping and the time jumps up to 2-3 secs.

    in ie, hitting refresh logs on the "server side" visibly "instantly".

    happy hunting.

    • Joe Zimmerman

      Are timing it from the start of trying to connect to the server? Or is it just the message sending that is taking so long?

      • GG405

        The code is above. You can see I open socket, THEN take time, then send time to server, who logs time received and time 1 “instruction” before the send.
        Any further info on this from anyone? I have been noticing lately a lot of sync issues using youtube via chrome, also. I’m wondering if google isn’t breaking their browser. Or possibly, collecting stats or something which is slowing everything down. Sadly, no native websocket support in IE9, and I’ve switched from node back-end to C#, so native websocket was working well for me.

        • Joe Zimmerman

          I’m not sure if I would be able to find out what’s causing these issues. This seems like something we should bring up to Google.

  • Jitka Hübnerová

    From my measurements websockets are nicely responsive with large amount of small messages (opposite to HTTP).

    When I try to send a burst of large messages from one connection, my websocket app will very soon get into long delay issues in comparison to XHR. There is also difference if I send such burst from Chrome or from Firefox, but principally it is slower. I know that messages don’t go fragmented thru the wire so this can’t be the issue.

    Now I am asking why – it is because websocket server is missing some better threading model? Or it is simply fact for websocket protocol with burst of large messages?

    I am planning to do some test on sending on large messages from multiple connections now… But if you have some tip on why burst of large messages from one connection thru the websocket can be slower than the same thru XHR tell me :)

  • ketting00

    Seem pretty flaw to me. No data typed, no amount of byte length of message. But this really give me an idea to launch my own test.