Luke Amery10 April 2008, 12:00 AM
A Tag Short | We have a dilemma - we want our home page to have lots of compelling rich content like embedded video and flash. And we want it before Christmas.
How do we balance these two goals? I think we can achieve both by “faking performance”; after all perceived performance is all that counts. Perceived performance is about making sure that the most appropriate elements of a web page are available as soon as possible in the rendering process.
So the question becomes how do we control that? This requires a quick explanation of http (the protocol the web browser and web server speak to each other). One of the largest costs in a web browser to web server “chat” is connection establishment. This is because of the round trips required in the communication channel to establish a connection (and as we know the up channel on the average consumer connection is still pretty average). This doesn’t make sense to a lot of people because “page weight” has been the hot topic for so long. Now, the real killer is latency; there is a saying in network circles that goes: “Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed - you can't bribe God.”
In the original http spec (version 1.0) each request for a separate object from the server required a new connection to be established the request made, the content returned and the connection torn down. There had to be a better way, so http 1.1 was created amongst other reasons to address this short coming. Various features and transfer encodings were added to the protocol to allow the client and the server to understand the beginning and ending of requests and responses. This allowed a new feature called persistent connections to emerge. Persistent connections allow several requests and responses to be sent over a single connection – we skip the connection establishment overhead altogether when this aspect of the protocol is in play.
Persistent http connections presented some danger to web servers, notably connection overload. If web browsers were going to open and keep open numerous connections poor web servers were going to struggle to keep things under control. So the Http 1.1 spec decreed that a “user agent” would not create more than two simultaneous connections to a given server.
Back to perceived performance, how can we use this knowledge to make our home page perform well? If our home page consists of the html content itself, a cascading style sheet document, a dozen images and a nice flash object then we can start assessing how our two http connections are going to be utilised. Obviously, the first connection is going to be consumed initially by getting the html content.
As the html comes streaming down the first thing it stumbles across is the css reference – our second connection is now in play. Depending on the relative time frames of retrieving the rest of the html content and the css document, the next set of content will be downloaded round robin as each connection completes the previously referenced object. If the flash object is near the top of the page before many of the images then we have a chance that the content will download in the order: html content, css, flash object, other supporting imagery. This would be perfect. The page would gain the necessary style and structure from the referenced css first up. Next the main visually compelling object, the flash object would be available shortly after.
Life (and web development) is rarely that simple, there are usually a lot more referenced objects and determining ordering can be a challenge. I use wireshark which is a very powerful network analysis tool. I make use of a very small fraction of its power by capturing http traffic and then exporting an http object list. This shows the objects in request order, which really helps with the effort mentioned.
The quickest way to get improvements is to merge all our css and javascript into single monolithic files. This will reduce the overall request count to get the page rendering.
In more extreme cases if we find ourselves in a less than perfect scenario how can we improve? The two http connection limit is actually limited to domain names. Web browsers enforce this limit on domain names not ip addresses. If we serve css and script and flash objects off different sub-domains from our main domain we multiply the number of available concurrent connections! Even the simple example above gets better, the flash object can be downloaded at the same time the remaining html content and css content is coming down.
For those developers out there building the latest greatest AJAX enabled thing since sliced bread, this tip could be a saviour as AJAX requests are subject to the same two connection limit.
Lastly, to conserve those precious http connections avoid server technologies that don’t support persistent http connections. Adobe’s Cold Fusion comes to mind, correct me if I am wrong, but I can’t seem to find a way to get Cold Fusion to support persistent connections at all!
Other techniques to boost performance include http compression and caching, but one tip at a time. This page does a good job of explaining utilisation of http connections. If wireshark is too complex and your website is hosted publically this service does a good job of analysing what gets loaded in what order.
All "A Tag Short of Compliance" Blogs
In his real job, Luke Amery works on shopping cart software. He is the technical director of On Technology, Australia's leading e-commerce development company.