addTrack adoption
Its about time for some more data nerding. This time not using my own data but Chrome telemetry. Chrome publishes as large amount of metrics for all of its features and there are quite some WebRTC metrics buried in there. This graph for the RTCPeerConnection addTrack method sparked my interest:
The graph is taken from the Chrome statistics and shows the percentage of pageloads that use RTCPeerConnection.addTrack.
It starts some time in December 2017 after addTrack had landed in Canary. The percentage seems to be in relation to Chrome Canary as the percentage is higher than what we see later in the graph. This gets particularly common when Chrome 64 becomes beta in mid-january and the percentage of pageloads goes up to almost 0.0075%. Looks like some people are testing in the canary and beta versions at least.
The native addTrack was released in Chrome 64 in late January and we can see some adoption immediately. Hopefully that is because adapter.js was shimming addTrack and just started using the native version once it came out. — driving adoption like this is one of the goals of the project. Unfortunately there was a bug related to statistics in the Chrome 64 version of addTrack which caused later version adapter.js to shim addTrack in that version.
We can see more adoption six weeks later in mid-march which coincides with the Chrome 65 release where all versions of adapter.js used the native addTrack.
In particular this meant that appear.in started using the native version and maybe that is the cause for the large jump in usage? Its only 0.0010% of pageviews but the total number of pageviews in Chrome is huge.
What is even more interesting is that the usage shows a very distinct cyclic pattern with usage going down for two days even seven days. Which is exactly what we see on appear.in in our own usage metrics. That means appear.in could amount to around 30% of the total addTrack usage.
However, compared to the usage of the the legacy addStream method the adoption of addTrack is fairly low though. addStream is used by around 0.04% of pageviews which is roughly 16 times as much as addTrack with 0.0025%. This shows that the majority of the “WebRTC community” has not yet updated their code to stop using the “legacy” stream methods.
If you are a developer still using addStream: please read Jan-Ivars great post on the evolution of WebRTC 1.0 and update your code. Maintaining three different versions of similar APIs is not something browser vendors should be required to maintain for an extended period of time.
