HTTP/2 vs HTTP/3: what actually changes on a CDN

HTTP/2 multiplexes over TCP. HTTP/3 uses QUIC. Cloud CDN offers both, with HTTP/2 as fallback when UDP is blocked.

HTTP/2 fixed the one-file-per-connection mess. HTTP/3 fixes some of what TCP still costs on lossy paths. You want both at the edge, and you want fallback when a hotel network blocks UDP.

Multiplexing versus handshake

HTTP/2 multiplexes streams over one TCP connection. Loss still head-of-line blocks at the TCP layer. HTTP/3 on QUIC reduces that and shortens handshakes with TLS 1.3.

The CDN is where this belongs

Turning on h2/h3 on a single origin still leaves most users far away. Cloud CDN advertises both on 210+ PoPs. Origin protocol can stay older.

Do not shard hosts for HTTP/2 reasons

Domain sharding was an HTTP/1.1 trick. On HTTP/2 and HTTP/3 it usually hurts. One hostname on Cloud CDN is enough for assets, fonts and HTML.

Measure the waterfall, not the badge

DevTools protocol badges are not the goal. TTFB and LCP from the markets you sell to are.

Continue on Aptranet

Frequently Asked Questions

Is HTTP/1.1 gone?

No. Some clients still use it. The edge should speak all three without you managing three hostnames.

Must I enable HTTP/3 on origin?

No. The browser talks to Cloud CDN.

Why did a network fall back to HTTP/2?

UDP or QUIC was blocked. Fallback is correct behaviour, not a misconfiguration.