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.

Real-world cases: why the upgrade did not speed things up

1. Still domain-sharding: HTTP/1.1 sharding worked around the six-connection limit per host; under HTTP/2 extra domains just mean extra handshakes. Consolidate back onto one host after upgrading.
2. Bundling JS / CSS into one giant file: HTTP/2 multiplexes, so splitting by route and component improves cache hit rates while the first paint needs only a few critical assets.
3. QUIC blocked by the network: HTTP/3 uses UDP 443, which some corporate networks and older middleboxes drop, so clients fall back to TCP with an extra delay. Keep the HTTP/2 fallback and monitor the fallback rate.

FAQ

Does HTTP/2 still head-of-line block? At the TCP layer yes — one lost packet stalls every stream on the connection; HTTP/3 over QUIC removes transport-level head-of-line blocking. Does HTTP/2 need its own certificate? No, it shares the HTTPS certificate; negotiation happens via ALPN. Is server push still used? Mainstream browsers removed it; preload and 103 Early Hints are the practical alternative. Which metrics prove the upgrade? Connection count, TLS handshake time, time to first byte and first-paint asset racing — not the download speed of a single file.

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.

Working with frontend bundling strategy

1. Split by route, not by type: create an entry plus on-demand chunks so first paint loads only what it needs, improving cache hits and avoiding one giant file.
2. Layer by change frequency: third-party dependencies change rarely and business code often, so splitting them lets users download only the business chunk on release.
3. Reveal critical assets early: declare the styles and scripts needed for first paint so the browser does not wait to parse the HTML before requesting them.
4. Avoid excessive requests: multiplexing lowers concurrency cost, but every request still carries headers and processing — dozens of tiny files rarely beat moderate bundling; decide by measurement.
5. Measure real users: lab data reflects an ideal network; use field metrics, especially first paint on mobile, to judge the benefit.

The protocol upgrade offers possibilities; what actually decides experience is how you organise assets and prioritise the critical path.