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 Hintsinstead of Server Push - Preload critical resources with
<link rel="preload">