HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1: The Workhorse with Limitations

HTTP/1.1 was standardized in 1997 and remained the dominant web protocol for nearly two decades. It introduced persistent connections — keeping the TCP connection open across multiple requests instead of closing it after every response — and chunked transfer encoding for streaming responses. For the web of the late 1990s, these were meaningful improvements over HTTP/1.0.

But HTTP/1.1 has a fundamental limitation: only one request can be in flight per connection at a time. A browser loading a modern web page needs dozens of resources — HTML, CSS, JavaScript files, images, fonts, API calls. With HTTP/1.1, each resource must wait for the previous one to complete before being requested on that connection.

Browsers worked around this by opening multiple parallel TCP connections to the same server — typically six per origin. This helped throughput, but each connection required its own TCP handshake and TLS negotiation, adding latency. Headers were sent as uncompressed plaintext with every request, often repeating the same Cookie, User-Agent, and Accept headers hundreds of times per session. Pipelining — sending multiple requests before receiving responses — was defined in HTTP/1.1 but proved unreliable in practice and was never widely adopted.

HTTP/2: Multiplexing Over TCP

HTTP/2, standardized in 2015 and based on Google's SPDY protocol, solved HTTP/1.1's core performance problem with a single fundamental change: multiplexing. Instead of one request per connection, HTTP/2 breaks messages into binary frames and interleaves multiple request/response exchanges simultaneously on a single TCP connection. A slow response no longer blocks everything behind it — the connection is shared, not queued.

HTTP/2 also introduced HPACK header compression, which dramatically reduces the overhead of repeated headers. After the first request, only headers that have changed need to be transmitted; common headers like User-Agent and Accept-Encoding are referenced from a shared compression table. A site making 100 requests per page load saves substantial bandwidth.

Server push was another HTTP/2 feature: the server could proactively send resources it knew the client would need (like a stylesheet referenced in the HTML) without waiting for the client to ask. In practice, server push was difficult to implement correctly and has been removed or deprecated in most implementations.

HTTP/2 has one remaining weakness: it runs over TCP, and TCP-level head-of-line blocking still applies. If a single TCP packet is lost, all HTTP/2 streams stall — even streams that have already received their data — until the lost packet is retransmitted. On networks with packet loss, HTTP/2 can actually perform worse than HTTP/1.1 with multiple connections, because HTTP/1.1's parallel connections are not all affected by the same packet loss.

HTTP/3: Moving to QUIC/UDP

HTTP/3, standardized in 2022, solves TCP's head-of-line blocking by abandoning TCP entirely. It runs over QUIC, a transport protocol built on UDP that implements its own reliable delivery per stream. When a packet is lost, only the stream that needed that packet stalls — all other streams continue unaffected.

QUIC also integrates TLS 1.3 directly into the protocol, reducing connection setup time. A new QUIC connection to a known server can complete in a single round trip (1-RTT), and for repeat connections with session resumption, data can begin flowing with zero additional round trips (0-RTT). Compare this to HTTP/2 over TCP+TLS 1.2, which required two round trips just for the handshakes before any HTTP data could be sent.

QUIC also supports connection migration: if your phone switches from Wi-Fi to cellular, QUIC can maintain the logical connection using a connection ID rather than a source IP/port tuple. A TCP connection would break and need to be re-established from scratch.

Version Comparison

Does HTTP Version Actually Affect Your Speed?

Yes, measurably — but the impact depends on your network conditions and what you are loading. On a fast, low-loss connection, the difference between HTTP/2 and HTTP/3 is small. The gains from HTTP/2 over HTTP/1.1 are more consistently visible: eliminating the overhead of six parallel TCP connections and compressing headers reduces both latency and bandwidth on nearly every page load.

HTTP/3's advantages become significant on mobile networks and high-latency or lossy connections. If you are on a cellular network with 2–5% packet loss, HTTP/2's TCP transport stalls frequently. HTTP/3's per-stream loss isolation means individual stream delays do not cascade across the page load. Connection migration also matters for mobile users who regularly switch between Wi-Fi and cellular mid-session.

For a developer, the practical implication is: use a CDN or hosting provider that supports HTTP/2 at minimum, and check whether HTTP/3 is available. The protocol is negotiated automatically between client and server — users do not configure it. You can verify which version is being used in your browser's developer tools Network tab by looking at the Protocol column.

Frequently Asked Questions

What is head-of-line blocking?

Head-of-line blocking occurs when a stalled or lost packet prevents all subsequent data from being delivered, even if that later data has already arrived. In HTTP/1.1, a slow response blocks subsequent requests on the same connection. In HTTP/2, multiplexing solved this at the HTTP layer, but a single lost TCP packet still stalls all streams. HTTP/3 on QUIC eliminates this because each stream is independently flow-controlled.

Does HTTP/2 require HTTPS?

Technically no — the HTTP/2 specification allows unencrypted connections (h2c). In practice, yes — every major browser only implements HTTP/2 over TLS. If you want HTTP/2 in a real browser, your site must use HTTPS. Servers negotiate HTTP/2 using the TLS ALPN extension during the handshake.

What transport does HTTP/3 use?

HTTP/3 runs over QUIC, which is built on UDP rather than TCP. QUIC implements its own reliable delivery, congestion control, and built-in TLS 1.3 encryption. Moving to UDP allows QUIC to avoid TCP's head-of-line blocking and enables faster connection establishment.

How do I know which HTTP version a site uses?

Open your browser's developer tools, go to the Network tab, and reload the page. Look for the Protocol column — it shows h1 for HTTP/1.1, h2 for HTTP/2, or h3 for HTTP/3. You may need to right-click the column headers to make the Protocol column visible.

Is HTTP/3 widely supported?

Yes. All major browsers support HTTP/3 as of 2026. Major CDNs including Cloudflare, Fastly, and Akamai support it. Google, Meta, and Cloudflare serve significant portions of their traffic over HTTP/3. Server-side support varies, but cloud load balancers commonly handle QUIC termination at the edge.

What is multiplexing in HTTP/2?

Multiplexing in HTTP/2 means multiple requests and responses can be sent simultaneously over a single TCP connection, interleaved at the binary frame level. In HTTP/1.1, only one request could be in flight per connection at a time. HTTP/2 multiplexing eliminated the need to open multiple parallel connections to load a page quickly.