What HTTP/2 and HTTP/3 Improve Over HTTP/1.1

The HTTP/1.1 pain

One connection handled one request at a time, so resources queued (head-of-line blocking); browsers opened many connections to cope, paying handshake and overhead.

HTTP/2 gains

• Multiplexing: many requests and responses on one connection, no mutual blocking;
• Header compression: HPACK shrinks repeated headers, saving bandwidth;
• Server push: proactively send resources (rarely used, often dropped).

Why HTTP/3 switches to UDP

HTTP/2 multiplexes, but a lost TCP packet still blocks all streams (TCP-level head-of-line blocking). HTTP/3 runs on QUIC over UDP, so each stream is independent and a loss affects only itself; 0-RTT setup is also faster.

Two reminders

1. Not a cure-all: a slow app layer is not fixed by a protocol change;
2. TLS required: browsers basically require HTTPS for HTTP/2 and HTTP/3.

Migration and canary validation

1. HTTPS everywhere first: browsers negotiate HTTP/2 essentially only over TLS, so a partial HTTPS rollout blocks the upgrade;
2. Enable ALPN with a fallback: advertise h2 alongside http/1.1 so old clients fall back cleanly, and keep a TCP fallback for HTTP/3;
3. Roll out gradually: start with internal traffic and a small percentage of users, watching error rates, handshake time and fallback share before widening;
4. Revisit old optimisations: evaluate domain sharding, sprite sheets and file concatenation one by one, many are now a burden under HTTP/2;
5. Verify with numbers: compare connection count, TLS handshake time, TTFB and first-paint asset racing before and after rather than judging by feel.

Remember that a protocol upgrade does not fix application problems: slow server rendering or slow queries still dominate TTFB.