HTTP/3 in production: Delivery Hero's 18-market test finds faster responses, 4% lower throughput

Delivery Hero has published the results of a large production test of HTTP/3 against HTTP/2, and the answer is more mixed than the protocol's marketing suggests. In a talk at the P99 CONF 2026 virtual conference, a staff engineer from the food delivery company described faster responses and far fewer network failures, but also lower throughput in several markets and a stubborn problem on lossy mobile networks. These are the company's own numbers, so read them as one large data point, not a benchmark.

Key points

• Delivery Hero ran an A/B test of HTTP/2 versus HTTP/3 across 18 markets, for a platform with millions of daily users (P99 CONF session abstract).
• The abstract reports up to 17% faster p90 response times and 48% fewer network-level failures with HTTP/3.
• It also reports throughput degradation of 4% or more in several markets, which the speaker traced to packet loss correlation and per-market segmentation.
• The Register, reporting on the talk, says handshake latency fell 51% and about 95% of users moved to HTTP/3, with the rest falling back to HTTP/2, largely because their networks block UDP.
• On Android, Cronet initialization took about 800 ms at p90, which the abstract says reduces the benefit of 0-RTT.

What happened

The talk, "HTTP/3 in Production: What the Numbers Actually Say", was given by Elvis Chidera, a staff software engineer at Delivery Hero in Berlin, who managed the project according to The Register's report of 30 October 2026. The conference page describes a production A/B test of HTTP/2 versus HTTP/3 across an 18-market food delivery platform, and says the results were mixed: HTTP/3 improved some metrics but reduced throughput in several markets.

The conference abstract gives these figures: up to 17% faster p90 response times, 48% fewer network-level failures, throughput degradation of 4% or more in several markets, and an 800 ms p90 initialization time for Cronet (the Chromium network stack used on Android). It also mentions QUIC operational issues that get little attention, such as connection churn from NAT timeouts, and ends with a framework for judging whether a platform is ready for HTTP/3.

The Register's report, by Joab Jackson, adds more detail that we could not find on the conference page, so we attribute it to The Register. It says home-screen end-to-end response time fell 17%, handshake latency between apps and servers fell 51%, and response time in Pakistan roughly halved, where handshakes before the change could take nearly a second at p90. It also reports that read latency at p95 dropped from 1.2 seconds to 120 ms. About 95% of users moved to HTTP/3, and devices that could not use it, largely because their networks block UDP, fell back to HTTP/2.

Where the two sources differ is in emphasis. The conference abstract states plainly that throughput fell in several markets. The Register's summary leads with the speedups and describes the main open problem as congestion control on secondary screens in markets with packet loss, such as Pakistan. It says the team blames the Cubic congestion control algorithm used by Cloudflare, found no such problem with servers using BBR in its tests, and is working with Cloudflare on a fix. We could not confirm that last detail from a Delivery Hero or Cloudflare source, so treat it as The Register's account of the talk.

Background

HTTP/3 is defined in RFC 9114, published by the IETF in June 2022 as a Standards Track document. It maps HTTP onto QUIC, a transport that runs over UDP and includes TLS 1.3, instead of TCP. The RFC states that in HTTP/3 "one stream that is blocked or suffers packet loss does not prevent progress on other streams." Over HTTP/2 on TCP, by contrast, a single lost or reordered packet can stall every active transaction on the connection, even ones the loss did not affect.

A server advertises HTTP/3 with the Alt-Svc header, and a client may then try a QUIC connection. The RFC says that if QUIC connectivity fails, for example because UDP is blocked, clients should attempt to use the TCP-based versions of HTTP. That is the fallback path behind the 5% of Delivery Hero users who stayed on HTTP/2.

QUIC also supports 0-RTT resumption, which lets a client send application data before the handshake finishes by reusing parameters from an earlier connection. RFC 9001 (May 2021) warns that this data can be replayed by an attacker, so 0-RTT should not carry requests that would cause harm if repeated. For that reason, servers usually limit it to safe requests.

On the server side, Cloudflare's documentation says HTTP/3 is available on its Free, Pro, Business and Enterprise plans, is switched on in the dashboard under Speed, Settings, Protocol Optimization, and covers the connection between users and Cloudflare. HTTP/3 to the origin is not supported yet, according to that page. The Register reports that for Delivery Hero the CDN side was a configuration change; Android needed more work.

The numbers

The chart shows the reductions the sources report for the move from HTTP/2 to HTTP/3. The 17% and 48% figures are in the conference abstract (the 17% is described as "up to"); the 51% handshake figure comes from The Register's report of the talk.

Handshake latency51

Network-level failures48

Response time (p90, up to)17

Reported reductions after moving from HTTP/2 to HTTP/3 (Delivery Hero) (% lower)

	% lower
Handshake latency	51
Network-level failures	48
Response time (p90, up to)	17

Source: P99 CONF 2026 session abstract; The Register

These are not directly comparable. They mix percentiles and metrics, and neither source describes sample sizes or how the baselines were defined. The throughput result, a drop of 4% or more in several markets, is the number that does not fit on a "lower is better" chart, and it is the one to keep in mind when you read the headline gains.

What it means

For teams running mobile apps, the main lesson is that HTTP/3 is not a free upgrade. Handshake and failure improvements are plausible on lossy mobile networks because of the way QUIC handles loss, and Delivery Hero's results point that way. But the abstract also lists costs: lower throughput in some markets, NAT timeout churn, and Android startup cost from Cronet initialization at about 800 ms at p90, which cuts into what 0-RTT can save. The Register says the team forked Cronet (calling the result OKCronet) and overlapped its start-up with background work; we did not see the code.

For teams that use a CDN, turning HTTP/3 on may be only a setting, as Cloudflare's documentation describes. The harder work is measuring per market, because an average across 18 markets can hide a region where throughput got worse.

For readers who only browse the web, nothing changes: HTTP/3 is negotiated automatically and falls back to older versions when UDP is blocked.

What we don't know yet

• We have not seen the talk itself, only its abstract and The Register's report, so the test design, sample sizes and baselines are unknown.
• The conference page gives no date for the recording. The Register's article is dated 30 October 2026.
• The claim that Cloudflare's Cubic congestion control causes the remaining problem, and that a fix is being worked on with Cloudflare, comes from The Register only.
• Whether other large apps see the same throughput loss is not established by this single case.

What to watch next

Watch for the recording and slides from P99 CONF, for any statement from Cloudflare on congestion control for QUIC traffic, and for similar write-ups from other large mobile platforms. If you plan your own test, copy the shape of this one: segment by market, measure p90 and p95 together with throughput and failures, and track the share of users who fall back to HTTP/2.

Sources

• P99 CONF 2026: HTTP/3 in Production: What the Numbers Actually Say (primary)
• The Register: HTTP/3 is faster with some work and help from Cloudflare
• IETF RFC 9114: HTTP/3
• IETF RFC 9001: Using TLS to Secure QUIC
• Cloudflare documentation: HTTP/3