HTTP/2 vs HTTP/3 on a CDN: What to Enable and How to Test

If you put a CDN in front of your site, you will probably meet two switches in its settings: one for HTTP/2 and one for HTTP/3. The usual question is "which one do I want?" The practical answer is both. HTTP/3 does not replace HTTP/2; it is added next to it, and browsers choose between them on every connection. What matters is knowing what each does, what the CDN handles, and what you must check yourself, so that HTTP/3 never leaves some visitors with a slower or broken connection.

This guide is for site owners and developers using a CDN such as Cloudflare, Fastly or Amazon CloudFront, or any provider with similar settings. For the general background on both protocols and how they differ from HTTP/1.1, read HTTP/2 and HTTP/3: What Changes for Speed and How to Check, and for choosing and configuring a CDN in the first place, read CDN for SEO. This article focuses on the CDN decision: what to turn on, how to prove it works, and how to avoid the common failures. Neither protocol is a ranking factor, and no setting promises a particular speed-up.

Before you begin

Confirm HTTPS works. Browsers use both protocols only over HTTPS. See moving from HTTP to HTTPS if you are not there yet.
Know where the CDN sits. The CDN should answer for your public hostname. If visitors reach your server directly, CDN settings change nothing.
Have access to the CDN dashboard and, if you run your own edge, the firewall rules.
Record a baseline. Save a Lighthouse or PageSpeed Insights run and note your field data. See field data vs lab data.
Risk: a firewall that drops the UDP traffic HTTP/3 needs. Plan an hour, plus weeks of observation.

The two protocols in plain terms

Both HTTP/2 and HTTP/3 carry the same web requests: the same methods, status codes and headers, so your pages and applications do not need to change. They differ in how bytes travel.

HTTP/2 is specified in RFC 9113. It sends many requests over one TCP connection at the same time (multiplexing) and compresses headers (HPACK). TCP delivers bytes strictly in order, so if one packet is lost, every stream on that connection waits until it is resent. This is called head-of-line blocking at the transport layer.

HTTP/3 is specified in RFC 9114. It runs over QUIC (RFC 9000), a transport built on UDP that carries its own encryption using TLS 1.3. Each stream is delivered independently, so a lost packet delays only the stream it belongs to. Headers use QPACK. QUIC also identifies connections by connection IDs rather than by network addresses, so a connection can survive a phone moving from Wi-Fi to mobile data.

	HTTP/2	HTTP/3
Specification	RFC 9113	RFC 9114 (with QUIC in RFC 9000)
Transport	TCP	QUIC over UDP
Typical port	443 TCP	443 UDP
Encryption	TLS (usually 1.2 or 1.3)	TLS 1.3, built into QUIC
Lost packet	Can stall all streams	Stalls only the affected stream
New connection	TCP handshake plus TLS handshake	One combined handshake
If unavailable	Falls back to HTTP/1.1	Falls back to HTTP/2 or HTTP/1.1 over TCP

On a new connection, TCP needs a round trip before TLS 1.3 starts its own, so HTTP/2 needs two round trips before the first request. QUIC combines transport and encryption setup in one. The saving is largest when latency is high, which is when a visitor is far from the nearest edge location.

What changes when a CDN is involved

With a CDN there are two separate connections. The visitor connects to a CDN edge server near them, and the CDN connects to your origin server when it needs something it has not cached. The protocol your visitors use is decided at the edge. The protocol between the CDN and your origin is separate, and many providers use HTTP/1.1 or HTTP/2 for that leg, so you can usually offer HTTP/3 to visitors without your origin supporting it. Confirm this in your provider's documentation. The CDN is therefore the sensible place to enable HTTP/3: you do not need a QUIC-capable web server, and your origin firewall needs no UDP rule for it. web.dev explains why a CDN helps even uncacheable pages.

Step-by-step instructions

Step 1: Check what visitors get today

Open your site in Chrome, press F12, choose the Network tab, right-click a column heading and tick Protocol, then reload. The value h2 means HTTP/2, h3 means HTTP/3, and http/1.1 is the old protocol. Check the HTML document and a few of your own static files. Third-party files use whatever their host offers.

