What Are HTTP/2 and HTTP/3, and Why They Matter for Speed

Every time a browser loads your site, it speaks a protocol called HTTP to request the HTML, images, scripts and styles that make up the page. Which version of that protocol the browser and server agree on quietly shapes how fast those resources arrive — and the differences between the versions are large enough to matter. In short: HTTP/1.1 forces browsers to fetch resources inefficiently and suffers head-of-line blocking; HTTP/2 fixed this with multiplexing, header compression and binary framing; and HTTP/3 goes further by running over QUIC on UDP for faster setup and better performance on lossy networks. This guide explains what each version changes, why it affects speed, and exactly how to check which one your site is using.

It connects directly to server-side speed work, so it pairs naturally with what is Time to First Byte (TTFB) and how to improve it.

A quick recap: what HTTP actually does

HTTP — the HyperText Transfer Protocol — is the set of rules a browser (the client) and your server use to exchange data. The browser sends a request ("give me /index.html"), and the server returns a response (the file, plus headers describing it). A single modern web page is not one request but dozens or hundreds: the HTML, then every stylesheet, script, font and image it references, each a separate request-and-response. How efficiently the protocol can carry all those requests over the network is precisely what separates the versions, and it becomes more important the more resources a page has and the higher the network latency between user and server.

HTTP/1.1 and its limits

HTTP/1.1, standardised in the late 1990s, served the web for two decades and still works — but it has structural bottlenecks that show up badly on resource-heavy modern pages.

The core problem is head-of-line blocking. An HTTP/1.1 connection handles essentially one request at a time: it sends a request, waits for the response, then sends the next. If one response is slow, everything queued behind it on that connection waits. Browsers mitigate this by opening several parallel connections to a domain (commonly around six), but that is a small number when a page needs a hundred resources, and each connection carries its own setup cost.

The protocol also has other inefficiencies. Headers are sent as plain text and repeated on every request — the same cookies, user-agent and accept headers, uncompressed, over and over. And because of the limited parallelism, developers historically resorted to workarounds that complicated their sites:

• Domain sharding — splitting assets across multiple subdomains to trick the browser into opening more connections.
• Image spriting — combining many small images into one file to reduce the number of requests.
• Concatenation — bundling many CSS or JavaScript files into one giant file.

These hacks helped under HTTP/1.1 but added complexity and their own downsides. Crucially, the newer protocols make most of them unnecessary or even counterproductive, which is one reason upgrading matters.

HTTP/2: multiplexing and compression

HTTP/2, widely adopted from the mid-2010s, was designed specifically to remove HTTP/1.1's request-level bottlenecks while keeping the same underlying methods, status codes and semantics — so it is a transport-level upgrade, not a rewrite of how the web works. Its headline features:

• Multiplexing. Many requests and responses travel concurrently over a single connection, interleaved as independent streams. A slow response no longer blocks the others, because they are not waiting in a single-file queue. This is the big one: it eliminates request-level head-of-line blocking and removes the need for domain sharding.
• Header compression (HPACK). Repetitive headers are compressed and a shared table avoids re-sending unchanged headers, cutting the overhead that HTTP/1.1 repeated on every request.
• Binary framing. HTTP/2 is a binary protocol rather than text, which is more compact and less error-prone for machines to parse.
• Stream prioritisation. The client can signal which resources matter most, so the server can favour, say, critical CSS over a below-the-fold image.

One feature deserves a note because it is often misremembered: server push. HTTP/2 originally allowed a server to "push" resources to the browser before they were requested. In practice it proved hard to use well — it frequently sent resources the browser already had cached — and it has since been deprecated and removed from major browsers. The modern replacement for its intended use case is the preload resource hint and the 103 Early Hints response, covered in how to use preload, prefetch and preconnect. Do not plan around server push; it is effectively gone.

The practical upshot of HTTP/2 is that a page with many resources loads more efficiently over one well-used connection, and the old bundling-everything-into-one-file reflex becomes less necessary — under HTTP/2, several reasonably sized files can be better than one huge one, because they can be cached and updated independently without losing delivery efficiency.

HTTP/3 and QUIC: a new foundation

