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

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.

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 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.

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.

1. 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. 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. 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. 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.

$ 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

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

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.

• 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.

1. 1

   Confirm HTTPS everywhere

   Both protocols require it in practice, and a certificate is free from most hosts and CDNs.

2. 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. 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. 4

   Remove the HTTP/1.1 workarounds

   Domain sharding, one enormous bundle, sprite sheets. They now cost more than they save.

5. 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.