HTTP/1.1 was the web's protocol for two decades. HTTP/2 (2015) and HTTP/3 (standardized 2022) brought significant changes — multiplexing, header compression, QUIC. The performance gains are real for typical web traffic.
This page covers what changed and the practical impact.
The problems HTTP/2 was designed to solve:
HTTP/1.1 sends requests one at a time per connection. A slow request blocks subsequent ones.
Browser workaround: open 6 connections per origin in parallel. Better than 1, but each connection has its own TCP overhead.
Headers are repeated on every request. For APIs sending small JSON responses, headers dominate.
Easy to debug; less efficient on the wire.
The major changes:
One TCP connection per origin. Multiple requests/responses in parallel over that connection.
Connection 1
├── Stream 1: GET /index.html
├── Stream 3: GET /style.css
├── Stream 5: GET /app.js
└── Stream 7: GET /image.png
Each stream is independent. Slow image doesn't block fast JS.
Common headers are sent once and referenced by index. Big savings on header-heavy traffic.
The protocol is binary instead of text. More compact; less ambiguous.
Server can push resources the client will need. Largely deprecated — performance benefits didn't materialize; adds complexity.
Streams have priorities; servers can serve high-priority first. Helps render-blocking resources.
The remaining problem: HTTP/2 multiplexes over one TCP connection. If TCP needs to retransmit a packet, all streams pause until retransmission. "TCP head-of-line blocking" — solved by HTTP/3.
QUIC is a new transport protocol (UDP-based) that replaces TCP for HTTP/3.
QUIC has its own stream concept independent of underlying packets. A lost packet only affects its stream, not all of them.
TLS 1.3 is integrated; the handshake is faster than TLS over TCP.
A QUIC connection is identified by a connection ID, not by IP/port. Mobile clients switching networks (WiFi → cellular) keep the connection alive.
Repeat connections can include data on the first packet, eliminating the handshake round-trip.
HTTP/2 vs. HTTP/1.1: noticeable improvement for pages with many resources. Most sites use HTTP/2 today.
HTTP/3 vs. HTTP/2: marginal improvement for most pages. More benefit on lossy networks (mobile).
HTTP/1.1 vs. HTTP/2: HTTP/2 wins if you make many parallel requests. For sequential request/response patterns, less benefit.
For HTTP/2 APIs, gRPC builds on HTTP/2 and benefits from multiplexing.
HTTP/3's stream-isolation matters more. SSE, WebSocket-over-HTTP/3, and streaming use cases benefit.
HTTP/3's resilience to packet loss is a real win. Mobile users on weak signals see better performance.
HTTP/2 in browsers requires TLS. Plain HTTP/2 (no TLS) is allowed by spec but browsers don't implement it. So HTTPS is implicit for HTTP/2 web traffic.
HTTP/3 is always encrypted (TLS 1.3 baked in).
For external-facing traffic, HTTP/2 is the default; HTTP/3 is increasing adoption. For internal traffic, HTTP/1.1 is fine.