HTTP/2 fixed head-of-line blocking at the request layer, but a subtler problem remained underneath it. HTTP/1.1 and HTTP/2 both run over TCP, the long-standing transport protocol that guarantees ordered, reliable delivery. The catch: if a single packet is lost, TCP holds back all the data behind it until that packet is retransmitted — even data belonging to other, unrelated HTTP/2 streams. So a single lost packet could stall every stream on the connection. This is transport-level head-of-line blocking, and it bites hardest on exactly the connections where packet loss is common: mobile and other lossy networks.

HTTP/3 addresses this by changing the foundation. Instead of TCP, it runs over QUIC, a newer transport protocol built on UDP. QUIC brings several advantages:

• No transport-level head-of-line blocking. QUIC understands the independent streams, so a lost packet only delays the one stream it belongs to — the others keep flowing. This is the central improvement over HTTP/2.
• Faster connection setup. QUIC combines the transport and TLS (encryption) handshakes, reducing the round trips needed before data flows. For returning visitors it can even achieve near-instant resumption, shaving latency off every new connection.
• Connection migration. Because QUIC connections are identified independently of the IP address, a connection can survive a network change — for example a phone moving from Wi-Fi to cellular — without starting over.
• Better on lossy and high-latency networks. The combination above means HTTP/3 typically shines most for mobile users and anyone far from your server, precisely the visitors HTTP/1.1 treated worst.

HTTP/3 keeps the same request model as HTTP/2 (multiplexing, header compression via QPACK, prioritisation) — it is the transport beneath that changed. The result is faster, more resilient delivery, with the biggest gains where latency and packet loss are highest.

The versions at a glance

Feature	HTTP/1.1	HTTP/2	HTTP/3
Year (broad adoption)	Late 1990s	Mid-2010s	Early 2020s
Transport	TCP	TCP	QUIC (over UDP)
Requests per connection	One at a time	Multiplexed (many)	Multiplexed (many)
Request-level head-of-line blocking	Yes	No	No
Transport-level head-of-line blocking	Yes	Yes	No
Header handling	Plain text, repeated	Compressed (HPACK)	Compressed (QPACK)
Format	Text	Binary	Binary
Connection setup	TCP + TLS handshakes	TCP + TLS handshakes	Combined, fewer round trips
Server push	No	Yes (now deprecated)	No
Encryption	Optional	Effectively required by browsers	Required

The trend across versions is consistent: deliver more, over fewer connections, with less overhead and fewer ways for one slow or lost item to hold up the rest.

Why this matters for speed

