HTTP/2 is the second major version of the HTTP protocol, the communication standard that governs how browsers and web servers exchange data. Released as a formal standard in 2015 HTTP/2 introduced fundamental changes to how HTTP requests and responses are transmitted, addressing performance limitations that had accumulated in HTTP/1.1 over its nearly two decades of dominant use. The core changes, multiplexing, header compression, server push, and binary framing, deliver measurably faster page load times particularly for pages that load many resources from the same server.

HTTP/2 maintains complete backward compatibility with the semantics of HTTP/1.1, the same HTTP methods, status codes, and headers work identically. The change is in how the protocol transmits data, the wire format, rather than in what the protocol communicates. A web application that works over HTTP/1.1 works over HTTP/2 without any changes to the application code. The performance improvements come from the protocol layer beneath the application.

The most practically significant aspect of HTTP/2 from a deployment perspective is its requirement for HTTPS in all major browser implementations. While the HTTP/2 specification technically allows unencrypted HTTP/2, called h2c, no major browser supports unencrypted HTTP/2 in practice. Deploying HTTP/2 for browser traffic requires TLS: making HTTPS a prerequisite for HTTP/2’s performance benefits. This de facto requirement has been one of the additional incentives driving HTTPS adoption across the web.

The problems HTTP/2 solved

Understanding HTTP/1.1’s limitations clarifies what HTTP/2 was designed to address and why the improvements matter for web performance.

HTTP/1.1 head-of-line blocking: HTTP/1.1 is fundamentally sequential within a TCP connection. One request must receive a complete response before the next request can be sent on the same connection, a limitation called head-of-line blocking. If a large resource is loading slowly it blocks all subsequent requests on that connection even if those resources would load quickly.

Browsers work around HTTP/1.1 head-of-line blocking by opening multiple parallel TCP connections to the same server, typically six connections per domain. This parallelism enables concurrent resource loading but has its own costs, each TCP connection requires its own setup overhead, its own TLS handshake, and its own congestion control state. Six connections per domain for a page loading resources from five domains means up to 30 TCP connections, significant overhead.

HTTP/1.1 header repetition: HTTP/1.1 headers are sent as plaintext with every request and response, including headers that are identical across many requests. The User-Agent, Accept, Accept-Language, Cookie, and many other headers repeat on every request. For a page loading 100 resources from the same server the same headers are transmitted 100 times, wasteful redundancy that inflates the total data transferred.

The web’s evolution beyond HTTP/1.1’s design: HTTP/1.1 was designed when web pages were simpler, fewer resources, smaller assets, less JavaScript. Modern web pages may load dozens to hundreds of resources, scripts, stylesheets, images, fonts, API responses. HTTP/1.1’s sequential request model was not designed for this scale of resource loading.

Various HTTP/1.1 workarounds, domain sharding to multiply the six-connection-per-domain limit, CSS sprites to reduce image request counts, JavaScript bundling to reduce script request counts, were developed specifically to compensate for HTTP/1.1’s limitations. These workarounds add complexity to the development and build process. HTTP/2 makes most of them unnecessary.

HTTP/2 key features

HTTP/2 addresses HTTP/1.1’s limitations through several interconnected features that together transform how HTTP communication works.

Binary framing layer: HTTP/1.1 is a text-based protocol, requests and responses are transmitted as human-readable text. HTTP/2 introduces a binary framing layer that encodes all communication in binary frames rather than text. Binary encoding is more efficient to parse and less error-prone than text parsing. The binary framing layer enables all of HTTP/2’s other features, multiplexing, header compression, and flow control are all implemented through the binary frame structure.

HTTP frames carry a type identifier, DATA, HEADERS, SETTINGS, PING, GOAWAY, WINDOW_UPDATE, PUSH_PROMISE, and others, and a stream identifier that associates the frame with a specific request-response exchange. The stream concept is central to HTTP/2’s multiplexing capability.

Multiplexing: the most impactful HTTP/2 feature. HTTP/2 allows multiple request-response exchanges, called streams, to be in flight simultaneously over a single TCP connection. Streams are multiplexed, interleaved within the same connection using stream identifiers in each frame. A DATA frame for stream 3 can be sent between HEADERS frames for stream 7, the browser and server maintain separate state for each stream and reassemble the frames into complete responses.

