Browser Support: The Two Metrics That Count

Published on January 27, 2009 (↻ February 5, 2024), filed under (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

There are only two things that matter to determine what user agents—or browsers, simple language—to support on any given site: First, how popular is the user agent in question? Second, what’s the “support threshold,” the distribution percentage that makes a user agent mandatory to support?

This might sound completely obvious but it still requires a meiertesque post, as some companies and individuals throw in other variables to the decision what browsers to support. For example, some consider practically unimportant browser Beta versions or rarely relevant operating systems, use unmanageable “grades” or “tiers,” or blindly refer to general concepts like Graceful Degradation and Progressive Enhancement.

Still, the only thing that matters is the browser’s popularity (in your market segment, if you like at least one level of complexity), and your own choice of what percentage makes a browser worth testing for. Supporting browsers is as simple as that; in a corporate environment, a list of browsers to be supported that gets updated each quarter is usually enough.

Since meiertesque posts are not always a 100% clear, here’s what I do every now and then: For an existing site, I’d have a look at its UA stats and compare them with competitors as well as my own heuristics. If the site is new I’d verify my heuristics and assumptions by checking public metrics. Then I’d set a support threshold of about 1% and would make sure that the site works (looks and behaves about the same, that is) in all browsers that are used by at least this 1% of visitors. Graceful Degradation and Progressive Enhancement would be instruments to be used, but they aren’t per se important to decide what browsers to support.

Was this useful or interesting? Share (toot) this post, or maybe treat me to a coffee. Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

Comments (Closed)

  1. On January 27, 2009, 21:43 CET, Dave said:

    I don’t think there’s such a thing as “mandatory to support”. The key measure is the return on investment, which means there’s definitely another factor: resources required to support a user agent. If I can make the site work in Browser A in 10 minutes, but it will take all day to make it work in Browser B…

    If you want to get fancy, you could start talking about the return you get from users of different browsers. If you’re selling something shady and you know you won’t be able to trick 99% of Chrome users into making a purchase, then why bother supporting Chrome?

  2. On January 28, 2009, 14:49 CET, Jabz said:

    Shouldn’t we create websites with people in mind, not browsers?
    I for my part, have decided to throw out all my IE hacks (on all my web sites) this year…forcing people to switch to newer Versions of their Browser-Software. So far it’s working.

    The usage of IE alternatives went up 12%, traffic is steady. đŸ˜Š Like Dave said,..there is no such thing as “mandatory support”!

  3. On January 28, 2009, 21:56 CET, Lauren said:

    I have actually seen quite a few people hit the moto of forcing the switch on users. However, when you are dealing a money site (which you may be) the last thing you want to do is make your users feel forced to do anything. Jens approach is rather safe and even going beyond to support that other bowser is worth it. I would rather take an extra day to bring in more visitors and potential customers. Support as much as needed without trying to decide for them. These are typically the people who are comfortable with the 800×600 resolutions : /

    however I would like to see firefox take over - or something other than IE

  4. On January 29, 2009, 20:28 CET, Jens Oliver Meiert said:

    Dave, ROI should usually correlate quite well with browser market shares, however you bring up a good point that indeed, users of one browser might mean more revenue than those of another.

    Jabz, I like how you point to the human factor to then talk about abandoning support for IE (6, I suppose?). But that should just illustrate my point—this might make perfect sense if you’ve only got .5% visitors using IE 6 and below. (Yes, I shamelessly added some judgment using what I referred to as the support threshold.)

    Lauren, exactly. Let’s not get all too philosophical here. At the end of the day you just want to make sure that the majority of your visitors are able to interact with what you’ve got to offer.

  5. On February 10, 2009, 12:55 CET, Richard Morton said:

    It is sort of implied in the post but it is worth mentioning that in the case of intranet websites it is often possible to restrict support to the only browser that is authorised for use by the owners of the intranet (possibly more than one version).

  6. On May 19, 2010, 8:29 CEST, Cassey said:

    As explained in the post, it is worth mentioning that in the case of intranet websites it is often likely to restrict support to the only browser that is authorized for use by the owners of the intranet. The other point is if you’re selling something dappled and you very well know you can’t trick 99% of Chrome users to purchase, then why we need to bother about supporting chrome.

  7. On January 25, 2011, 16:55 CET, Mike said:

    I agree, it would depend on the popularity of your visitors browser. Anyways, browsers will update their to adapt new sets of codes.