Thankfully, the footprint of Internet Explorer 6 is declining at a steady rate but until it reaches less than say 15% of a general audience we’re going to have to put up with it. The best we can do to speed its decline is provide some subtle hints about upgrade paths to its user-base.

To do our part, we thought illustrating practical example of problems caused by IE and the flow-on effects of those problems.

Recently, we completed an overhaul of EuroCheapo’s homepage,  implementing a snazzy and lighter new layout. We think it’s great, especially as we are able to find budget accommodation for our next European jaunt using CheapoSearch. Our development methods involve test-as-you-code processes in Firefox 3 followed up by Internet Explorer 7 testing as the go-live date draws nearer. It’s a method that works quite well as we can be pretty sure that layouts, even complex ones, are going to work just as well in Safari 3, Chrome, Konquerer and Opera 9 as they do in Firefox.

During the IE testing phase of this project I booted up our trusty-but-rusty XP box containing a pristine copy of Internet Explorer 6 and went to work trying to smooth out the expected rough edges. One of the most perplexing of these was that where Firefox flew through the dynamic CheapoSearch box we’d added to the homepage, IE became bogged down just loading the calendar widgets and the background images in.

Checking our access logs, stepping through the Javascript and a few googles later confirmed that Internet Explorer was refusing to cache any images associated with the dynamic parts of the CheapoSearch box, even though our caching rules were being respected by every other browser. Laughably, every time a form was switched in and out of view the access logs would fill with requests to the various images that had popped into view.
From an IE6 user perspective, the site was taking up to 25 seconds to completely load the page and make the page elements interactive (IE7 was not much better) along with a 2-3 second wait for dynamic elements to become visible.

While there is a technical solution, which we’ll cover, the process of implementing it couldn’t but make me wonder about the side effects of IE6 usage on its users and systems it connects to:

• our web servers have to fulfill a large amount of unneeded requests that would use memory best allocated elsewhere on the system (not good)
• a site visitor using IE6 who can’t or won’t upgrade may lay the blame at the feet of the site – “it’s sooo slow, I’m not coming back here again”, resulting in a loss of traffic and revenue for the site owner (not to mention the kudos). How do we get across that it’s the browser’s fault, not ours? (even worse)
• site owners have to wear the extra (and sometimes unforseen) costs of supporting and testing against older versions of IE (not good either) and
• it puts serious obstacles in the way of being able to develop and present information in new and interesting ways (probably the worst of the lot)

Will IE6 ever fully go away? Developers dream of IE6 extinction – it will happen – but until then the costs associated with testing and hacking around its various idiosyncrasies will still be a burden, time and dollars wise, for developers and site owners.

Back to the technical solution for this … what forces IE to cache those images ?.

Footnote: Internet Explorer 7 isn’t much better in that it displays this behaviour as well. What’s the best solution IE browser users can implement? Easy: use another browser.