The transition from HTTP/2 to HTTP/3 can significantly reduce application response times. However, this isn’t always the case and depends on the circumstances. On mobile networks with high packet loss, performance can sometimes be disappointing.
Engineer Elvis Chidera shared these findings during P99 CONF 2026, as reported by DevClass. Chidera stated that the transition to HTTP/3 reduced the time required to establish a secure connection by 51 percent. The total response time of a mobile app’s home screen decreased by 17 percent. For certain read requests, latency dropped from 1.2 seconds to 120 milliseconds.
HTTP/3 uses QUIC, which runs on UDP. This replaces the TCP protocol, which forms the foundation for HTTP/2. Thanks to QUIC, fewer communication steps are required between the client and server to establish a connection. When resuming a previous connection, data can even be sent before the “handshake” is complete, under certain conditions.
On high-latency networks, this results in significant time savings. Chidera explained that, prior to the switch to HTTP/3, establishing a secure connection in Pakistan took nearly a second or longer for the slowest 10 percent of requests.
Android causes an unexpected problem
On the server side, the transition to HTTP/3 was fairly straightforward. Cloudflare already supports HTTP/3, so a minor configuration adjustment was all that was needed. However, an unexpected problem arose on Android, according to DevClass. The delay occurred in Cronet, the Google network library that was being used. In 10 percent of initializations, Cronet sometimes took more than 800 milliseconds to start up. This caused a significant delay.
This forced the developers to adjust their integration. If Cronet starts up simultaneously with other background processes, the application does not have to wait for the network software to finish booting up.
However, there was an even greater challenge. In regions with unstable connections, certain parts of the application actually slowed down after the switch to HTTP/3.
The cause appears to lie with Cubic. This is the algorithm Cloudflare uses to manage potential network congestion. When packets are lost, Cubic reduces the transmission speed. If this happens frequently on a connection, it can significantly degrade performance.
In similar tests with Google servers using BBR, the problem did not occur. BBR is an alternative algorithm that estimates available bandwidth and network latency to determine the transmission speed.
The measurements come from the meal delivery platform Delivery Hero, which has now migrated 95 percent of its users to HTTP/3. For connections where UDP traffic is blocked, HTTP/2 remains available as a fallback option.
Also read: Cloudflare blocks unencrypted HTTP traffic to API