HTTP/1.1 vs HTTP/2 — What Actually Changed?
HTTP/1.1 has been the backbone of the web since 1997. It works, but it has some fundamental performance bottlenecks that HTTP/2 was designed to solve.
The Problem with HTTP/1.1
In HTTP/1.1, each request-response pair blocks the connection. If you need 10 resources, the browser either waits for each one sequentially or opens multiple TCP connections (typically 6 per domain). This is called head-of-line blocking.
Developers worked around this with hacks like domain sharding, sprite sheets, and inlining CSS — all to reduce the number of requests.
What HTTP/2 Fixes
Multiplexing — Multiple requests and responses travel over a single TCP connection simultaneously. No more head-of-line blocking at the HTTP layer. The browser can request all 10 resources at once over one connection.
Header Compression (HPACK) — HTTP/1.1 sends headers as plain text on every request, often repeating the same cookies and user-agent strings. HTTP/2 compresses headers using HPACK, which uses Huffman encoding and a shared header table. This can reduce header overhead by 85-90%.
Binary Framing — HTTP/1.1 is text-based. HTTP/2 uses a binary framing layer that's more efficient to parse and less error-prone. Each message is split into small frames that can be interleaved on the connection.
Stream Prioritization — The client can signal which resources matter most. CSS and JS can be prioritized over images, so the page renders faster.
Server Push — The server can proactively send resources it knows the client will need. If the browser requests index.html, the server can push style.css along with it before the browser even asks. (Though in practice, this feature is rarely used and was removed in HTTP/3.)
Quick Comparison
| Feature | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Connections per domain | ~6 | 1 |
| Request handling | Sequential | Multiplexed |
| Headers | Plain text, repeated | Compressed (HPACK) |
| Protocol format | Text | Binary |
| Prioritization | None | Stream weights |
| Server push | No | Yes |
The Catch
HTTP/2 still runs over TCP, which means TCP-level head-of-line blocking is still a thing. If a single packet is lost, all streams on that connection stall until it's retransmitted. This is exactly what HTTP/3 (built on QUIC/UDP) solves — but that's a topic for another post.
Bottom Line
HTTP/2 made the web significantly faster by fixing the protocol-level inefficiencies of HTTP/1.1. Most of the old performance hacks (domain sharding, concatenation, spriting) are no longer necessary. If your server supports it, there's no reason not to use HTTP/2 — it's backwards compatible and requires zero changes to your application code.