Multiplexing eliminates HTTP/1.1’s head-of-line blocking at the HTTP level. A large resource loading slowly on stream 3 does not block small resources on streams 5, 7, and 9, those streams receive their responses while stream 3 continues. The browser needs only one TCP connection per server rather than six, connection setup and TLS handshake overhead is paid once rather than six times.

For redirect management multiplexing means that when a browser receives a redirect response and needs to load the redirect destination’s resources all those resource requests can share a single TCP connection, reducing connection establishment overhead for pages that load many resources.

Header compression, HPACK: HTTP/2 uses a compression algorithm called HPACK specifically designed for HTTP header compression. HPACK maintains a dynamic table of previously transmitted headers on both the client and server sides. When a header that was previously transmitted appears in a new request it can be referenced by its table index, a single byte or two bytes, rather than being retransmitted in full.

For requests that share many headers, most requests to the same server share User-Agent, Accept, Cookie, and other headers, HPACK dramatically reduces header overhead. After the initial requests establish the dynamic table subsequent requests may transmit only the headers that differ from previous requests, often just the method and path.

Server push: HTTP/2 allows servers to proactively send resources to the client before the client requests them, server push. When a browser requests an HTML page the server can push the CSS and JavaScript that will be needed to render the page alongside the HTML response, anticipating the browser’s next requests. The browser receives the resources and caches them, when it parses the HTML and discovers the CSS and JavaScript links it finds them already available in the cache.

Server push has seen limited adoption in practice, it requires the server to correctly predict what the client will need, and incorrect push wastes bandwidth sending resources the client already has cached. Many HTTP/2 deployments do not use server push and its effectiveness varies significantly by use case. The HTTP/3 successor has moved away from server push in favour of other mechanisms.

Stream prioritisation: HTTP/2 allows clients to indicate the relative priority of streams, instructing the server to send higher-priority resources before lower-priority ones. A browser can indicate that the CSS stylesheet blocking page rendering has higher priority than below-the-fold images, the server allocates bandwidth accordingly. Stream prioritisation enables optimised resource delivery ordering for faster perceived page load times.

HTTP/2 and HTTPS

The practical requirement for HTTPS with HTTP/2 deserves specific attention, it is the most immediately relevant HTTP/2 characteristic for web infrastructure configuration.

The specification vs browser reality: the HTTP/2 RFC does not require TLS. It defines two variants, h2 for HTTP/2 over TLS and h2c for HTTP/2 over cleartext TCP. The specification was intentionally agnostic about TLS to avoid conflating protocol design with security policy.

However all major browser vendors, Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, decided independently to implement only h2, HTTP/2 over TLS, not h2c. No major browser supports HTTP/2 over unencrypted connections. This decision reflects the browsers’ position that new protocol features should not be available without the security baseline that TLS provides.

HTTPS as prerequisite for HTTP/2 performance: since browsers only use HTTP/2 over TLS a site that serves HTTP without HTTPS receives only HTTP/1.1 connections from browsers regardless of whether the server supports HTTP/2. Deploying HTTP/2 to get its performance benefits requires deploying HTTPS first. This coupling has been a significant motivator for HTTPS adoption, organisations that might not have prioritised HTTPS for security reasons were incentivised by the HTTP/2 performance benefits.

ALPN, Application-Layer Protocol Negotiation: HTTP/2 over TLS is negotiated through a TLS extension called ALPN, Application-Layer Protocol Negotiation. During the TLS handshake the client sends a list of supported application protocols, typically h2 for HTTP/2 and http/1.1 for HTTP/1.1 fallback. The server selects the best mutually supported protocol and includes its choice in the TLS handshake. After the handshake completes both parties know which protocol version to use for the connection.

ALPN negotiation happens within the TLS handshake, no additional round trips are needed to negotiate the protocol. The protocol selection is complete by the time the first HTTP request can be sent.

HTTP/2 and redirects

HTTP/2 changes how redirects behave and perform in several specific ways, all generally positive from a performance perspective.

