# 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://muhammetsafak.com/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.

## 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](/just-ask/edge-caching-with-cloudflare-workers-kv-and-invalidation/).

## 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.

## Related Reading

- [How do I set up CDN asset versioning: hashing and a cache strategy on deploy?](https://muhammetsafak.com/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://muhammetsafak.com/just-ask/streaming-multi-gigabyte-file-downloads-without-exhausting-php-memory/) — Just Ask
- [WireGuard collides with Docker networks — how do I stabilize routing?](https://muhammetsafak.com/just-ask/wireguard-and-docker-network-ip-conflicts-and-routing/) — Just Ask