Understanding HTTP/2 and HTTP/3: What Changed and Why

HTTP/2 and HTTP/3 fundamentally changed how browsers communicate with servers. Every frontend developer should understand these protocols.

HTTP/1.1 Problems

• Head-of-line blocking: One slow response blocks all others on the connection
• 6 connection limit: Browsers open max 6 TCP connections per domain
• Header redundancy: Full headers sent with every request
• No prioritization: Can't tell the server which resources are most important

HTTP/2 Solutions

Multiplexing

Multiple requests and responses share a single TCP connection, interleaved as binary frames. No more domain sharding hacks.

Header Compression (HPACK)

Headers are compressed and cached. Repeated headers (Cookie, User-Agent) are sent as small indices instead of full strings.

Server Push

Server can proactively send resources before the client requests them. However, this has been largely deprecated because browsers couldn't efficiently use pushed resources.

Stream Prioritization

Client can hint which resources are most important. Critical CSS and JS get priority over images.

HTTP/2 Still Has a Problem

HTTP/2 solved HTTP-level head-of-line blocking but runs on TCP. TCP treats all streams as one — a single packet loss blocks ALL streams (TCP head-of-line blocking).

HTTP/3: QUIC Protocol

HTTP/3 replaces TCP with QUIC (built on UDP). Each stream is independent — packet loss in one stream doesn't affect others.

Additional Benefits

• 0-RTT connection: Return visitors connect instantly (vs 2-3 RTT for TCP+TLS)
• Connection migration: Switching networks (WiFi→cellular) doesn't drop the connection
• Built-in encryption: TLS 1.3 is mandatory, not optional

What This Means for Frontend

• Stop concatenating files — multiplexing handles many small files efficiently
• Stop domain sharding — one connection is better with HTTP/2
• Use 103 Early Hints instead of Server Push
• Preload critical resources with <link rel="preload">