SPDY on the Client Side

‹prev | My Chain | next›

Tonight, I am going to play around in the client under SPDY. A recent question on the spdy-dev mailing list asked how to detect SPDY on the client-side. The answer was window.chrome.loadTimes().wasFetchedViaSpdy

Indeed, that seems to work. I load the sample SPDY server in node-spdy, to find:



I root about the various other objects in an attempt to find traces of SPDY in the client, but without much luck. The remainder of the loadTimes() object:

window.chrome.loadTimes()
Object =>
{
commitLoadTime: 1308016338.425257,
finishDocumentLoadTime: 1308016338.52675,
finishLoadTime: 1308016338.559778,
firstPaintAfterLoadTime: 1308016338.560204,
firstPaintTime: 1308016338.560204,
navigationType: "BackForward",
requestTime: 1308016338.297097,
startLoadTime: 1308016338.393768,
wasAlternateProtocolAvailable: false,
wasFetchedViaSpdy: true,
wasNpnNegotiated: true,
__proto__: Object
}

The wasFetchedViaSpdy and wasNpnNegotiated values seem fairly self-explanatory. I would guess that wasAlternateProtocolAvailable value would be true if the node-spdy server offered more than just SPDY. So I update the test server to return HTTP/1.1 as well:

var options = {
  //...
  NPNProtocols: ['spdy/2', 'http/1.1']
};

var server = spdy.createServer(options, function(req, res) {
  // ...
});

But when I reload the test page, I find that window.chrome.loadTimes().wasAlternateProtocolAvailable is still false. Just to make sure I am not doing something silly, I check the SSL negotiation in Wireshark. I find that yes, there are two protocols offered:



Hrm... I am unsure about that. I will follow up on the spdy-dev mailing list to see if my expectation is in error.

I am hard pressed to worry too much about this. Aside from reporting, I cannot think of many use cases for the client knowing that the page was served via SPDY. As far as the page is concerned, any secondary interactions would be the same over HTTP as over SPDY. Be it server-sent events, web sockets, or plain-old AJAX, as far as the client is concerned, it is all going over HTTP.

If a use-case does arise, the SPDY / NPN information will likely need to be stored elsewhere besides window.chrome.loadTimes()—especially if SPDY is adopted by browsers other than Chrome. For now, that will complete my exploration of SPDY inside the client. I will switch back to the server side tomorrow.


Day #50