HTTP/2 vs HTTP/3: what should I enable on my CDN?

Enable both HTTP/2 and HTTP/3 on your CDN. HTTP/2 (RFC 9113) runs over TCP and is supported almost everywhere. HTTP/3 (RFC 9114) runs over QUIC on UDP and can cope better with packet loss. Browsers use HTTP/3 when they can and fall back to HTTP/2 when they cannot, so keeping both costs nothing.

Why it matters

Both versions send many requests over one connection, which is faster than the one-at-a-time habits of HTTP/1.1. The difference is the transport underneath. HTTP/2 over TCP can stall every stream when a single packet is lost, because TCP delivers data in order. HTTP/3 uses QUIC, where streams are independent, and QUIC combines the connection and TLS 1.3 set-up into fewer round trips.

You do not rewrite your site to use either. The protocol is negotiated between the visitor's browser and the CDN edge. Your origin server can keep speaking HTTP/1.1 or HTTP/2 to the CDN.

How to set it up

Open your CDN's dashboard and look for the HTTP/3 option in the protocol or network settings. The wording and location differ by provider.
Confirm HTTP/2 is also on, and that your site is served over HTTPS, since both browsers and the protocols expect TLS.
Save the change and wait a few minutes for it to propagate.
Test it. In Chrome DevTools, open the Network panel, right-click the column headings, enable Protocol and reload. Entries show h2 or h3.
Optionally check from a terminal if your curl was built with HTTP/3 support:

curl -sI --http3 -o /dev/null -w "%{http_version}\n" https://example.com/

A result of 3 means the HTTP/3 connection worked.

How browsers choose

A browser's first visit usually uses HTTP/2. The server announces HTTP/3 in an Alt-Svc response header, for example alt-svc: h3=":443", and later requests can use it. So a first test may show h2 and a reload may show h3.

Common mistakes

Turning off HTTP/2 when enabling HTTP/3. Keep HTTP/2 as the fallback.
Blocking UDP port 443 on a firewall or corporate network and then wondering why h3 never appears; the browser quietly uses HTTP/2 instead.
Testing once and concluding it is not working, when the first request legitimately used HTTP/2.
Expecting a large speed-up on every page. The benefit is mostly on slow or lossy mobile connections.

Frequently asked questions

Do I need HTTP/3 for SEO?

No. It is not a ranking factor on its own. It may help real-visitor speed on some connections, and speed supports the user experience Google asks sites to deliver.

Is HTTP/3 risky to enable?

It is designed to fall back to HTTP/2 when blocked, so most sites see no breakage. Check your pages after enabling anyway.

Does my origin server need HTTP/3?

Not when a CDN sits in front. The CDN handles the visitor-facing connection and talks to your origin using whichever protocol the origin supports.

Crawvix's scan checks whether your site serves HTTP/2 or HTTP/3. To see yours, Try the free website sample.