What success looks like: You know the protocol shown for your HTML and your own files.

Step 2: Make sure HTTP/2 is on at the CDN

Many providers enable HTTP/2 by default, but check the CDN's protocol or network settings. Then test pages that submit forms, log in or call an API, because HTTP/2 requires lowercase header names and some old applications send headers it rejects.

What success looks like: The Protocol column shows h2 for your pages, and nothing is broken.

Step 3: Enable HTTP/3 at the CDN

Look for an HTTP/3 option, sometimes labeled with QUIC, in your CDN's protocol or network settings. Menu names change between providers and over time, so follow your provider's current documentation. In general terms:

Cloudflare: the dashboard has protocol settings for your zone; look for HTTP/3.
Fastly: HTTP/3 is a service-level feature described in Fastly's documentation; follow the current instructions there.
Amazon CloudFront: a distribution has a setting for the HTTP versions it supports; look for HTTP/3 next to HTTP/2.
Other providers: search the provider's documentation for HTTP/3 or QUIC.

Leave HTTP/2 enabled: clients usually reach you over TCP first and are then told about HTTP/3, and clients whose networks block QUIC need the fallback.

What success looks like: The setting is saved and the provider shows it as active.

Step 4: Confirm the server advertises HTTP/3

A server tells browsers it offers HTTP/3 with an Alt-Svc response header (RFC 7838):

alt-svc: h3=":443"; ma=86400

h3 names the protocol, :443 is the UDP port, and ma is how many seconds the browser may remember the offer. Check from a terminal:

curl -sI https://example.com/ | grep -i alt-svc

Some clients can also learn about HTTP/3 from DNS HTTPS records (RFC 9460), which some CDNs publish, so a browser may use HTTP/3 on a first visit.

What success looks like: The alt-svc header names h3.

Step 5: Test HTTP/3 itself

Three methods, from the most to the least reliable:

Browser. Reload your page twice in Chrome or Firefox with the Protocol column visible. The first load may show h2 while the browser learns of HTTP/3; later loads should show h3. An extension, VPN, proxy or corporate policy can disable HTTP/3 in the browser, so try a second browser if it looks off.
curl built with HTTP/3 support. Run curl --version and look for HTTP3 in the feature list. Then:
```
curl -sI --http3 https://example.com/ | head -n 1
curl -s -o /dev/null -w "%{http_version}\n" --http3-only https://example.com/
```
--http3 tries HTTP/3 and falls back, so the first line may show an older version if QUIC fails. --http3-only fails instead of falling back, and prints 3 when it works. Many curl builds lack HTTP/3; if yours does, use another method.
Online HTTP/3 checkers. They test from their own servers and report whether the site accepts QUIC connections. They only show what their network sees, so confirm with a browser.

What success looks like: At least one method shows HTTP/3, and a fallback test still shows HTTP/2 working.

Step 6: Test the fallback

HTTP/3 should never be the only way in. Clients fall back to HTTP/2 over TCP when UDP is blocked, when the QUIC handshake fails, or when the client does not support HTTP/3. Simulate it with curl --http2, a browser with HTTP/3 disabled, or a network that blocks UDP. Pages must load normally either way.

What success looks like: With HTTP/3 unavailable, the site still loads over h2.

Step 7: Measure the result

Run PageSpeed Insights or Lighthouse before and after, several times each from the same location, and then watch field data for a few weeks. Lab tools simulate network conditions and may not show a benefit some real visitors get. See Core Web Vitals explained and improving Lighthouse performance. If the numbers do not move, the protocol was not your bottleneck.

What success looks like: You have a saved before and after, or you know the protocol was not the limit.

When HTTP/3 helps and when it does not

HTTP/3 tends to help most when connections are lossy or have high latency, such as mobile networks, long distances, or pages that need many separate requests. It matters less when most of your weight is one large image, when your server is slow, or when visitors sit close to the edge on a stable link. Time to first byte, largest contentful paint and layout shift are usually decided by other work: server time, image weight and reserved space. For those, see fixing TTFB and fixing LCP. Compression such as Brotli and gzip and caching usually change load time more than the protocol does.

