How do HTTP/2 and HTTP/3 (QUIC) improve API performance?

Short answer: your 4-5 parallel requests per screen are exactly where HTTP/2 shines — turn it on now; if your audience is mostly mobile, follow up with HTTP/3.

Short answer

What you’re hitting is a protocol-level bottleneck: HTTP/1.1 opens a limited number of connections per host, and one request on a connection makes the next wait (head-of-line blocking). Domain sharding is a hack invented to dodge that — it’s a symptom, not a fix. I covered the caching side of the same “answer fast from close to the user” goal in the edge caching and invalidation question.

Why

1. HTTP/2 multiplexes everything onto one connection. All 4-5 requests flow concurrently over a single TCP+TLS connection; the “6 connections per host” ceiling is gone and so is the need for domain sharding. On top of that you get HPACK header compression — in a “many small requests per screen” pattern, the repeated headers come almost for free.

2. HTTP/2’s blind spot is TCP-level HOL blocking. The multiplexing lives at the HTTP layer, but underneath there’s a single TCP stream. Lose one packet and all streams wait until it’s retransmitted. On solid Wi-Fi you won’t notice; on lossy mobile networks it bites.

3. HTTP/3 (QUIC) closes that blind spot. QUIC runs over UDP and carries each stream independently; a lost packet only stalls that one stream. It also sets up faster (TLS is baked into QUIC, with 0-RTT resumption).

What to do

1. Turn on HTTP/2 first. Cheap, backward-compatible, and it clears most of your current bottleneck immediately. Already there in Caddy; in Nginx there’s been a standalone http2 on; directive since 1.25.1 (off by default).

2. Add HTTP/3 if your audience is mostly mobile. Default in Caddy; in Nginx the HTTP/3 module has existed since 1.25.0 but is experimental and isn’t in the default build — you need a binary compiled with --with-http_v3_module, then enable it with listen 443 quic;.

3. Cheapen the handshake. Terminate TLS at the edge, keep keep-alive on, and use OCSP stapling plus TLS session resumption (session tickets) to avoid re-handshaking on every connection.

4. Drop domain sharding entirely. For multiplexing to kick in, consolidate to a single origin; reintroduce sharding and you cancel HTTP/2’s benefit with your own hand.

Bottom line: I’d turn on HTTP/2 first, then add HTTP/3 for the mobile audience; QUIC’s per-stream independence and fast setup are what the user actually feels on a bad network. Trim handshake cost with a single origin, keep-alive on, stapling and session resumption. And in an HTTP/2 world, domain sharding is an anti-pattern.