Also, what features in collector.js do not have wide browser support? If you let me know, I can address it. Is the amount of browsers who can not run this script statistically significantly, like more than 1% of devices?
I do have error reporting on the script so I know that if the script runs I catch all the errors. I guess I am missing if the script fails to compile in the first place.
BTW I just pushed a new version that uses ES6 as the TypeScript compile target rather than ES2020 for collector.js.
You can grab mine from our site, if you like.
It's from a checkout page (the most important page where fancy JS isn't worth a single lost sale) so it goes to great pains to catch all errors and not be itself a source of JS errors. It intercepts errors and POSTs them to the server with a good-faith attempt at getting the browser, faulting script, line number, column number, error message, and stack trace.
It was actually in a <script> tag and not in an external js, but that shouldn't matter too much. You can see the comments and code to support actually ancient browsers (predating IE6 and Firefox 24).
It's a fatal flaw in pretty much all modern web stats collection that makes it seem like JS and bleeding edge JS support are far more of the pie than they are. And any time it's brought up those same people say it's not worth actually collecting information about all hits, say, via the webserver logs, because it's small. But they never connect the dots...
Okay. I can assume that anyone who has JS disabled, and I know how to detect that in the iframe, as also not having WebGPU available. Because WebGPU is exclusively JS and if JS is disabled, it effectively disables WebGPU. I'll add that.
Hmm... technically correct, but I wonder if this is statistically relevant? Remember that I am currently collecting 30K browser samples per day. I'd have to miss 300 samples in a day this way for it to cause an error of 1%.
Sure, there is a small set of people who choose not to run JS, or use something like lynx that doesn't support it, but almost every browser version released in the last 20 years, certainly all the graphical ones, have by default good enough JS support to gather basic statistics and send them back to the server.
Near-universal: not universal. But people still running very old devices or browsers are not going to have a fun time on many sites regardless, and WebGPU is not likely to be used casually on random sites: it will be used for the same stuff that WebGL and canvas is today: mostly for special-purpose things like games, some visualisations, etc. – the sort of stuff that very old and slow devices will have trouble with in the first place.
So for fingerprinting, got it.
According to caniuse, promises are supported by Chrome since v33, by Edge since v12, by Firefox since v29, and by Safari since 7.1.
Both Chrome 33 and Firefox 29 were released in 2014.
Chrome (to include the original Chromium and forks like Edge and Brave) holds 80~90% of the browser market share, and the vast majority of those installations will either autoupdate or be manually updated on a regular basis.
The logical conclusion thus is that whatever feature(s) introduced by Chrome will be widely available for common use in a short period of time.
This is the positive side to a monopolized browser market: Whatever Chrome supports is what the commons can support.
Use Firefox, the last bastion of the Free Web.
https://gs.statcounter.com/browser-market-share: worldwide, Chromium-family browsers are at around 76%.
Naturally it depends on where you are: by Statcounter’s figures, Australia and USA are both under 62%, and India is over 95%.
(Note that Statcounter is far from reliable: its data comes from trackers that are blocked by most ad/content blockers, which mean it is likely to significantly undercount Firefox especially.)
And two other factors to consider here:
• On a feature like this, browser support is only one of the gating factors: you also need graphics card/driver support. For a long time, WebGL support was way lower than the browser support charts suggested, for this reason. (Subpoint: WebGPU is not a cohesive whole; devices may support some features and not others, which will always make life more difficult, and that’s about the graphics card hardware and driver, not the browser.)
• At this time, Chromium hasn’t shipped WebGPU on all platforms—only desktop platforms. Mobile platforms will lag, and I imagine that low-end devices will just not support WebGPU for many years to come.
Regardless, after the web.dev/baseline announcement, I looked at Browslerlist and one of our site's analytics and it is shocking how many people are not using the last two versions of evergreen browsers. There is a long tail of browser versions in those stats.