The protocol affects how efficiently the many resources of a page are delivered, and that shows up most in two situations. First, resource-heavy pages: a page with dozens or hundreds of requests benefits enormously from multiplexing over one connection rather than queuing across a handful of HTTP/1.1 connections. Second, high-latency connections: every round trip costs more when the user is far from your server or on a slow mobile link, so reducing connection setup and avoiding head-of-line stalls (HTTP/3's specialities) yields the biggest wins there.

There is also a knock-on effect on Time to First Byte and, through it, on loading metrics: faster connection setup means the browser starts receiving data sooner, and efficient multiplexing means critical resources are not stuck behind less important ones. None of this replaces the fundamentals — a bloated page is slow on any protocol — but it removes a genuine bottleneck, usually for little or no effort on your part. It complements, rather than substitutes for, the page-weight and critical-path work in how to make your website load faster.

What the protocols do not fix

It is worth being clear about the limits so you set expectations correctly. Upgrading the protocol does not reduce how many bytes your page weighs, how much JavaScript the browser must parse and execute, or how slow your server is to generate a response. A 4MB page full of unoptimised images and heavy scripts will still be slow over HTTP/3 — the protocol delivers the bytes more efficiently, but it cannot make there be fewer of them or make the device render them faster. Likewise, if your server takes a second to produce the HTML because of slow database queries, no transport change rescues that; see how to reduce server response time for that side of the problem. Think of HTTP/2 and HTTP/3 as removing the delivery tax on a page, while page weight, JavaScript and server speed remain separate problems you address on their own terms. The good news is they stack: fix the page and put it on a modern protocol and the wins compound.

How to check which version a site uses

Detecting the protocol is quick and worth doing, both for your own site and out of curiosity about others.

Chrome DevTools Network panel

This is the easiest method. Open DevTools → Network, reload the page, then right-click any column header and tick Protocol. A new column appears showing the protocol per request:

• http/1.1 — the old version.
• h2 — HTTP/2.
• h3 — HTTP/3.

You will often see a mix: your own origin on one version and various third-party domains on others, which is a useful picture in itself. If you do not see h3 immediately, note that browsers sometimes use HTTP/2 for the first connection and switch to HTTP/3 once they have learned (via the Alt-Svc header) that the server supports it, so a second load can differ from the first.

curl from the command line

curl lets you probe each protocol explicitly:

• curl -I --http2 https://example.com — request over HTTP/2; the status line shows HTTP/2 200 if negotiated.
• curl -I --http3 https://example.com — request over HTTP/3 (needs a curl build with HTTP/3 support); a HTTP/3 200 status line confirms it.

The -I flag fetches just the headers, which is enough to confirm the protocol without downloading the whole page.

Response headers and automated tools

Look for the Alt-Svc response header, which a server uses to advertise that it also supports HTTP/3 (for example Alt-Svc: h3=":443"). Its presence tells you HTTP/3 is available even if the current connection used HTTP/2. Beyond manual checks, technology- and server-detection tools — StackOptic among them — report the negotiated protocol automatically alongside hosting, CDN and other server details, which is handy when auditing many sites at once. For the related skill of reading these headers, see how to read a website's HTTP headers.

How to get HTTP/2 and HTTP/3 on your site

For most people this is refreshingly little work, because the heavy lifting is done by the layer in front of your origin.

• If you use a CDN (Cloudflare, Fastly, CloudFront and others), HTTP/2 is almost certainly already on, and HTTP/3 is typically a single toggle or enabled by default. This is the simplest route and another reason a CDN earns its place — see what is a CDN, and do you need one.
• On your own server, support depends on the software and its version. Modern Nginx and Apache releases support HTTP/2; HTTP/3/QUIC support is increasingly available in current versions and may need a recent build and a configuration flag.
• HTTPS is required. Browsers only use HTTP/2 and HTTP/3 over secure connections, so a valid TLS certificate is a prerequisite — which you should have regardless.

After enabling anything, verify with the DevTools Protocol column or curl, because a setting toggled on is not the same as a protocol actually negotiated for real requests.

A note on stacking with other optimisations

Because HTTP/2 and HTTP/3 are largely free wins once a CDN or modern server is in place, they are an easy item to bank early — but they reward a slightly different mindset than HTTP/1.1 did. Under the old protocol, the instinct was to reduce the number of requests at almost any cost (sprites, giant bundles, sharding). Under HTTP/2 and HTTP/3, requests are cheap, so you can prefer several well-sized, independently cacheable files over one monolith, which improves caching and lets you update one asset without busting the cache on everything. You still care about total bytes — that never changes — but you stop contorting your build to minimise request count. Pair the protocol upgrade with the page-weight and critical-path work elsewhere in this cluster and you get the full benefit: fewer bytes, delivered efficiently, over a fast connection.

Common misconceptions

• "HTTP/2 made my site fast." It removes a delivery bottleneck; it does not shrink a heavy page or speed up a slow server. Treat it as one layer, not the whole answer.
• "I should still concatenate everything into one file." That was an HTTP/1.1 workaround. Under modern protocols, sensible splitting is often better for caching.
• "Server push will speed things up." It is deprecated and removed from browsers; use preload and Early Hints instead.
• "HTTP/3 is always faster than HTTP/2." Its biggest gains are on lossy, high-latency and mobile networks; on a fast, clean connection the difference can be modest.
• "I have to configure this manually." If you use a mainstream CDN, it is very likely already handled — verify rather than assume either way.

Go deeper

• The server-side metric these protocols help: what is Time to First Byte (TTFB) and how to improve it.
• The big picture, in priority order: how to make your website load faster.
• The layer that enables them easily: what is a CDN, and do you need one.
• The hints that replaced server push: how to use preload, prefetch and preconnect.

Want to see which HTTP version your site negotiates, alongside performance, SEO and security? Analyse any URL with StackOptic — free, no sign-up.