I have been looking at these Chrome usage statistics available on chromestatus.com for a while together with Tsahi Levent-Levi for WebRTC Insights but they are too fascinating to keep them behind our paywall. Let’s do some coffee ground reading on the usage of a number of important APIs and what it tells us about what drives WebRTC in Chrome:
Google Meet.
Meet (or back in the day Hangouts) is a major driver for WebRTC to Chrome. It is no secret Google invests heavily in this area – surprisingly the only major party doing so. The data shows why.
Chrome metrics
Chrome gathers usage metrics on how certain Web features are used (see here for some detail but it remains pretty vague). These metrics drive the decision making whether to remove a feature that is considered unused.
Some of these metrics called UMA (User Metrics Analysis) are only available to Googlers. Others are public and can be found on the chromestatus.com page.
The numbers need to be taken with a grain of salt. Whenever we hear usage numbers from the WebRTC team at Google (which seem to be based on UMA) they come with a “Does not represent Chrome population” disclaimer. In addition to that the chromestatus metrics are measured in percentage of “Chrome page loads” which is an unknown number (but quite large presumably). But even if the chromestatus.com data does not represent the whole Chrome population, it does cover a massive amount of users and the tracking methodology is relatively consistent, making it valuable for trend tracking.
Since Chad wanted nicely looking graphs on a shared axis I built a tool that allows fetching the raw data from chromestatus for multiple datasets, provides for better resolution, and lets you sum up values from different datasets. You can find the tool here and we provide links to interactive versions of the graphs linked from each of them – remember to click for a full-size version.
Google’s numbers
Niklas Blum said a couple of very thoughtful words at KrankyGeek, calling 2021 the year real-time communication kept the world talking.
The graph shown is the ” received minutes”. It is not available in the publically available statistics. What we see is the first pandemic peak with a lot of work-from-home. During the summer (in the northern hemisphere) we see a slight decrease — seasonal effects. Then we see a massive increase from education moving online. We also see “peak WebRTC” at 100x the pre-pandemic usage. During the summer of 2021 usage dropped again. We’ll see how the usage develops during the winter…
getUserMedia and getDisplayMedia
The first usage statistics we look at is for getUserMedia, the API for access to the camera and microphone. It is used by all video conferencing apps but does not typically cover use-cases where one receives a WebRTC stream without sending one, like watching a real-time broadcast:
This shows the same usage pattern that Google presented at KrankyGeek which makes it a good metric to look at.
The getDisplayMedia screen sharing API is surprisingly small compared to getUserMedia. Note the change in scale on the y-axis, otherwise, it is too small to see together in the same graph.
Usage sees a tenfold increase during the first part of the pandemic but is stagnating since.
But usage is mere 2% of the getUserMedia usage and surely screens are shared more often? Well, if you remember the history of screen sharing in Chrome a bit, Google Meet does not use the getDisplayMedia API but continues to rely on its built-in extension. Under the hood, that still gets counted as getUserMedia and not getDisplayMedia.
Now that getDisplayMedia is getting some more love it will be interesting to see when Meet switches to the new and spec-compliant API. I expect a huge jump in usage, similar to the ones we see below for other APIs.
addStream, addTrack and addTransceiver
The addStream, addTrack and addTransceiver are different APIs to add the local media stream to the peer connection and send it. Make sure to check the fiddle of the month for a basic explanation of the differences between the three. The combined usage of these three APIs almost adds up to the getUserMedia usage.
In April 2021 we saw a drastic decrease in the usage of the addStream API. Until that point it had been looking very similar to the getUserMedia numbers:
Such a drastic drop means a very big user of that API suddenly stopped using it (while getUserMedia usage continues). The size of the decrease is massive – 0.3% of page loads. Or half of the total usage of the three APIs combined. And it happened on a single day, March 30st 2021. It was quite easy to validate this was Google Meet indeed.
Replacing the legacy addStream API with addTrack is straightforward – one just iterates over all the audio and video tracks of the MediaStream and calls peerConnection.addTrack(track, stream). There is even a codemod for it.
There was a corresponding change in the addTrack metrics:
The usage increased sixfold. Or, said differently, a single very large service is six times as big as all other users of that API combined.
What is interesting here is that addTrack usage is relatively constant even in the pandemic which is very different from what we see in addStream. There is growth during the first wave of the pandemic but the usage only triples compared to addStream which increased tenfold.
But behold, we see another interesting drop in October 2021 after the seasonal drop in general usage during the summer. No need to look very far, we see a corresponding increase in the addTransceiver APIs:
The addTransceiver API is a bit different since unlike the other APIs it is only available in “unified-plan” mode and the transition between the APIs is a bit more involved. Its usage has been limited to some early adopters of unified-plan such as Google Duo.
Once more we see the usage increase significantly in October 2021, even though it only doubles. This can be explained by the general decrease in usage compared to “peak WebRTC”. The switch took about two weeks but since it is a more complicated transition than from addStream to addTrack a gradual rollout makes more sense.
What else happened in October 2021 that would explain this? Well, Google Meet switched to using unified-plan as part of the deprecation of plan-b. We can also see that in this graph comparing unified-plan and plan-b:
Phase 1: WFH
We see at least two different phases in the usage. The first one starts in early 2020 and ends during the summer.
The usage of addStream which correlates with Google Meet increases tenfold and surpasses everything else. There is some growth but on March 16 usage takes off. addTrack behaves differently, decreasing a bit at first, growing by 25% in February. The growth phase starts a week later and only doubles in usage before plateauing. addTransceiver grows at a lower slope even but has a second growth spurt at the end of May 2020.
Phase 2: homeschooling
This phase starts after the summer break of 2020:
We see addStream (or Google Meet) quadrupling usage in that period (with a 30-day window). That doesn’t quite correlate with the increase in the received video minutes shown in Google’s data but we are looking at the single-time usage of adding a track to the RTCPeerConnection which will not reflect a change in conference sizes or an increase in the duration of the sessions.
addTrack triples in usage but compared to addStream is a seventh of that usage. addTransceiver starts out ahead of addTrack but after the data gap in October ends up below addTrack.
Note that there is a large gap in the data and we only have five data points in September, hence the unsmoothed data looks a bit different:
There are some notable events here such as addStream almost hitting 1% of page loads on October 20th, 2020. Then it drops to 0.33% the next day – getUserMedia behaves the same. One wonders what happened… this might be an artifact in the chromestatus data even? Hard to tell…
Summary
At the end of 2021 addTrack usage is down to pre-pandemic levels. The API is still fine and there is no technical reason for it. This is more likely due to the ups and downs of who uses the API. And note that overall usage (which is a product of API usage, conference size, and duration) has probably still increased compared to pre-pandemic levels.
Looking at these numbers paints a pretty interesting picture of how WebRTC is used in Chrome. The numbers explain why Google keeps on investing in WebRTC — Google Meet. The usage is so massive that changes to the application show up in multiple metrics. Google Meet has switched to actually using the “spec-compliant” APIs in a few places after lagging behind severely (and for no technical reason), putting an end to the phase where the WebRTC team was talking about “spec compliance” without actually using the new APIs themselves. A welcome change certainly.
If as a developer you just want to use WebRTC, you are strongly advised to ensure that your use-case is covered by what Google Meet wants. If you do, you know you’ll be in well-supported company with others on Chrome.
{“author”: “Philipp Hancke“}
Leave a Reply