Question

In the web world a web browser makes a new request for every static file it has to retrieve, so; a stylesheet, javascript file, inline image – all initiate a new server request. Whilst my knowledge of the web is pretty good, the underlying technologies like websockets are somewhat new to me in how they work and what they are capable of.

My question is rather theoretical, but I am wondering if it’s possible now or would ever be possible to serve static files via a websocket? Considering websockets are a persistent connection from the client (web browser) to the server, it makes sense that websockets could be used for serving some if not all static content as it would just be one connection as opposed to many.

To clarify a little bit.

I realise my wording about connections was incorrect as pointed out by Greg below. But from what I understand the reason CDN’s were created and are still used today is to address the issue with browsers and or servers having a hard limit on the number of concurrent downloads, once you hit that limit your requests are then queued thus adding to the page load time. I am aware they were also created to provide cookie-less requests as well. So really my question should be: “Can websockets be used in place of a CDN?”

BrowserScope has some useful metrics, it appears as though the request limit is about 6 per hostname for most modern browsers and even IE8. But as I said sometimes people have more than 6 resources, does this mean they’re being queued and slowing the page load time where websockets could potentially reduce this to one?

Answer 1

It’s definitely possible but there are a few reasons why you probably don’t want to use this for static resources:

• You need at least one resource that is statically delivered over the standard HTTP mechanism which means you need something capable of serving static resources anyways. Generally you want to keep Javascript separate from your HTML which would mean another static load. Or you can be messy and put the WebSocket code embedded on the main page, but you still are really any better off yet.
• You can’t open WebSocket connections until a script on the page starts running. Establishing the WebSocket connection adds some initial latency.
• Most browsers will load non-conflicting static resources in parallel (some older browsers have a severe limit on the number of parallel connections, but they still have some parallelization). You could open multiple WebSocket connections for different static resources, but doing this reliably and efficiently is going to take a lot of effort. Browsers have already solved most of these issues for static resources.
• Each WebSocket connection is a guaranteed order message based transport. Combined with the serialized nature of Javascript execution this effectively means you get to process one WebSocket message at a time. You could use Web Workers to be able to process more than one WebSocket connection in parallel, but the main render script will still be serialized across those connections. You could certainly make this efficient, but once again, this isn’t a trivial problem and browsers have already solved a lot of these static resource loading problems.
• Many web servers support gziping resources before delivering them. WebSocket does not yet have compression support (it’s being discussed as an extension in the working group). This means if you want to compress your resources over WebSocket you will have to do this in Javascript which will add more latency.

If you have parts of your page that are dynamically updated using static resources (e.g. loading in new images into a HTML5 canvas game), then WebSockets may be your best option because an already established WebSocket connection will have low latency and overhead for getting pushed updates from the server then getting these delivered over HTTP. But I wouldn’t recommend using WebSockets for the initial static resources when you page first loads.