HTTP/2
HTTP/2 is a major revision of HTTP that improves performance through multiplexing, header compression, and stream prioritization over a single connection.
§ 1 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.
§ 2 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.
§ 3 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.
§ 4 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.
§ 5 Note
§ 6 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.
- 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.
Atomic Glue ensures your site is served over HTTP/2 (and HTTP/3) with proper TLS and CDN configuration. Performance optimization is part of every build.
Get in touchHTTP/2 is a major revision of HTTP that improves performance through multiplexing, header compression, and stream prioritization over a single connection.
Category: Web Development (also: Performance, Infrastructure)
Author: Atomic Glue Team
## 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](/glossary/http3) 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.
## Related entries
- [HTTP](atomicglue.co/glossary/http)
- [HTTP/3](atomicglue.co/glossary/http3)
- [HTTPS](atomicglue.co/glossary/https)
- [TLS/SSL](atomicglue.co/glossary/tls-ssl)
Last updated June 2026. Permalink: atomicglue.co/glossary/http2