Browser usage share statistics in the modern web development landscape
Certainly global browser usage share statistics (GBUSS) are meaningless when applied to your website:
- StatCounter data, the most commonly cited source of GBUSS, is derived from slightly less than 1% of the web, that percentage is decreasing year-over-year, and it’s known to be skewed—counting hits instead of unique visits,;
- GBUSS includes both mobile and desktop usage share yet many website’s actual BUSS is either nearly all mobile or nearly all desktop;
- Even country-specific BUSS, whether combined or filtered by desktop or mobile, is unlikely to reflect your website’s BUSS.
Real world browser usage patterns seem to be more niche-market based rather than having a global or geographic pattern. Corporate and business-to-business websites generally have higher Edge, Chrome for Enterprise, maybe IE11, and maybe Firefox ESR usage. Technology-related websites tend to have users that adopt the latest browser versions the moment they’re released paired with a small percentage of users running atypical browsers, such as Brave, w3m, and lynx. On fashion, grooming, and make-up websites you’ll likely see higher mobile and less desktop traffic.
Each niche has its own identity and demographics. Each website exists to fulfill the needs and wants of its particular niche. From this angle, the inapplicability of GBUSS to individual websites isn’t surprising. However, this perspective seems to be overlooked when it comes to using GBUSS to justify using a particular feature, especially in our own projects.
When you check a feature’s viability with
you should be skeptical.
CanIUse uses StatCounter’s skewed
for desktop and its mobile data is opaquely
extrapolated from other sources
Despite how brilliantly StatCounter’s marketing plays off of our drive to have
a website with global reach, StatCounter’s
Global Stats is only
applicable to StatCounter and its clients, not to you and not to your niche.
The next time someone states you should or should not do something according to
you should be skeptical.
does not necessarily disqualify a claim, it’s just that
ought to be ignored rather than assumed to be applicable to your website.
There are better options and they’re readily available.
The next time you’re on CanIUse go tothen to and import your Google Analytics visitor statistics, or from the same menu, toggle the appropriate browsers for your website. The inapplicability of GBUSS to your website isn’t really CanIUse’s fault. Showing some BUSS by default seems to be better than not showing anything at all. But perhaps more attention should be given to the importance of using your own BUSS.
In build pipelines
frontend toolchain is driven by StatCounter’s
config to share target browsers and Node.js versions between different frontend
Babel, PostCSS, their plugins, and many other frontend tools use Browerslist, and consequently, rely on CanIUse and StatCounter’s GBUSS under the hood.
In project management
Beyond frontend tooling, project management continues to be the place where website-specific BUSS is most useful. BUSS is a powerful aid for determining (1) when and how to implement a particular feature; and (2) when legacy code is able to be refactored or removed.
When we write code, we are limited by the tools available in our users' current
Some features can be taken advantage of immediately and do not interfere with
older browser versions, e.g., features unlocked via HTTP headers, such as
Some features require the usage share of an older browser to decline before any
hacks, workarounds, or less-than-ideal approaches can be refactored using a
relatively new feature.
Consider all the less-than-ideal approaches to layouts: table-based layouts
(either HTML tables or CSS’s
float-and-clear layouts and their variants, and inline-block-based layouts.
You didn’t need flexbox to implement a holy-grail style
It used to be done with tables and it’s been done with floats, but all
approaches had their fair share of bugs and maintainability problems.
Flexbox just happened to make that particular layout less buggy, easier to
implement, and easier to maintain.
I document these less-than-ideal situations with
For example, when I coerce nested flexboxes into a multicolumn layout, I create
an issue and tag it as
This way, I can find code that may be cleaned up once
CSS grid or CSS
multicol is viable according to my website’s
Hacks and workarounds for specific browsers can be handled in a similar way.
When adding a
<meta http-equiv='X-UA-Compatible' content='ie=edge'>
to your codebase, document this as a workaround for
IE10 and earlier by creating an issue and tagging
Once IE10 is practically nonexistent according to
find all issues tagged
ie<=10-workaround and remove the
are cheap wins for reducing page weight, providing a smoother user experience,
and easing maintenance work.
For this to workout, you do need to stay up-to-date with modern web development
Time spent doing that certainly isn’t free.
BUSS measurement and accuracy
If you need
data and you aren’t using analytics then you can find the raw hits and
user-agent strings in your server logs.
However, before tallying it up, realize that
is harder to measure than it seems.
User-Agent header, which
is typically derived from, is easily spoofable.
Furthermore, many users, corporate environments, and even web browsers block
It’s hard to get good data on public facing websites, on websites where the
user is fuzzy, and on websites that rely heavily on proxying or
For SaaS products,
for logged in users should be easy to obtain, but you might benefit from a
separate cohort for leads to make sure you’re not excluding potential clients.
Don’t expect your BUSS to be 100% accurate.
It will not be, even if you're paying for analytics.
At an individual level
is effectively meaningless.
At a userbase level, it’s assumed that not all your users are spoofing their
User-Agent request header or blocking trackers, and therefore
has some meaning.
Don’t let the inherit inaccuracy of BUSS lead you into thinking GBUSS are sufficient. It’s not.
Unfortunately, we generally treat
as if it had any relevance to our own websites.
When we make
informed decisions based on
we play into the idea that as an industry, we're data-driven, no matter how bad
the data is.
That said, BUSS continues to be a fixture in the web development landscape. The way we interact with BUSS has changed. Its become an obscure yet important piece in a huge, sprawling toolchain. But its use-case is still the same: informing us about the current and future viability of particular features so that we can better meet our users’ wants and needs.
Thank you for reading, and happy hacking.
is based on the cog icon originally from Font Awesome by Dave Gandy, licensed under CC BY 4.0.
Historical trendgraph on w3techs.com/technologies/details/ta-statcounter/all/all.
as 1 above,
but notice the graph has a downward trend.
There is also the
Historical trendsreport at w3techs.com/technologies/history_overview/traffic_analysis/all which appears to be the raw numbers used in the
We measure internet usage trends. To accurately measure usage, we have to base our stats on page views (and not unique visitors). StatCounter’s FAQ even includes a video explanation. I disagree with their counting method. I think browser usage share is more accurately described by unique visits than page views. Page views skews data in favor of users and web browsers that send the most HTTP requests. But I agree with the difficulties StatCounter raises in regards to calculating BUSS, which is also why I don’t think their statistics are useful for most people, and why I think their statistics are not what I’d consider to be
global. My disagreement comes down to an argument about what
usagemeans and what browser usage share should represent.
- Sampling bias in StatCounter’s Global Stats data was spotlighted by Wikipedia:StatCounter, and from there I verified that the claims are accurate.
Information for mobile versions is extrapolated from other sourcesfrom caniuse.com/usage-table.
- See GitHub:Browserslist/Browserslist
- I don’t use Google Analytics, so I’m assuming this works. It seems to be relatively popular. See GitHub:Browserslist/Browserslist-GA.
- See GitHub:Browserslist/Browserslist#custom-usage-data
- But flexbox does make holy-grail style layouts significantly easier. For a great overview on the subject, see Wikipedia:Holy grail (web design).
Blocking tracking is a certainly a good thing.
I have mixed feelings on collecting
User-Agentstrings. As a privacy absolutist, I think code should work in
any browserand websites shouldn’t have to collect this data at all. On the other hand, as a developer, I value my time and engineering effort. Having BUSS helps me make informed decisions. Ultimately, there is real value in collecting some user or device-related data. We should focus on ways data can be collected that are morally acceptible and preserve privacy of the end-user. Such as, (1) only collect exactly the things you need and no more; (2) make aggregated data available from a high-level, e.g., minimum bucket sizes of 15k or 100k users and classify anything not meeting that criteria as
other; (3) don’t make the raw data available; (4) round timestamps to the nearest day or hour, if they’re collected; (5) do not associate the data with an IP address or user; (6) limit collection into cycles, e.g., four weeks, and after these four weeks, keep the aggregated data and wipe all the raw data; (7) inform the user exactly what is being collected and for how long; and there are probably many other things that could be done.