Hossam EL-Kashef

The Horizon

Still on HTTP/1.1? Should you jump to HTTP/2 or HTTP/3?

25 October 2026 · Hossam EL-Kashef

If you’re still on HTTP/1.1, the first move is easy: get to HTTP/2. Whether to go further to HTTP/3 depends where you sit.

Two numbers caught my eye this week:

  • 41.1% of websites support HTTP/3, according to W3Techs (25 October 2026). Cloudflare does most of the lifting: 88.7% of sites served by Cloudflare use it, compared with 12.3% for nginx and 2.5% for Apache.
  • But on Cloudflare’s own network, only about 20% of requests actually use HTTP/3. HTTP/2 is around 52%, and good old HTTP/1.x is still around 27% (Q3 2026, Cloudflare Radar data via TechnologyChecker). Bots and scripts are a big part of that HTTP/1.x share.

So support is high, real usage is lower. And a lot of traffic hasn’t even made the first jump yet.

Step zero: still on HTTP/1.1? Move to HTTP/2 first

This is the no-brainer part.

  • HTTP/1.1 handles one request at a time per connection (pipelining exists, but almost nobody uses it). Browsers work around it by opening several connections per host (usually up to 6), and pages still queue up.
  • HTTP/2 multiplexes many requests over one connection and compresses headers. Fewer connections, less waiting, same HTTPS setup.
  • Browsers only use HTTP/2 over HTTPS. If you’re already on TLS, it’s often one line in your web server or a setting on your load balancer or CDN.
  • It’s mature. HTTP/2 has been a standard since 2015 (RFC 7540, replaced in 2022 by RFC 9113), and every current browser and major server supports it.

One thing to clean up while you’re at it: old HTTP/1.1 tricks like domain sharding and huge concatenated bundles were built around its limits. With HTTP/2 they can stop helping, so measure before you keep them.

Once you’re on HTTP/2, the HTTP/3 question below is about the next step, not the first one.

What HTTP/3 adds on top

HTTP/3 was standardised in 2022 as RFC 9114. The big change is underneath: it runs on QUIC over UDP instead of TCP.

  1. No more TCP head-of-line blocking. With HTTP/2, many requests share one TCP connection. If one packet is lost, everything behind it waits. QUIC handles each stream separately, so one lost packet only slows its own stream.
  2. Faster connection setup. TLS 1.3 is built into QUIC, so the transport and encryption handshakes happen together instead of one after the other. That usually saves one round trip compared with TCP plus TLS 1.3.
  3. Connections can survive a network change. QUIC identifies a connection by an ID, not by your IP and port, so moving from Wi-Fi to mobile data doesn’t have to mean starting over.

None of this makes your backend faster. It makes the network part faster, and mostly on bad networks.

Who should turn it on now

  • You’re behind a CDN. On Cloudflare and most big CDNs it’s a setting. Browsers learn about HTTP/3 through the Alt-Svc header or HTTPS DNS records, and fall back to HTTP/2 when UDP is blocked. Low risk, easy to roll back.
  • Lots of your users are on mobile or weak networks. Packet loss and network switching are exactly what QUIC was designed for. This is where people feel the difference.

Who can wait

  • You self-host with a small team. nginx has had built-in HTTP/3 support since version 1.25.0 (still marked experimental, and not built by default), but you still need UDP 443 open on every firewall and load balancer in the path, new config, and monitoring that understands QUIC. A well-tuned HTTP/2 setup beats a half-working HTTP/3 one.
  • Your users are mostly on fast, stable office networks. They probably won’t notice.
  • Your network blocks or throttles UDP. Some corporate networks do. Clients will fall back to HTTP/2, which is fine, but then you’ve done the work for little gain.

How I’d do it

  1. Measure first: real-user metrics like time to first byte and LCP, split by mobile and desktop.
  2. Turn HTTP/3 on at the edge (CDN or load balancer), not deep inside your stack.
  3. Keep HTTP/2 enabled as the fallback. Don’t remove it.
  4. Compare the same metrics after a week or two. Keep it if it helps, roll back if it doesn’t.

Don’t switch for the badge. Switch because your users are on networks where it matters.