HTTP/2 (Hypertext Transfer Protocol 2)

HTTP/2 (Hypertext Transfer Protocol version 2) is a major revision of HTTP, the protocol browsers and servers use to exchange web pages, standardized in 2015. Its purpose is speed. The previous version, HTTP/1.1, handled requests largely one at a time per connection, so a page with many resources — images, scripts, stylesheets — suffered delays as requests queued and browsers opened multiple connections to compensate. HTTP/2 fixes much of this with multiplexing, which lets many requests and responses travel over a single connection at the same time rather than waiting in line. It adds header compression, which shrinks the repetitive metadata sent with every request, and it introduced server push, a way for a server to send resources before the browser asks. The result is that a typical page, with its many small files, loads faster over HTTP/2 than over HTTP/1.1, without the developer having to change the page itself.

HTTP/2 matters to marketers because it improves page-load speed, and page speed affects user experience, Core Web Vitals, bounce, conversion, and SEO. Most of the benefit is automatic: when a site and its server support HTTP/2, browsers use it and the page simply loads faster, especially pages with many resources. That makes enabling HTTP/2 one of the lower-effort technical wins available — it requires server support and HTTPS, not a rebuild of the site. For a growth team, the relevance is that the protocol layer underneath the site quietly shapes how fast pages feel, and HTTP/2 is the baseline modern web protocol that captured much of the available speed gain over the old HTTP/1.1 model. It is worth knowing the site runs on it, even if engineers handle the details.

HTTP/2's gains are clearest against HTTP/1.1, the version it replaced for most traffic. Under HTTP/1.1, a connection handled requests serially, so browsers opened several connections per site and pages with many resources stalled in queues. HTTP/2 multiplexes those requests over one connection, compresses headers, and removed much of that queuing, so the same page loads faster with less overhead. The improvement is largely transparent — the page's HTML and assets do not change, but they arrive more efficiently. This is why HTTP/2 became the modern default: it captured a large, low-effort speed gain simply by changing how requests travel, not what is sent. For most sites, moving from HTTP/1.1 to HTTP/2 is a clear win in delivery efficiency and perceived speed.

HTTP/2 must also be distinguished from its successor, HTTP/3, because they solve different remaining problems. HTTP/2 multiplexes streams over a single TCP connection, but TCP itself can stall all of those streams when a single packet is lost — a problem called head-of-line blocking at the transport layer. HTTP/3 addresses this by running over QUIC, a UDP-based transport, so a lost packet affects only its own stream rather than freezing them all, and it reduces connection-setup latency. So HTTP/2 fixed the application-layer queuing of HTTP/1.1, while HTTP/3 fixes the transport-layer blocking that HTTP/2 still inherits from TCP. The progression is HTTP/1.1 to HTTP/2 to HTTP/3, each removing a further source of delay. HTTP/2 remains widely used and beneficial; HTTP/3 is the next step where it is supported.

Using HTTP/2 well mostly means making sure your site actually serves over it — which requires modern server or CDN support and HTTPS — and then verifying that it is enabled, since the speed benefit comes automatically once it is. It also means revisiting old HTTP/1.1-era performance hacks: techniques like sharding resources across many domains or bundling everything into giant files were workarounds for HTTP/1.1's serial connections, and under HTTP/2's multiplexing some of them no longer help and can even hurt. The right approach is to let HTTP/2 do its job, keep pages reasonably lean, and measure real load times. For a growth team, the practical move is to confirm the protocol is in use, drop the obsolete workarounds, and treat HTTP/2 as the modern baseline that quietly improves the speed metrics tied to experience and SEO.

The failures are assuming a site uses HTTP/2 without checking (it needs server support and HTTPS), keeping HTTP/1.1-era workarounds like domain sharding that can be counterproductive under HTTP/2, over-relying on server push (which proved tricky and is being deprecated in places) rather than sound resource loading, and treating the protocol as a substitute for actually lean pages. The discipline is to enable and verify HTTP/2, retire the old hacks it makes obsolete, keep pages efficient, and understand it as the transparent delivery upgrade over HTTP/1.1 — with HTTP/3 the further step beyond it — so the protocol layer supports page speed rather than being left to chance.

HTTP/2 (Hypertext Transfer Protocol version 2) — a 2015 revision adding multiplexing and header compression over one connection — speeds page loads over HTTP/1.1, with HTTP/3 the next step beyond it.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where http/2 (hypertext transfer protocol 2) is a core concern: