Tech News HTTP/3 is faster with some work and help from Cloudflare

[SeriousHoax]

Content source

https://www.theregister.com/devops/2026/10/30/http/3-is-faster-with-some-work-and-help-from-cloudflare/5306767

When you're ordering food from your phone, even time spent navigating the app is time wasted. At the P99 2026 virtual conference, Elvis Chidera, a staff engineer at Germany-based global delivery service Delivery Hero, explained how the company moved most of its user base to HTTP/3, and consequently cut its apps’ total end-to-end response time of the home screen by 17 percent.

Chidera, who managed the project, explained that, as promised on the tin, HTTP/3 delivers the web faster than HTTP/2, though it has slow bits that need to be adjusted to work properly.

Uber eats Delivery Hero​

Delivery Hero is all but unknown in the US, which is dominated by Uber Eats and DoorDash. But it is a company with global reach outside the US, with an estimated user base of 60 million across Europe, Latin America, Africa, the Middle East, and Asia. Uber is currently acquiring Delivery Hero for $14.8 billion, with plans to unite the company with Uber Eats.

With this purchase, Uber would expand the number of markets where it offers both ride-hailing and delivery services, though not necessarily under the Uber Eats nameplate. Delivery Hero centrally manages separate apps for different regions, all of which it built or acquired. Asians can order poke bowls and sundries through Foodpanda. Turks can order kebabs through Yemeksepeti. Throughout Spain, Italy, Poland, Romania, Ukraine, and much of Africa, the Glovo app is where to ring up the late-night deliveries. And in Latin America, users dial in to PedidosYa to get what they need from nearby farmacias, restaurantes, and mercados.

All these regions have widely varying network connectivity, a problem Delivery Hero wanted to minimize.

Last mile networking was most often the bottleneck. Apps in Pakistan, for instance, could take nearly a second (at p90) to establish a secure handshake with a server. The engineering team looked at HTTP/3 as a way to lower, even eliminate, that latency.

A QUIC-er HTTP​

The Internet Engineering Task Force (IETF) formally introduced the third version of the internet’s Hypertext Transfer Protocol in 2022. HTTP is the application layer protocol that connects browsers and other resources connected to servers over the Internet.

The previous versions of HTTP were built on the Transmission Control Protocol (TCP), which offered guaranteed delivery and flow control. In conjunction with the Internet Protocol (IP), TCP/IP built the modern internet.

HTTP/3 replaced TCP with Quick UDP Internet Connection (QUIC), developed by Google, to address some of TCP’s perceived sluggishness as a transfer protocol.

UDP stands for User Datagram Protocol and, unlike TCP, it does not guarantee packet delivery or flow control. UDP is faster because it doesn’t wait around for a signature (QUIC adds in its own flow control on top of UDP).

But the UDP-based HTTP/3 reduces, and sometimes eliminates, the round trips needed to secure connections. The app can cache a session ticket and, on a later connection, use QUIC's 0-RTT capability to start sending eligible application data while the handshake is still underway, rather than waiting for it to finish.

“Essentially, you can eliminate that one second” of latency that plagued slower networks, Chidera said. “You don't want to pay the cost of two round trips just to exchange data, if you could do it faster.”

And unlike HTTP/2, HTTP/3 doesn’t get hung up when packets are lost or delayed. There’s no head-of-line blocking because packets are sent in multiple streams, not just the single string that HTTP/2 offers.

Multitask during initialization​

Setting up HTTP/3 turned out to be surprisingly easy,..................................

HTTP/3 is faster with some work and help from Cloudflare

How the Uber-bound delivery giant tuned its mobile networking stack to cut latency

www.theregister.com

 

[Bot]

(link omitted)

Hi SeriousHoax, this is a useful production result, but the headline is broader than the evidence. The real conclusion is HTTP/3 can substantially improve mobile tail latency when the network is the bottleneck—provided the client stack, congestion control and fallback path are properly engineered.

A few important details:

• The talk’s own synopsis describes up to 17% faster p90 end-to-end responses and a 48% reduction in network-level request failures, but also says some markets suffered more than 4% throughput degradation. So HTTP/3 was not automatically faster everywhere.
• Delivery Hero had to address Cronet’s roughly 800 ms p90 initialization cost on Android. That is an implementation problem rather than an HTTP/3 defect, but it neatly demonstrates that a fast protocol wrapped in slow startup code is still slow.
• Keeping HTTP/2 fallback was essential because some networks block or mishandle UDP. Moving 95% of users to HTTP/3 is impressive; forcing the other 5% to stare at a spinner would have been less so.
• The article’s explanation of head-of-line blocking is slightly loose. HTTP/2 already multiplexes multiple streams, but they share one ordered TCP byte stream, so a lost packet can temporarily stall every HTTP/2 stream. QUIC isolates delivery between streams, although loss can still delay the affected stream and reduce the connection’s sending rate.
• UDP is not intrinsically magic fast dust. QUIC adds reliability, flow control, congestion control and integrated TLS on top of UDP. Its advantage comes largely from faster connection establishment and avoiding TCP-level cross-stream blocking.

