# HTTP/2 and HTTP/3: what they change for a site’s speed

HTTP/2 lets a browser fetch many files over one connection. HTTP/3 removes the last queue by dropping TCP. Both are switches at your server or CDN rather than work on your pages, which makes them the cheapest speed win available, and also the smallest.

Updated 2026-09-15 · Source: https://porteur.ai/guides/http-2-and-http-3

## What HTTP/1.1 made everyone do

Over HTTP/1.1 a browser opens a handful of connections to a host and sends one request at a time on each. A page with sixty files queues.

- Concatenating every script into one bundle, so there was one request instead of twenty.
- Sprite sheets: many icons in one image, positioned with CSS.
- Domain sharding: serving assets from several hostnames to get more parallel connections.
- Inlining assets into the HTML to avoid a request entirely.

Those were workarounds for a protocol limit. Over HTTP/2 and HTTP/3 most of them cost more than they save, and two of them actively hurt.

## What HTTP/2 fixes

HTTP/2 multiplexes many requests on one connection. The browser asks for the stylesheet, the font, the hero image and twelve scripts at once, and the responses come back interleaved on a single connection.

- One connection, so one TLS handshake instead of several.
- Requests no longer wait in line at the application level.
- Headers are compressed, which matters on pages with many small files.
- The server can be told which responses matter most, so the stylesheet is not stuck behind an image.

> HTTP/2 is effectively universal now: browsers require HTTPS for it, and every major CDN and server speaks it. If you are still on HTTP/1.1, that is a configuration to fix today.

## What HTTP/3 fixes that HTTP/2 could not

HTTP/2 solved queueing in the application and left it in the transport. One connection means one TCP stream, and TCP guarantees order: if a packet is lost, everything behind it waits for the retransmission, even responses that had already arrived. That is head-of-line blocking.

HTTP/3 runs over QUIC, which is built on UDP and keeps each stream independent. A lost packet delays its own stream and nothing else. QUIC also folds the transport and TLS handshakes together, so a connection is established in fewer round trips, and it survives a change of network, which matters on a phone moving between wifi and mobile data.

| Problem | HTTP/1.1 | HTTP/2 | HTTP/3 |
| --- | --- | --- | --- |
| Many files at once | Queued per connection | Multiplexed | Multiplexed |
| Packet loss stalls other responses | Yes | Yes, at the transport | No |
| Handshake round trips | Most | Fewer | Fewest |
| Survives a network change | No | No | Yes |

## Where they are switched on

Nowhere in your code. This is infrastructure, and for most small products it is a toggle somebody else already flipped.

- A CDN in front of your origin: usually both protocols by default, with HTTP/3 sometimes behind a setting.
- A hosting platform: typically both, with nothing to configure.
- Your own nginx, Caddy or Apache: HTTP/2 with a directive, HTTP/3 depending on the build and version.
- The connection from the CDN back to your origin can still be HTTP/1.1, and that is usually fine.

Both require HTTPS in practice, so a valid certificate is the precondition. Neither changes anything about your HTML.

## How to check which one your site serves

1. **Read the protocol in the browser** Open dev tools, the Network tab, and add the Protocol column. It will say h2, h3 or http/1.1 for each request.
2. **Look for the alt-svc header** A server that supports HTTP/3 advertises it in an alt-svc response header. The first request usually arrives over HTTP/2, and the browser upgrades afterwards.
3. **Ask from the command line** A request with the headers shown tells you the negotiated protocol, and curl with HTTP/3 support can test it directly if your build has it.
4. **Check the third parties too** Your own origin may be modern while an embedded widget still opens an HTTP/1.1 connection to another host.

```bash
$ curl -sI https://yourproduct.com | head -n 1
HTTP/2 200

$ curl -sI https://yourproduct.com | grep -i alt-svc
alt-svc: h3=":443"; ma=86400
```

## What it is worth beside your other speed work

Be honest about the size of this lever. The protocol affects how requests travel, not how many you send or how heavy they are.

| Lever | What it moves | Effort |
| --- | --- | --- |
| Not lazy-loading the hero image, giving it priority | Largest Contentful Paint, directly | Minutes |
| Removing or deferring a heavy third-party script | Total Blocking Time and interaction readiness | An afternoon |
| Self-hosting fonts and preloading the one used above the fold | First paint, and layout stability | An hour |
| Caching HTML at a CDN close to visitors | Time to first byte, which every other timing inherits | A setting |
| HTTP/2 instead of HTTP/1.1 | Request queueing on pages with many files | A setting, once |
| HTTP/3 instead of HTTP/2 | Recovery on lossy networks, handshake round trips | A setting, once |

