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.

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.

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. That’s precisely your problem.
2. HTTP/2’s blind spot: 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/cellular networks it bites you.
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, the rest keep flowing. It also sets up faster (TLS is baked into QUIC, with 0-RTT resumption) — and that’s the real win on a flaky mobile network.
4. Cheapen the handshake at the Nginx/Caddy layer. Terminate TLS at the edge: HTTP/3 is already the default in Caddy, and Nginx 1.25+ enables it via the http2/http3 directives. Keep keep-alive on, and use OCSP stapling plus TLS session resumption (session tickets) to avoid re-handshaking on every connection. One more thing: for multiplexing to actually 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 — it’s cheap, backward-compatible, and clears most of your current bottleneck immediately. 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 drop domain sharding entirely; in an HTTP/2 world it’s an anti-pattern.