Browser speed wars, it’s not all about rendering

After reading a quick performance guide to the various new browser engines it struck me that it has missed another aspect, that I just happen to have been experimenting with…that of caching. A current customer I’m working with has some issues with poor performing and unreliable download speeds. With this in mind I’ve examined how three of the common browsers deal with caching, after all if you can cache a resource then the download speed becomes far less important. Using IIS6 I created a simple HTML page with containing a page of text, a single jpg and a link to a stylesheet. The page expiration is set to a year in the future and with the Etags both on and off. The results were a little surprising;

Internet Explorer (6,7,8) is determined not to be caught out by changes on the server. First off I do a hard refresh and what the network traffic. Every resource is returned to the browser "as new" from GETs with lots of "200 ok" responses from the server. With every subsequent refresh IE asks the server if the resource has changed, resulting in a "304 not modified". So IE creates a server roundtrip which is small, however, is it necessary? I’ve specifically provided a expiration date so why is it ignoring me? Interestingly if you shut the server down, IE will ask for the server and then realise it’s not there and just server up the cached version. So what happens if I change any of the resources? Well since IE asks the server each time, IE reflects the changes immediately. This is good news if you change your "static" content but not great for my customer!

Firefox (3) provides a very nice compromise. As with IE the hard refresh returns all the resources. The next two requests seems to see Firefox continue to behave like IE with it asking for changes. However, after the 2nd refresh FF seems to accept that the resources are not changing and stops making server roundtrips until the item hits the expiry date. To be absolutley accurate, FF did seems to occasionally check for changes but very, very infrequently. If the server drops FF continues to server up the resource from the cache. This is good news for my customer since the server roundtrips are almost cut to zero.

Safari (3.1.1.) works pretty much like IE, with the exception of when the server is down no page is rendered…boo.

To give you some idea of the difference in speeds because of this caching/non-caching behaviour I ran my tests against the BBC’s main news page, The total time to return all the resources for a hard refresh for IE and FF was ~3.5s consisting of some 87 requests. The next two refreshes remained at 87 requests but were mainly the "has it changed" request resulting in better performance ~2.5s. However, the next refresh saw FF shine. IE remained at 87 requests and ~2.5s whereas FF, relying on its cache, only made 17 requests taking a mere 700ms. Ok ok so this doesn’t take into account the rendering speed, but rendering speed does not improve your download speeds, caching can fake that improvement. So at the moment I have FF ahead of IE. I’ve yet to test Opera and I have to say that Safari does render very quickly but sort out your caching Web Kit!

NB. If this is very important to your business please run the tests yourself, I found the following to be useful tools; FireBug’s net performance tab; Fiddler2 and WireShark.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s