Why we won't test on IE8 any more (unless you ask us to)

Written by: Dan Goodwin On: 16 Apr 2015 In: Design, Development, Workflow

fffunction stopped testing sites we’re designing and building by default (there’s an explanation for the the meaning of default shortly) on IE8 a few months ago. I was asked to write a blog post to explain why. I’ve finally managed to find some time to write the post.

It’s a classic tradeoff between number of users and time/cost of developing, testing, and bug fixing for an outdated platform. We’re always keeping an eye on stats from StatCounter and when IE8 stats dropped below 5% we had a bit of an internal debate and made the decision to stop.

The default graph on StatCounter isn’t really the best one to look at, mainly because it lumps all the versions of IE in together. If you look at this one what you’re seeing is:

  • Desktop browsers
  • All Chrome and Firefox versions 5+ combined
  • From January 2014 until April 2015 (the latest stats available at the time of writing this post)

So you can see that today IE8 sits at 3.22% and is on a clear gentle downward trend except for a spike in December 2014. That spike remains pretty much unexplained as you can see from a note on StatCounter (rollover the little triangle on the spike for IE8) and this analysis from Sitepoint’s Browser Trends Report for February 2015. So we’ll put that spike aside and assume that IE8 is on a steady downward trend.

OK, we’re not naive and we understand that 3.22% of a really really really big number is still a really big number (or maybe even a really really big number). StatCounter’s FAQ states that their worldwide sample size in June 2013 is 17.5 billion page views. In that FAQ answer, they break mobile devices out so it’s hard to work out if that 17.5 billion is desktop only or includes mobile. And those sample size figures are from 2013 which isn’t where we’re taking our graphs from. So I’ve made some questionable assumptions and drawn some questionable inferences from these statistics. But either way, if we take 3.22% of 17.5 billion we still get 0.5635 billion page views. Which is still quite a lot of views for sure (it’s 563,500,000 for the record). But then again, it’s still also only 3.22%.

So then we’re left to speculate as to who these IE8 users will be and whether we’re concerned about them. Anecdotally we gather that many IE8 users were or are stuck in locked down corporate or public sector environments where they have no choice but to use the incumbent browser. But then hopefully Microsoft having shut down updates to Windows XP (in April 2014, a year ago) will have forced many such organizations to move off Windows XP and IE8 to something newer. But it’s difficult to find any credible evidence or research which backs any of this speculation up (if you know of any, please do let us know).

Then we might also start talking about global regional variation, developing countries who are still using Windows XP and hence IE8 or other lower versions of IE. And we could start discussing whether users in those regions are relevant to our clients. And again much of that discussion would be based on speculation or anecdotal evidence.

I find it difficult to square having such discussions with a fundamental desire to build a web which is all-inclusive and progressive. Shouldn’t users be able to access the sites we build on any browser on any device? And we ‘cut the mustard’ and enhance the experience for the newer, better browsers. Yes and our position on the progressive nature of sites we build hasn’t changed. This means we’ll continue to serve up a fixed width version of a default site build to IE9 and below which should allow content to be accessed on those browsers.

But we won’t specifically test our sites on IE8 or below and we won’t specifically fix issues with those browsers (because we won’t be able to spot them). If a client wants specific support for IE8, we’ll negotiate additional costs for the testing and development required. And if we’re alerted to issues with IE8 by clients or visitors to their sites we can look at fixing those on a cost basis.

We’ll use the time we save to spend more time designing and building functional, beautiful things which meet the needs of our client’s users. It’s what we do best and if you want us to do that for you, we’d love to chat to you about it.