Is Everyone Switching to MoQ? A Critical Look at WebRTC and WebTransport Usage Data

This article, originally published by Philipp Hancke on October 7, 2025, addresses Cloudflare's recent blog post about Media over QUIC (MoQ), which made several assertions regarding WebRTC requiring "clarification". We will examine these claims before delving into MoQ and WebTransport.

An Odd Understanding of WebRTC

Cloudflare's blog post, which you can find here, implies that MoQ will solve all contemporary real-time media transmission problems. It first attempts to establish why WebRTC is purportedly inadequate, and in doing so, misrepresents the protocol. One of the initial claims against WebRTC is its designation as a peer-to-peer protocol, which allegedly causes "issues."

"Full Mesh" Is Not a Predominant WebRTC Architecture

WebRTC can be utilized without a server-side media element, a configuration known as "full mesh" – or, as Emil Ivov aptly termed it a decade ago, "full mess". While popular in WebRTC's early days, full mesh has never been considered a reference architecture. Most libraries that employed this model, like the early SimpleWebRTC, are no longer active, and services have largely transitioned to SFU-based architectures, some incorporating optimizations such as Jitsi’s P2P4121.

In many of today's WebRTC deployments, the "peer" is, in fact, a server. Fortunately, Chrome collects public metrics (which we have examined before in 2021) that allow us to make reasonable estimates regarding this claim. While direct public metrics for "WebRTC talking to a server" are unavailable, we can establish a lower bound by observing the usage of non-standard "simulcast SDP munging," a technique still used by Google Meet among others. You can find these metrics here, comparing them with both getUserMedia and addTrack/addTransceiver:

The numbers have remained relatively stable over the past few years. "Simulcast SDP munging" accounts for 0.075% of page loads, getUserMedia for 0.225%, and addTrack/addTransceiver usage for 0.375% (for reference, peak WebRTC during the pandemic reached 0.7% of page loads). This indicates that approximately one-third of WebRTC usage (combined with getUserMedia) employs this non-spec SDP modification. Considering that many SFUs utilize standard methods for enabling simulcast, it is plausible that WebRTC communicates with a server 40-50% of the time.

Video Media Servers Have Been Around for Decades

Routing media via a server – i.e., using an MCU or SFU – was not a novel solution developed for WebRTC. These architectures existed in VoIP systems long before WebRTC. Most vendors behind these server-side video calling solutions eventually had to support WebRTC to gain browser access, with Zoom being an exception for an extended period.

The "compromise on architecture" claimed by Cloudflare's blog post does not exist. WebRTC or similar techniques are deployed at scale for a wide range of services, including video conferences, game streaming, and real-time voice AI. Our comprehensive list of blackbox breakdowns offers ample evidence, including analyses of Cloudflare calls and OpenAI (including their recent usage).

For large-scale events, Google Meet utilizes WebRTC to create a peer-to-peer ECDN among peers within the same (corporate) local network, thereby preventing saturation of the network's downstream connection. Microsoft Teams employs a similar strategy, leveraging WebRTC-based technology acquired with Peer5. Such applications inherently require peer-to-peer capabilities.

Should I Switch to Media over QUIC (MoQ)?

Discussions surrounding QUIC for WebRTC began as early as 2015, and Google experimented with QUIC for data channels back in 2019. We also hosted a panel discussion on this topic here on webrtcHacks in 2023. WebTransport, a method to establish a QUIC connection with a server, was launched in Chrome on October 5, 2020 – exactly five years ago.

While I'll spare you my detailed opinion on MoQ (which can be summarized as "yeah"), let's examine the numbers. In the browser, MoQ runs over WebTransport; therefore, MoQ usage is a subset of WebTransport usage. This means we can use WebTransport metrics to establish an upper bound for MoQ adoption. WebTransport has been shipping in Chrome with metrics since its launch on October 5, 2020.

WebTransport on chromestatus – Up... and Down

The usage metrics for WebTransport appear quite... interesting:

Overall, the data suggests repeated instances of someone attempting to deploy WebTransport in production for a period, then subsequently disabling it. Attributing these experiments to a particular site is challenging, even for Google (as we have recently observed with WebRTC metrics).

We observe essentially negligible usage, interrupted by phases of limited activity. The first significant phase spanned January 2022 to October 2022, peaking at approximately 0.0006% of page loads.

While that number may seem small, making a discernible impact on Chrome metrics requires an extremely large-scale deployment. Usage reappeared in December 2022 (possibly from a different source) and then doubled to 0.002% of page loads by March 2023:

This usage declined again in July 2023 and was replaced by fluctuating usage that continued until December 2023:

Following a period of inactivity, another bump in usage occurred from June 2024 to July 2024, again at roughly 0.0006% of page loads:

Another quiet period ensued until June 2025, when, following what appears to be a partial rollout, the numbers surged to 0.035%, representing a tenfold increase over the previous peak usage. This spike is finally visible when compared to WebRTC – which, as a reminder, remains relatively stable at 0.35% of page loads, still ten times WebTransport's peak.

However, this surge ended as quickly as it began, dropping to near zero by the end of July 2025. Five years after its initial release in Chrome, we primarily observe what appear to be failed experiments, which is both surprising and disappointing.

But Why the Blog Post?

This raises the question of why Cloudflare would publish such a blog post. Its primary purpose is likely to generate attention for MoQ, a common and understandable marketing technique. (I am no stranger to that technique myself.)

Claiming to be "joining Meta, Google, Cisco, and others" is a significant assertion. Companies generally do not make statements about competitors' activities lightly. While some developers at those companies may be experimenting with MoQ, this level of activity is far from the organizational commitment Google demonstrated when announcing WebRTC, with Harald Alvestrand signing the announcement as "speaking for Google" and continuing to maintain libWebRTC for over a decade.

Any blog post that contrasts technologies (or services, a regrettably frequent occurrence in the WebRTC space) and portrays "the others" in a negative light often reveals underlying challenges faced by the authoring party and their comparison targets. Developers convinced that MoQ solves their specific problems (which may not even be what WebRTC was built for) might be struggling to persuade their organizations to allow them to prove their hypothesis (a common scenario!). A public blog post from Cloudflare can certainly provide political leverage, enabling these developers to point to it and argue, "but Cloudflare says," to weaken internal opposition. Or, as another blog post puts it, one can use it to "convince your boss’ boss that the writing is on the wall."

Good luck, however, explaining the Chrome numbers to your boss’s boss! It would be more insightful to investigate the nature of these experiments and why they failed. Yes, WebRTC made many compromises, and it is naive to think MoQ will not face similar challenges.

To answer the title question directly: based on the available Chrome metrics, it does not appear that anyone has successfully switched from WebRTC to MoQ yet.

Editor Note: Cloudflare declined to comment on this article when contacted for review.