It is time for another edition of “Is everyone switching to…“. Cloudflare recently published a blog post about Media over Quic (MoQ) which made a number of statements about WebRTC that require some “clarification”. Let us start with that and look at MoQ and WebTransport after that.
An odd understanding of WebRTC
The blog post which you can find here describes how MoQ is going to solve all of today’s realtime media transmission problems. First it tries to establish why WebRTC is not good – and the post gets that utterly wrong. One of the first claims made against WebRTC is that it is a peer-to-peer protocol and that this causes “issues”.
Full mess is not a predmoninant WebRTC architecture
WebRTC can be used without a server-side element to handle media. This is called “full mesh” – or as Emil Ivov called it a decade ago, “full mess”. While popular for a while this in WebRTC’s earlier days, full mesh has never been a reference architecture for how to do WebRTC. Most libraries doing this like the early SimpleWebRTC are no longer around and services have switched to using SFU-based architectures, some with optimizations such as Jitsi’s P2P4121.
In many WebRTC deployments today, the “peer” is a server. Fortunately Chrome gathers some public metrics (that we have looked at before in 2021) which we can use to make rough estimates for that claim. While there are no direct public metrics for “WebRTC is talking to a server” we can get a lower bound by looking at the usage of non-spec “simulcast SDP munging” which is still used by Google Meet among others. You can find these metrics here, comparing them with both getUserMedia and addTrack/addTransceiver:
The numbers have been fairly stable in the last few years. Simulcast SDP munging is 0.075% of pageloads, getUserMedia 0.225% and the addTrack/addTransceiver usage is 0.375% (for reference, peak WebRTC during the pandemic was 0.7% of pageloads). So about a third of the WebRTC usage (that is combined with getUserMedia) is using this kind of non-spec SDP modification and there are a number of SFUs out there that actually use the standard way for enabling simulcast so probably 40-50% of the time WebRTC is talking to a server.
Video media servers have been around for decades
Routing the media via a server – i.e using a MCU or SFU – was not a new solution made for WebRTC. These architectures existed in VoIP systems long before WebRTC. Most of the vendors behind these server-side video calling solutions eventually had to support WebRTC to get access in the browser (Zoom being an exception for a long time).
The “compromise on architecture” claimed by the blog post does not exist. WebRTC or similar techniques are deployed at scale for all kinds of services including video conferences, game streaming and real-time voice AI. See our long list of blackbox breakdowns for evidence, including Cloudflare calls and OpenAI (including the recent usage by OpenAI).
For large-scale events Google Meet uses WebRTC to create a peer-to-peer ECDN between the peers in the same (corporate) local network to avoid saturating the downstream connection of that network. Microsoft Teams does the same, using the WebRTC-based technology acquired with Peer5. One needs peer-to-peer for that.
Should I switch to Media over Quic (MoQ)?
QUIC for WebRTC has been talked about as early as 2015 and Google experimented with QUIC for data channels back in 2019. We had a great panel discussion back in 2023 here on webrtcHacks too. WebTransport, a way to establish a QUIC connection with a server, landed in Chrome on October 5th 2020, exactly five years ago.
I will spare you my opinion on MoQ (or summarize it as “yeah”), let’s rather look at the numbers. In the browser, MoQ is running over WebTransport so MoQ usage is a subset of WebTransport usage so we can use the WebTransport metrics to get an upper bound for MoQ usage. WebTransport has been shipping in Chrome with metrics since October 5th 2020, five years ago.
WebTransport on chromestatus – up.. and down
The usage metrics look quite… interesting:
Overall what it looks like is someone trying WebTransport in production for a while and then turning it off again. Multiple times. Attributing all these experiments to a particular site is quite hard, even for Google (as we have seen recently in WebRTC).
We see basically no usage interrupted by phases of some usage. The first phase is January 2022 to October 2022 with roughly 0.0006% of pageloads.
While that number may seem small, making a dent in Chrome metrics requires a very large scale deployment. The usage comes back in December 2022 (possibly from a different source) and then doubles to 0.002% of pageloads in March 2023:
That usage drops again in July 2023 and gets replaced by usage which goes up and down until December 2023:
Then… nothing until another bump in usage from June 2024 to July 2024 at roughly 0.0006% of pageloads:
Then again nothing until June 2025 when, after what looks like a partial rollout the numbers jump to 0.035% or 10x the previous peak usage. Now this bump is finally visible in comparison with WebRTC – which as a reminder remains relatively stable at 0.35% of pageloads or 10x of WebRTC.
It ended as quickly as it began, dropping to near zero at the end of July 2025.
Five years after shipping in Chrome we see only what looks like failed experiments which is both surprising and disappointing.
But why the blog post?
Now there is the question why Cloudflare would publish that blog post? The purpose of the blog post is to generate attention for MoQ. Which is fine, I am no stranger to that technique myself.
Saying “We’re joining Meta, Google, Cisco, and others” is an interesting claim. Companies generally do not make statements about what other companies do lightly. Some developers at those companies may be doing something with MoQ. However, this is far from the level of organisational commitment that Google had when announcing WebRTC, with Harald Alvestrand signing the announcement as “speaking for Google” and contining to maintain libWebRTC more than a decade later.
Every blog post that makes such a comparison between technologies (or services of which we have sadly seen that a lot in the WebRTC space), and painting “the others” in a bad light is somewhat revealing about the problems of the party that is writing the blog post and who they are comparing to.
Developers who are convinced MoQ is solving their problem (which may not even be what WebRTC was built for) may be struggling to convince their organisations to let them prove they are right (which is all too common!). A public blog post like the one by Cloudflare surely helps politically as those developers can point to it and argue “but Cloudflare says” to weaken the internal opposition. Or as a blog post puts it, one can use it to “convince your boss’ boss that the writing is on the wall”.
Well yes, good luck explaining the Chrome numbers to your boss’ boss! Maybe do some digging to find out what the experiments were and why they failed. Yes, WebRTC made compromises, many of them. It is naive to think MoQ will not have to.
To answer the title question: from the Chrome numbers it does not look like anyone has successfully switched from WebRTC to MoQ yet.
{“author”: “Philipp Hancke“}
Editor Note:
I did reach out to a contact at Cloudflare for review of the above. Cloudflare declined to comment on this one.
{“editor”, “chad hart“}