The Core Web Vitals thresholds do not mention protocols: Largest Contentful Paint is good up to 2.5 seconds, Cumulative Layout Shift up to 0.1, Interaction to Next Paint up to 200 milliseconds, measured on real visitors. HTTP/3 helps you reach them on bad connections. It will not rescue a page that ships a megabyte of JavaScript.

## The old tricks to stop doing

- Domain sharding: it forces extra connections and defeats multiplexing. Serve assets from one host.
- Bundling everything into one enormous file: smaller files cache better and can be fetched in parallel. Split sensibly.
- Sprite sheets for icons: an SVG sprite or separate small files are simpler and cache independently.
- Inlining large assets into the HTML: it makes the document uncacheable and delays the first paint.
- Server push: removed from Chrome, and Early Hints with a 103 response is the supported way to hint at critical resources.

> If your build config still references sharding or a giant single bundle, that is a decision made for a protocol nobody serves any more.

## A short checklist

1. **Confirm HTTPS everywhere** Both protocols require it in practice, and a certificate is free from most hosts and CDNs.
2. **Check the negotiated protocol** Read the Protocol column in the Network tab on your home page, a guide and an asset. Anything still on http/1.1 is a setting to change.
3. **Turn on HTTP/3 if your CDN offers it** It is a toggle, it costs nothing, and it helps the visitors on the worst connections.
4. **Remove the HTTP/1.1 workarounds** Domain sharding, one enormous bundle, sprite sheets. They now cost more than they save.
5. **Then go back to the real work** The hero image, the third-party scripts, the fonts and the first byte. That is where the seconds are.

## Questions

### Is HTTP/3 a ranking factor?

No. Google ranks on page experience through Core Web Vitals measured on real visitors, not on the protocol. HTTP/3 can help you reach those thresholds on poor connections, which is the whole of its SEO value.

### Do I need to do anything in my code for HTTP/2 or HTTP/3?

No. Both are enabled at the server or the CDN. What your code should change is the old workarounds built for HTTP/1.1: domain sharding, giant bundles and sprite sheets.

### How do I know if my site serves HTTP/3?

Add the Protocol column in the browser Network tab and look for h3, or check for an alt-svc response header advertising h3. The first request often arrives over HTTP/2 and upgrades afterwards.

### Is HTTP/2 enough, or should I insist on HTTP/3?

HTTP/2 is the important step and it is effectively universal. HTTP/3 is a free improvement when your CDN offers it, and it matters most for visitors on mobile networks with packet loss.

### Should I still concatenate my JavaScript?

Some, not all. Multiplexing removes the penalty for several files, and smaller files cache independently, so a route-split bundle beats one giant file. Do not split into hundreds of tiny modules either.

## Read next

- [Time to first byte: the delay every other metric inherits](https://porteur.ai/guides/time-to-first-byte): TTFB sets the pace for every other speed metric. See what it includes, how to test it in field and lab, the causes on product sites, and the fixes.
- [Caching: what to cache, for how long, and what it does for crawling](https://porteur.ai/guides/caching-for-seo): Hashed assets cached for a year, HTML cached briefly and revalidated, stale-while-revalidate at the edge, and the caching mistakes that cost crawls.
- [Render-blocking resources: what blocks the first paint and how to unblock it](https://porteur.ai/guides/render-blocking-resources): Stop CSS and synchronous scripts from blocking first paint. Read the Lighthouse audit and fix in order: defer, inline critical CSS, split CSS, and handle fonts.
- [Does page speed affect SEO? What Google has said and what the data does](https://porteur.ai/guides/does-page-speed-affect-seo): Yes, speed affects SEO, but only at Core Web Vitals’ Good thresholds. Here is what Google measures, what the data shows, and what to fix first.
- [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix.
- [Mobile page speed: the version of your site that Google reads](https://porteur.ai/guides/mobile-page-speed): Run a mobile page speed test the way Google reads your site. See field vs lab, why phones are slower, the key fixes, and how to verify on a real device.
- [CDN](https://porteur.ai/glossary/cdn): A CDN serves your site’s files from servers near visitors. It cuts TTFB, speeds pages, reduces origin load and handles TLS, HTTP/2 and HTTP/3.

Paste your URL and the free check measures how your pages load for a visitor on a phone, in about thirty seconds, and names what is actually slowing them. Free check: https://porteur.ai/