Redirect responses over HTTP/2: HTTP redirects work identically over HTTP/2 and HTTP/1.1, the same 3xx status codes, the same Location header, the same browser behaviour of following the redirect. The difference is in the efficiency of the redirect response delivery, over HTTP/2 the redirect response is a binary-framed message that benefits from HPACK header compression and multiplexing.

Connection reuse for same-origin redirects: when a redirect sends the browser to the same origin, same domain and port, the existing HTTP/2 connection can be reused for the follow-up request. The browser does not need to establish a new connection to follow the redirect, the TCP connection and TLS session are already established. This makes same-origin redirects significantly cheaper in terms of connection overhead than cross-origin redirects.

Redirect chains and HTTP/2: redirect chains: multiple sequential redirects before reaching the final destination, are still problematic over HTTP/2. Each hop in the chain requires a request-response cycle, even with multiplexing each hop is a sequential step that adds latency. HTTP/2 improves the efficiency of each hop but does not eliminate the fundamental latency cost of multiple hops. Minimising redirect chains remains a performance best practice regardless of HTTP version.

Cross-origin redirect connection overhead: when a redirect sends the browser to a different domain a new TCP connection and TLS handshake are required, the browser cannot reuse the connection from the redirect source. HTTP/2 reduces this to one connection rather than potentially six, and TLS 1.3’s one round trip handshake minimises the connection establishment overhead, but the overhead still exists. Redirect chains crossing multiple domains accumulate this overhead at each hop.

HTTP/2 deployment

HTTP/2 is now the default for most modern web infrastructure, most browsers, servers, CDNs, and hosting platforms support HTTP/2 without special configuration.

Server support: major web servers have supported HTTP/2 for years. Nginx has supported HTTP/2 since version 1.9.5. Apache supports HTTP/2 through the mod_http2 module available since version 2.4.17. Caddy supports HTTP/2, and HTTP/3, automatically with no configuration required. Node.js has built-in HTTP/2 support. IIS supports HTTP/2 on Windows Server 2016 and later.

CDN support: all major CDNs support HTTP/2 and typically enable it by default. Cloudflare, Fastly, Akamai, AWS CloudFront, and Google Cloud CDN all support HTTP/2 on their edge networks. CDN-fronted sites automatically benefit from HTTP/2 for client-to-edge connections regardless of the origin server’s HTTP/2 support.

Hosting platform support: modern hosting platforms, Vercel, Netlify, Heroku, Railway, and others, support HTTP/2 by default for all hosted sites. No configuration is needed to enable HTTP/2 on these platforms.

Checking HTTP/2 support: the HTTP version used for a connection is visible in browser developer tools. The Network tab shows the protocol column, h2 for HTTP/2, http/1.1 for HTTP/1.1. The Security tab shows the TLS details including the negotiated ALPN protocol. Online tools, HTTP/2 Test at tools.keycdn.com/http2-test: check whether a domain supports HTTP/2 from external perspectives.

HTTP/2 vs HTTP/3

HTTP/2 addressed HTTP/1.1’s limitations but introduced its own limitation, TCP head-of-line blocking. While HTTP/2’s multiplexing eliminates HTTP-level head-of-line blocking within a single TCP connection TCP-level head-of-line blocking remains. If a TCP packet is lost all streams on the connection stall until the packet is retransmitted and received, HTTP/2 multiplexing cannot help because the issue is at the transport layer below HTTP.

HTTP/3: standardised in 2022, addresses this by replacing TCP with QUIC, a transport protocol built on UDP that provides multiplexing at the transport layer without head-of-line blocking. HTTP/3 provides all of HTTP/2’s benefits plus elimination of TCP head-of-line blocking, particularly valuable on unreliable network connections where packet loss is more common.

HTTP/2 remains widely used, it is well-supported, well-understood, and delivers significant performance improvements over HTTP/1.1. HTTP/3 is increasingly deployed alongside HTTP/2, servers and CDNs support both and negotiate the appropriate version based on client capability. HTTP/2 is not being replaced by HTTP/3 rapidly, both coexist as the web infrastructure evolves.