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

> Turn on HTTP/2 today, since multiplexing collapses 4-5 requests per screen onto one connection; add HTTP/3 for a mobile audience and drop domain sharding.

- Asked: 2026-05-21
- Answered: 2026-05-24
- Asked by: Kerem
- Tags: performans, altyapi, networking
- Source: https://www.muhammetsafak.com.tr/en/just-ask/how-http-2-and-http-3-improve-api-performance/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** Our mobile app fires 4-5 requests to the API at once on a single screen to load the profile, notifications, cart and recommendations. On HTTP/1.1 the screen fills slowly because of per-host connection limits and head-of-line blocking, and we're fighting with domain sharding.

What's the architectural gain in moving the infrastructure to HTTP/2 or HTTP/3? And how do I optimize the TLS handshake at the Nginx/Caddy layer?


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.

## Related Reading

- [How do I set up CDN asset versioning: hashing and a cache strategy on deploy?](https://www.muhammetsafak.com.tr/en/just-ask/cdn-asset-versioning-and-cache-strategy-on-deploy/) — Just Ask
- [How do I stream 2-5 GB file downloads without blowing up PHP's memory?](https://www.muhammetsafak.com.tr/en/just-ask/streaming-multi-gigabyte-file-downloads-without-exhausting-php-memory/) — Just Ask
- [WireGuard collides with Docker networks — how do I stabilize routing?](https://www.muhammetsafak.com.tr/en/just-ask/wireguard-and-docker-network-ip-conflicts-and-routing/) — Just Ask