HTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC) for Frontend Performance
Learn the interview-ready mental model, practical trade-offs, and production patterns for this web fundamentals topic.
Topic content
HTTP evolution addresses network inefficiencies that affect frontend performance. HTTP/1.1 relies on multiple TCP connections. HTTP/2 introduces multiplexing over a single connection. HTTP/3 replaces TCP with QUIC (UDP-based), eliminating head-of-line blocking, improving loss recovery, and enabling seamless connection migration — especially valuable on mobile networks.
HTTP/1.1 = many small trucks, each making separate trips (high overhead). HTTP/2 = one big truck carrying everything but stuck in traffic if one box is missing (HoL blocking). HTTP/3 (QUIC) = many smart drones that can reroute independently when one is delayed.
HTTP/1.1
Multiple TCP Connections
HTTP/2
Multiplexed Streams (TCP HoL)
HTTP/3
Independent QUIC Streams
1HTTP/1.1
Uses multiple parallel TCP connections per origin. Suffers from repeated handshakes, slow-start penalties, and connection limits. Inefficient for modern pages with many assets.
Connection 1: index.html Connection 2: style.css Connection 3: script.js ... (up to browser limit)
2HTTP/2
Single TCP connection with multiplexing, header compression (HPACK), and server push. Still limited by TCP head-of-line blocking on packet loss.
3HTTP/3 (QUIC)
Runs over UDP. Independent streams, faster handshake, built-in encryption, better loss recovery, and connection migration. Ideal for mobile and unstable networks.
- ✓HTTP/1.1: Multiple connections, high overhead
- ✓HTTP/2: Multiplexing over TCP, better bandwidth use
- ✓HTTP/3 (QUIC): Independent streams, no HoL blocking, fast recovery
- ✓Mobile networks benefit most from QUIC's connection migration
- ✓Protocol improvements amplify good frontend practices but don't replace them
- ✓Always validate with real-user metrics (LCP, INP, resource timing)