There is also a security qualification around 0-RTT. It can send eligible data before a resumed handshake completes, but early data can be replayed. The HTTP/3 specification explicitly requires replay mitigations. Retrieval requests may be suitable; placing an order or making a payment needs much more care—you do not want “QUIC-er” to mean “two dinners billed instead of one.” See RFC 9114’s early-data requirements and the broader QUIC deployment guidance.

The CUBIC-versus-BBR result is also workload-specific rather than proof that CUBIC is universally bad. CUBIC interprets loss as congestion and backs off, which can hurt where loss is random radio noise rather than an overloaded link. Cloudflare still uses CUBIC as quiche’s default while progressively testing BBRv3, illustrating why per-market measurements matter more than protocol slogans.

Overall, this is good evidence for HTTP/3 on geographically diverse mobile services—not evidence that merely ticking Cloudflare’s HTTP/3 switch guarantees a 17% improvement. The engineering and measurement did at least as much work as the checkbox.

Sources

• RFC 9114: HTTP/3
• RFC 9308: Applicability of the QUIC Transport Protocol

 

[Marko :)]

QUIC sucks so much I disabled it entirely in Firefox.

 

[SeriousHoax]

QUIC sucks so much I disabled it entirely in Firefox.

What was the issue?

 

[TairikuOkami]

Faster is never safer, companies want to save money, it is like a passkey vs 2FA, I block QUIC via a firewall and browser's settings.

 

[Marko :)]

What was the issue?

Mainly YouTube. With QUIC enabled, YouTube constantly buffers for me and speed is varying from 300 kbps to maximum I've seen 20000 kbps. More often than not, videos were loaded at speed of 5000 kbps. As soon as I disabled QUIC, buffering issues disappeared and speed on YouTube increased to ~500000 kbps.

And I thought maybe that was the issue with my PC, ISP or the web browser; tested on several other, as well as on different ISPs and browsers... exactly the same behavior. If I remember I even posted here looking for a solution long time ago. Gave QUIC a try a year ago as back then it was experimental protocol. Turns out nothing changed.

So yeah, I passionately hate QUIC and disable it wherever I can.

Faster is never safer, companies want to save money, it is like a passkey vs 2FA, I block QUIC via a firewall and browser's settings.

If it was only faster...

 

[SeriousHoax]

Mainly YouTube. With QUIC enabled, YouTube constantly buffers for me and speed is varying from 300 kbps to maximum I've seen 20000 kbps. More often than not, videos were loaded at speed of 5000 kbps. As soon as I disabled QUIC, buffering issues disappeared and speed on YouTube increased to ~500000 kbps.

And I thought maybe that was the issue with my PC, ISP or the web browser; tested on several other, as well as on different ISPs and browsers... exactly the same behavior. If I remember I even posted here looking for a solution long time ago. Gave QUIC a try a year ago as back then it was experimental protocol. Turns out nothing changed.

So yeah, I passionately hate QUIC and disable it wherever I can.

If it was only faster...

Must be an external factor that hampers QUIC on your case on YouTube, not the QUIC protocol itself.
Your issue sounds like ISP (even if you checked multiple ISPs) throttling QUIC. I never had any issues with it. I only experienced faster navigation with QUIC.
Besides, YouTube or any Google services would be the last place where QUIC itself would have an issue.

This is a stat from my router for the last 49 minutes. Two other family members have been watching YouTube on their phones during this time, while I've been casually browsing MalwareTips. As you can see, QUIC is dominating the download section here, as it is used by YouTube. So QUIC itself is not an issue.
Don't shoot the messenger

 

[SeriousHoax]

Regarding QUIC vs TLS. Here's a very basic latency test

 

[Marko :)]

Must be an external factor that hampers QUIC on your case on YouTube, not the QUIC protocol itself.
Your issue sounds like ISP (even if you checked multiple ISPs) throttling QUIC. I never had any issues with it. I only experienced faster navigation with QUIC.
Besides, YouTube or any Google services would be the last place where QUIC itself would have an issue.

This is a stat from my router for the last 49 minutes. Two other family members have been watching YouTube on their phones during this time, while I've been casually browsing MalwareTips. As you can see, QUIC is dominating the download section here, as it is used by YouTube. So QUIC itself is not an issue.
Don't shoot the messenger
View attachment 301028

I don't believe ISP is the issue. As I said, I tried multiple networks; I have FTTH at home, Wi-Fi at work, three different mobile networks. I even connected to multiple VPN servers to rule out internet in Croatia, same behavior. I had no idea what was going on until I saw others having exactly the same issues on Reddit.

It's very unreliable protocol. When it works, it works; when it doesn't, it slows down the web.

 

[SeriousHoax]

I don't believe ISP is the issue. As I said, I tried multiple networks; I have FTTH at home, Wi-Fi at work, three different mobile networks. I even connected to multiple VPN servers to rule out internet in Croatia, same behavior.

Whatever the reason is, it's external, not QUIC itself. Google services have been using QUIC for years. If it couldn't stream 4K YouTube videos without buffering, it wouldn't have been used. There was a couple of years old study where they found that QUIC had no issue upto 600 Mbps. Above that there was a performance degradation compared to the good old HTTP/2. So, 600 Mbps is way above your issue where it was unable to go over 5000 kbps.