For crawling, Google's crawler documentation lists HTTP/1.1 and HTTP/2, with HTTP/1.1 the default at the time of writing, and does not describe either as a ranking signal. Enabling HTTP/3 for visitors does not stop crawlers from using HTTP/2 or HTTP/1.1; check the current page rather than assuming.

Firewall and UDP 443 pitfalls

UDP 443 blocked on your own network. If you run your own edge or origin that serves HTTP/3, the firewall or cloud security group must allow inbound UDP on the advertised port. Rules written for web traffic often allow only TCP.
Networks that block UDP. Some corporate networks, schools and public Wi-Fi block or throttle UDP. Clients on them fall back to HTTP/2, which is why the fallback must work. An attempt that fails can add a short delay before the fallback.
Security tools. A web application firewall, load balancer or monitoring tool may handle UDP differently from TCP. If traffic counts look odd after enabling HTTP/3, check where those tools sit.
Bot protection. Review bot rules so verified crawlers are not challenged, whatever the protocol. See Cloudflare bot blocking and verifying Googlebot and Bingbot.
Uppercase headers. Both protocols require lowercase header names; a mismatch can cause errors such as ERR_HTTP2_PROTOCOL_ERROR.
Stale Alt-Svc. If you disable HTTP/3 later, browsers may keep trying it until the ma lifetime expires.

Final verification checklist

The CDN answers for your public hostname and HTTPS is valid.
HTTP/2 is enabled and your forms and APIs still work.
HTTP/3 is enabled at the CDN and HTTP/2 is still on.
The alt-svc header names h3.
A browser or curl test shows HTTP/3, and a fallback test shows HTTP/2.
Verified crawlers still receive normal 200 responses.
Before and after measurements are saved.

Common mistakes to avoid

Turning off HTTP/2 when turning on HTTP/3. HTTP/3 needs the TCP path for discovery and fallback.
Forgetting the firewall. Blocked UDP 443 makes HTTP/3 invisible, and fallback hides the problem.
Expecting ranking gains. The protocol changes delivery, not relevance.

Troubleshooting

The browser shows h2 even though HTTP/3 is on

Reload again, check the alt-svc header, and test in a second browser. Extensions, VPNs and enterprise policies can disable HTTP/3. Then confirm UDP 443 is reachable from your network.

The `alt-svc` header is missing

The setting may not be active yet, the request may be going to the origin instead of the CDN, or a cache or proxy in between may be removing the header. Test the public hostname.

curl reports an unsupported option

Your curl was built without HTTP/3 support. Use a browser or an online checker.

Pages load more slowly after enabling HTTP/3

Test with HTTP/3 temporarily off to compare, and check for blocked UDP, which makes clients try and fall back. Report persistent problems to your CDN provider.

Frequently asked questions

Should I enable HTTP/2, HTTP/3, or both on my CDN?

Both, in most cases. HTTP/2 stays the dependable base over TCP, and HTTP/3 is an addition that clients use when it works. Turn HTTP/3 off only if you find a specific problem.

Does HTTP/3 use TCP?

No. It runs over QUIC, which uses UDP, normally port 443. Clients that cannot use it fall back to HTTP/2 over TCP.

Do I need HTTP/3 on my origin server?

Not usually. The CDN can speak HTTP/3 to visitors and a different version to your origin. Confirm in your provider's documentation.

Will HTTP/3 improve my Core Web Vitals?

It can help on slower or lossy connections, but it is rarely the main factor. Images, JavaScript and server time usually matter more. Measure before and after.

Is HTTP/3 safe to enable?

It is a standard (RFC 9114) supported by current major browsers, and clients fall back automatically. The risks are firewalls and security tooling, which is why you test.

Does Crawvix check this?

Crawvix's scan checks "HTTP/2 or HTTP/3". It reports the HTTP version the scanner negotiated and passes for version 2 or 3. It does not tell you whether alt-svc advertises HTTP/3, so use the tests above for that.

Official references

Want to see how a site is checked from the outside? Try the free website sample. This guide provides technical information, not a promise about speed or rankings.