Deciding the Minimum Browser Versions to be Supported in Mamikos.com

Tri Hargianto
mamitech
Published in
7 min readDec 5, 2022

As a Web Developer, one of the biggest challenges is making our web app compatible and working well for as many browsers as possible. Even though for me it’s impossible. Based on Google Analytics data, at least from May to November 2022, there are 180 types of browsers and 4.865 different versions that have visited our site.

So, we need a clear strategy about how far we should support the variety of browsers and versions.

Problems

Not having a clear strategy and which minimum browser versions to be supported causing some problems as a Web Developer:

1. Not confident to use new web technology features

Until this time, we’re not sure whether it’s safe to use CSS Grid or not, and we never know the answer. It’s just an example, there are tons of new web technology features out there but we don’t have any confidence to use them because we are afraid our website will be broken on some old browsers.

Without any data, we can just assume that our website is working well on users’ browsers.

2. Providing unnecessary Polyfill

Lighthouse tells us that we provide unnecessary Polyfill to modern browsers

We always think that we need to support old browsers by providing tons of Polyfill in our Web app, or always transpile our modern code into ES5.

Before this research is written, how we provide Polyfill is by monitoring errors from our error monitoring platforms such as Sentry. If there are some errors reported related to our modern code, then we’ll provide the Polyfill. Sadly, we’re only able to know once our web apps are released to production 😢.

3. Wasting our time

Forcing our efforts to support legacy browsers without any clear rule or reason can make our development process cumbersome. Let’s say we’re developing a feature and pushing our limit to make sure that our feature is working on Internet Explorer that only has 0.00001% of users. It’ll be a waste of time.

Tools

To be able to make a good decision based on the problems above, there are some tools I’ll be using in this research.

  1. Google Analytics: to know how the users behave.
  2. Browserslist: to see what browsers our potential users use.
  3. Caniuse: to see what technologies different browsers support.

Caniuse’s Global Data

Caniuse has a browser usage database that is used by global users. We can utilize those data to find out how many users are using some types of browsers. To see Caniuse’s data, we need to use another tool, which is Browserslist.

Browserslist has a unique query to get the data. It also has a special keyword called defaults, which is a shortcut for > 0.5%, last 2 versions, Firefox ESR, not dead.

But what it means?

Browserslist defaults query meaning

To try the query, we can visit https://browsersl.ist, or running browserslists command via Terminal

Browsers that have more than 0.5% audience worldwide

Data produced on the Terminal has some unique code names. For example, and_chr is for Android Chrome, and_ff is for Android Firefox, and so on. Click here for the others.

Mamikos.com’s Google Analytics Data

We’ve gathered 6-month data from Google Analytics.

Operating System

As you can see, Mobile web users have more than 85% (iOS + Android). This is really an indicator that we need to prioritize building & test our web app to be mobile-first.

Browser Vendor

Google Analytics tracks more browsers than that, but we just put the browsers that at least have more than 0.1% of users. The excluded browsers are Puffin, YaBrowser, Phoenix Browser, etc.

We also include Internet Explorer in the table to show you that the fact, there are Internet Explorer users who accessed our site, even though only 667 users.

Browser Version

There are too many browser’ versions tracked by Google Analytics and we can’t show all of them here.

Fortunately, those data can be exported into a CSV file. After getting the CSV file, we’re able to convert it into a format that is recognized by Browserslist by using browserslist-ga-export.

Browsers that have more than 0.5% audience in our Google Analytics data

Discussion

We need to combine the data from Google Analytics and global data from Caniuse. Google Analytics can be our source to know users that have visited our site, and global data can be our source to know the global audience that has not visited our site yet.

So, let’s combine them. We just put the minimum version into the table because features that worked on Chrome version 101 surely worked well on Chrome 107.

Deciding minimum percentage query

As I’ve explained above, defaults keyword in Browserslist means it’ll show browsers that have at least more than 0.5% users. In the table above, we can see that most of the users using Chrome below version 101 are less than 0.5%.

But, then a question pops up in my mind. Do we really don’t need to support users that are not included in > 0.5% criteria? To answer, we need to find out how many are them. Google Analytics reports that 0.03% means more than 10K users. That’s quite a lot actually.

So, let’s try to decrease our criteria from > 0.5% become > 0.01%

0.01% criteria

Using > 0.01% query, now we know that Chrome 79 is the oldest browser for Chrome Desktop. But actually, this is quite interesting. I’m not quite sure how many percentages are should we use.

Should we use > 0.01% or > 0.5%? How should we decide it? We always think that the more browsers we support will gain more revenue, right? But again, we need to check the data.

From what we’ve found, these are the data browser versions that did submit bookings from January to November 2022.

The oldest browser version that submit bookings is slightly different from 0.01% criteria. But, we think it’s still acceptable to use the 0.01% criteria with some notes:

  1. We need to manually specify the version for Android Chrome and Android Webview because we think the data is not accurate.
  2. For iOS Safari, the usage for version 604.* is quite high on Google Analytics. But apparently, browserslist-ga-export can’t parse iOS Safari 604.* properly (604.* actually is a WebKit version for iOS Safari 11).

Final Browserslist Query

Now we got the data, let’s compose the Browserslist query.

>= 0.01% in my stats, last 2 version, not dead, ChromeAndroid >= 50, Android >= 60, ios_saf >= 11

How we choose the ChromeAndroid and Android minimum version is by manually reading the Google Analytics report. We choose 50 and 60 because they have more than 10.000 users.

User Coverage

We also can get the total users' coverage by providing --coverage option

User Coverage

We’re able to get 95.49% user coverage by using 0.01% criteria and specifying the minimum version for ChromeAndroid and Android Webview.

How About the Unsupported Browsers?

Based on what we’ve discussed above, there’s one more question left. Let’s say we only support some browsers and the rest are unsupported. How should we handle the unsupported browsers properly?

There are two approaches that we can implement:

  1. First approach: Block the UI, show the unsupported browser message, and make users not able to use the website completely until they update their browsers.
  2. Second approach: Warn the users if there is a possibility some features won’t work properly until they update their browsers. They will be still able to use the site though. We surely know that not all users will update their browsers even though they saw the message. This is far better than not telling them that their browsers are outdated. Also, updating the browser is the users’ responsibility and we can’t force them to do that. Other than that, there is still a possibility that the unsupported browsers will be able to use some features on our website.

Conclusion

Now, we have the data on which browser versions we should prioritize and support. This data unlocks several benefits:

  1. QA Engineers now have a clear direction on which browser version to be supported, so the website has a chance to be more stable on those targeted browsers.
  2. We know which web technologies we can use (and shouldn’t use). Improving the development process confidence.
  3. Reducing development time and effort to support unnecessary browser versions.
  4. We also can tell the users if their browser is outdated so they have a reason if our website is broken on their end.
  5. Many more… 😁

There are a lot of benefits in deciding the minimum browser versions for our site rather than not, and I think that is what you & your team also should do 🙂.

Thank you for reading 👋

--

--