HTTP/2

HTTP/2 is the second major version of the HTTP protocol, published in 2015 (RFC 7540) and based on Google's earlier SPDY protocol. It preserves the same semantics as HTTP/1.1 — the same methods, status codes and headers — but completely changes how data is transmitted in order to speed up modern, complex web pages.

How HTTP/2 works

The key innovation is multiplexing — many requests and responses can travel in parallel over a single TCP connection. In HTTP/1.1 the browser had to open several separate connections and suffered from head-of-line blocking, where one slow resource held up the others. HTTP/2 solves this at the application level. Its other improvements include:

• Header compression (HPACK) — cuts the repetitive metadata overhead in every request.
• Stream prioritization — the browser signals which resources matter most.
• Binary framing — data is split into frames, which is more efficient and less error-prone than the text-based HTTP/1.1.

The result is faster page rendering and a lower TTFB, which translates directly into better Core Web Vitals scores.

Practical application

HTTP/2 is now widely supported by Apache, Nginx and LiteSpeed servers and by CDNs, and enabling it usually comes down to server configuration and having an HTTPS certificate. Because multiplexing removes the cost of many connections, old HTTP/1.1-era optimization techniques — concatenating CSS/JS files or sharding resources across multiple domains — lose their point or become counterproductive. The next step in the protocol's evolution is HTTP/3, which moves transport from TCP to the QUIC protocol.

It's worth noting one limitation: HTTP/2 multiplexing works at the application level but still runs over a single TCP connection. Losing one packet then stalls data delivery across all streams — the so-called transport-level head-of-line blocking. In networks with high packet loss this issue is only resolved by HTTP/3, which makes the two versions complementary steps on the road to a faster web.