HTTP/2

HTTP/2 is a major revision of HTTP that improves performance through multiplexing, header compression, and stream prioritization over a single connection.

Definition

HTTP/2 is the second major version of the HTTP protocol, standardized in 2015 as RFC 7540 (later superseded by RFC 9113). It addresses the biggest performance problem with HTTP/1.1: head-of-line blocking at the application layer. In HTTP/1.1, each TCP connection could process one request at a time. Loading a page with 100 resources required either 100 sequential round trips or 6+ parallel connections (browser connection limits). HTTP/2 multiplexes multiple streams over a single TCP connection. Multiple requests and responses can be in flight simultaneously without blocking each other. HTTP/2 also compresses headers using HPACK (often reducing header overhead by 80% or more), supports server push (though browsers are deprecating this), and allows stream prioritization. HTTP/2 does not change HTTP semantics. The methods, status codes, URIs, and headers are the same. HTTP/2 changes only the framing and transport layer. Most modern web servers and CDNs support HTTP/2. If your site is not on HTTP/2, you are leaving performance gains on the table.

How it works

The client and server negotiate HTTP/2 during the TLS handshake via ALPN (Application-Layer Protocol Negotiation). HTTP/2 introduces binary framing (not text like HTTP/1.1). Streams within the connection carry frames of different types: HEADERS, DATA, SETTINGS, PRIORITY, GOAWAY. Multiple streams are interleaved at the frame level, so a large response on one stream does not block others. Each stream has a priority weight, helping the server allocate bandwidth.

Performance impact

HTTP/2 dramatically improves page load times for resource-heavy pages. It eliminates the need for domain sharding (splitting resources across multiple domains to bypass browser connection limits). It reduces the overhead of connection establishment. Combined with TLS, HTTP/2 benefits from a single negotiated connection with session resumption. Server push was originally touted as a major feature but proved impractical and is being removed from Chrome.

Common misconception

HTTP/2 does not make every site faster. For simple sites with few resources, the benefits are minimal. HTTP/2 also suffers from TCP-level head-of-line blocking (if a TCP packet is lost, all streams are delayed). This is why HTTP/3 uses QUIC over UDP instead of TCP.

Note

HTTP/2 requires TLS in practice (browsers only support HTTP/2 over TLS). Ensure your server and CDN support TLS 1.2 or higher with ALPN for HTTP/2 negotiation. Check your site's HTTP protocol with browser DevTools under the Network tab.

Common questions

Q: Do I need to change my code for HTTP/2?

A: No. HTTP/2 is transparent to application code. You may need to remove HTTP/1.1 optimizations like domain sharding and image spriting.

Q: Is HTTP/2 faster than HTTP/1.1?

A: For multiplexed resource loading, yes significantly. For single-request APIs, the difference is negligible.

Key takeaways:

• HTTP/2 multiplexes multiple streams over one TCP connection, eliminating head-of-line blocking.

• Header compression (HPACK) reduces overhead by up to 80%.

• HTTP/2 is transparent to applications but requires TLS in practice.