Your API response went from 320ms to 95ms after a CDN switch.
Nothing changed on the server. Same origin. Same payload.
The only difference: the CDN started speaking HTTP/3 to your clients.
Here's the setup:
Mobile app → Load Balancer → Origin (NestJS) → DB
Every request goes through the CDN first. Latency is acceptable, until high packet-loss environments (mobile 4G to 5G transitions, flaky WiFi, Asia-Pacific routes). You're seeing 800ms+ tail latency for the p99. The CDN supports HTTP/2 and HTTP/3. What do you enable?
A) HTTP/2 only — multiplexing over a single TCP connection eliminates the old HTTP/1.1 head-of-line problem. Proven, widely supported.
B) HTTP/3 only. Built on QUIC (UDP), eliminates TCP head-of-line blocking entirely, 0-RTT connection resumption. Modern clients handle it fine.
C) HTTP/2 to origin, HTTP/2 to clients. Maximize multiplexing end-to-end, avoid QUIC instability in enterprise firewalls.
D) HTTP/3 to clients, HTTP/2 to origin. QUIC handles the lossy last mile, HTTP/2 handles the stable datacenter leg.
One of these is how Netflix, Cloudflare, and most major CDNs actually handle this in production.
Pick one (A, B, C, or D) and tell me why. Full breakdown in the comments.
If your team is debating CDN config or protocol upgrades, share this. The tradeoff is sharper than most people think.
Drop your answer 👇
Top comments (7)
Answer: D — HTTP/3 to clients, HTTP/2 to origin ✅
Here's why, and why the others miss the point:
Why D wins:
The problem is the last mile. Mobile clients on lossy connections are where TCP falls apart.
HTTP/2 fixed HTTP/1.1's application-layer head-of-line blocking by multiplexing streams over one TCP connection. But TCP itself still has head-of-line blocking at the transport layer. A single lost packet stalls ALL streams until it's retransmitted. On a 4G connection dropping 2% of packets, your 20-stream HTTP/2 connection grinds to a halt.
HTTP/3 runs on QUIC (UDP). Each stream is independent. A dropped packet stalls only that stream, the other 19 keep flowing. Add 0-RTT resumption (subsequent connections skip the handshake entirely) and you shave 1-2 round trips on every reconnect. That's where the latency gains come from.
But your datacenter leg (CDN to origin) is a different story. It's a stable, low-loss private network. QUIC's benefits disappear on reliable connections. HTTP/2 multiplexing is mature, well-optimized, and doesn't carry QUIC's CPU overhead for cryptography (QUIC encrypts everything at the transport layer, no cleartext, ever).
This is exactly how Cloudflare, Fastly, and Akamai operate: HTTP/3 on the edge-facing side, HTTP/2 (or even HTTP/1.1 with keepalive) on the origin-facing side.
Why A falls short (HTTP/2 only):
HTTP/2 multiplexing is a genuine improvement over HTTP/1.1, but it doesn't solve TCP head-of-line blocking. On lossy mobile connections, you're still at the mercy of the TCP retransmission window. For p99 tail latency on bad networks, HTTP/2 won't move the needle.
Why B is wrong (HTTP/3 only):
HTTP/3 to origin introduces real operational risk. Enterprise firewalls and some cloud load balancers block UDP port 443 or rate-limit it. Your origin infra isn't the bottleneck, the last mile is. Fixing the origin leg with QUIC doesn't help the problem; it just adds complexity and potential breakage.
Why C is wrong (HTTP/2 end-to-end):
Same problem as A. You've done nothing about the last mile. Consistent HTTP/2 end-to-end sounds clean, but "clean" doesn't show up in your p99....
Nice post!
Great Share!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.