RFC 2616 and Web Performance

RFC 2616 is the specification to the HTTP 1.1 protocol. It defines in some part how web browsers connect with web servers. The purpose of the document is much larger - it defines the communication protocol as a whole - meaning that anything talking HTTP 1.1 should follow the protocol exactly if it wants to follow a set of expected behaviors.

I was reading through this mainly because I'm a nerd and I do these kinds of things as a distraction from my normal work behavior, but also in small part because web site performance is something that I take very seriously. In order for a small webmaster to compete with all the giant corporations out there, he has to squeeze the most out of what he can afford. I have a friend who's Mitsubishi Eclipse could hold it's own against my Porsche 993 (which I no longer own). He didn't spend nearly as much money, but the time and care that he put into the car made a huge difference. That's the way small webmasters should look at web site performance - you don't need $20K servers to deal with 100K visitors / day - you just need to pay attention to the little things - and often you can see large performance boosts for very little cost and effort.

But anyhow, back to RFC 2616. Section 8.1.4 is a little bit enlightening, and it points out a great way to improve web site performance, and your own experience while browsing sites on the web.

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

The emphasis in the above quote is not my own, it is straight out of the RFC. Basically, this means that there is no hard and fast rule, but if you are doing anything major, you really do need to follow the guideline. Now let's see here... what would be something major that followed RFC 2616... maybe Internet Explorer, Safari, and Firefox?

Sure enough, IE and Firefox limit their concurrent http 1.1 connections to any given server. This means that out of the box (which is how MOST people use Firefox and IE), end users will limit themselves to downloading at most 2 objects from your server - it starts out with your HTML page, and from there, any files referenced in your HEAD (CSS or Javascript). After that, it's anybody's guess - images, xml, BODY referenced Javascript or CSS, etc.

Server side, you can alleviate this congestion by maintaining separate host names for some of your static content. If you are serving up javascript and CSS from one host, images from another, and html content from yet another, you open yourself up to 6 concurrent connections per client, thereby increasing the potential load time of your web pages by a factor of 300%. More intelligent design based on content size and potential for usage would increase the actual experience closer to the potential.

Think of it like a queue. There are two lines available. If the request sitting at the front of either line takes longer than a second or two, then all requests behind them in the queue will have to wait. If one of those requests is a 500K file, you've effectively cut off the pipeline by 50% until that file is completely downloaded.

You can fix this "problem" client side by changing configuration options in IE or in Firefox (safari I don't know much about). Either browser can easily be configured to a higher limit of concurrent http requests. For firefox, simply go into about:config and enable network.http.pipelining and change the network.http.pipelining.maxrequests value to your desired number. More about Firefox pipelining here. In IE, of course, you have to edit the registry. The specifics are outlined in this knowledge base entry. I'd rather not repeat it here for fear of getting it wrong with a typo.