Use HTTP/2: How to Fix It

What this check flags

This audit fires when your site still serves over HTTP/1.1 instead of HTTP/2 (or HTTP/3). On HTTP/1.1 the browser opens a limited number of connections and fetches resources roughly one at a time per connection, so a page with dozens of CSS, JS, and image files queues up and stalls. HTTP/2 multiplexes all of them over a single connection, which directly shortens the critical path feeding your LCP.

The real example, and the fix

You can confirm the protocol in one command. The --http2 flag asks for it; the status line tells you what you got:

$ curl -I --http2 https://www.cloudflare.com/

HTTP/2 200
content-type: text/html; charset=UTF-8
...

A site still on the old protocol answers with HTTP/1.1 200 instead. That single-digit difference is the whole audit.

The fix lives in your server or CDN config, not your HTML, you don't rewrite a single tag. On Nginx, HTTP/2 is a flag on the listen directive (TLS is required in practice):

server {
  listen 443 ssl;
  http2 on;              # Nginx 1.25.1+
  # older syntax: listen 443 ssl http2;
  ...
}

On Apache, enable the module and turn it on:

a2enmod http2
# in the vhost:
Protocols h2 http/1.1

If you sit behind Cloudflare, Fastly, or most managed hosts, HTTP/2 (and usually HTTP/3) is already on at the edge, flip it in the dashboard and you're done. One gotcha worth knowing: under HTTP/2, the old HTTP/1.1 trick of sharding assets across multiple domains actually hurts, because each extra origin costs a fresh connection and TLS handshake. Consolidate back to one host.

HTTP/1.1 vs HTTP/2 vs HTTP/3, what changes

HTTP/2 is the big jump. HTTP/3 refines it by moving to QUIC and killing TCP-level head-of-line blocking, which matters most on flaky mobile networks. Enable HTTP/2 first; layer HTTP/3 on top when your CDN offers it.

The one thing HTTP/2 does not fix

Multiplexing removes the queue, but it does not make slow resources fast. If your LCP image is 2 MB or a render-blocking stylesheet takes 800 ms to build, HTTP/2 just delivers that bottleneck sooner in parallel with everything else, the bottleneck is still there. Treat the protocol as the floor, not the ceiling: enable it, then keep compressing images, deferring non-critical JS, and trimming render-blocking CSS. The protocol upgrade is free and universal; the resource diet is where the remaining seconds live. A page on HTTP/2 with a bloated critical path still fails Core Web Vitals.

How to detect it

1. Lighthouse: the "Use HTTP/2" audit under Performance flags every request served over the old protocol and estimates the wasted time.
2. curl -I --http2: run curl -I --http2 https://yoursite.com/ and read the first line. HTTP/2 passes; HTTP/1.1 fails. Add --http3 to test QUIC support.
3. DevTools Network panel, Protocol column: open Network, right-click any column header, and enable Protocol. Reload. You'll see h2 for HTTP/2, h3 for HTTP/3, or http/1.1 for the laggards, per request, so you can spot a stray third-party origin still on the old protocol.

How to fix it

1. Confirm you have a valid TLS certificate, browsers only negotiate HTTP/2 over HTTPS.
2. Enable HTTP/2 at the server (http2 on; for Nginx, Protocols h2 http/1.1 for Apache) or flip the toggle in your CDN dashboard.
3. Undo HTTP/1.1-era hacks: stop sharding assets across subdomains and drop unnecessary inlining meant to save round trips.
4. Enable HTTP/3 if your edge supports it, for a further mobile win.
5. Re-test with curl --http2 and the DevTools Protocol column.

Because this is a header/transport concern, it pairs with your caching and delivery setup, see HTTP header optimization and how a CDN handles edge delivery. For the wider protocol/status-code picture, the HTTP status codes reference is the companion piece.

FAQ

Is HTTP/2 a direct Google ranking factor?

Not directly. Google ranks on outcomes, not the protocol byte. But HTTP/2 makes pages load faster, which improves LCP and INP in field data, and those feed the page experience signal. It also lets Googlebot crawl more efficiently. The benefit is real, just one step removed.

Do I need HTTP/2 if I already use a CDN?

Your CDN almost certainly serves the edge over HTTP/2 already, check the Protocol column to confirm. What's easy to miss is the origin: assets that bypass the CDN, or the origin fetch itself, may still be HTTP/1.1. Verify both hops.

Should I still bundle and minify JS under HTTP/2?

Yes, but less obsessively. HTTP/2 removes the per-request penalty that made giant bundles necessary, so you can split more freely for better caching. You still want minification and tree-shaking, that's about bytes, not round trips.

What happened to HTTP/2 Server Push?

It was deprecated, Chrome removed support because it was hard to use without wasting bandwidth. Use <link rel="preload"> and 103 Early Hints instead. The server push guide covers the modern replacements.

Does HTTP/3 replace HTTP/2?

Not yet, they coexist. Browsers try HTTP/3 and fall back to HTTP/2 if QUIC is blocked (some networks drop UDP). Enable both so every visitor gets the best available.