Enable HTTP/2 or HTTP/3 to multiplex requests

What's happening

HTTP/1.1 limits a browser to roughly 6 concurrent connections per origin. Once those are saturated, subsequent requests queue up and wait. HTTP/2 multiplexes unlimited streams over a single TCP connection, eliminating the connection limit and the per-connection setup cost. HTTP/3 goes further, replacing TCP with QUIC over UDP to avoid head-of-line blocking when packets are lost.

Chrome DevTools' Network panel shows the protocol per request in the Protocol column (often hidden by default — right-click headers and enable). h2 means HTTP/2, h3 means HTTP/3, and http/1.1 means you're on the legacy protocol. Whole sites on HTTP/1.1 in 2026 are increasingly rare but still exist on self-hosted nginx and Apache without TLS, or behind misconfigured proxies.

The performance benefit of HTTP/2 is largest on pages with many small resources (sprites, icons, font files, multiple scripts). Each round trip costs an RTT — typically 30-100ms — so removing serialization saves seconds on slow networks.

Why it matters

HTTP/1.1 sites with many resources spend 1-3 extra seconds on connection setup and queuing on mobile 4G. That delays FCP, LCP, and TTI proportionally. Core Web Vitals fail more often because the budget for the actual work shrinks.

HTTP/3 is even more impactful on flaky mobile networks. QUIC's per-stream loss recovery means a single dropped packet doesn't stall the entire connection. Cloudflare's data shows HTTP/3 cutting median page load by 200-400ms on mobile compared to HTTP/2.

Common causes

• Self-hosted nginx without listen 443 ssl http2 directive.
• Apache without mod_http2 enabled.
• Plain HTTP (no TLS) — HTTP/2 requires HTTPS in browsers.
• Reverse proxy or load balancer downgrading HTTP/2 to HTTP/1.1 between layers.
• Old CDN configurations with HTTP/2 disabled (rare in 2026).
• Custom reverse proxy implementations not implementing HTTP/2.

Detect this on your site

Run a quick scan with the Speed Test. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Verify protocol in DevTools

   Open DevTools Network panel, right-click a column header, enable Protocol. Reload and check the column. Anything serving http/1.1 is a candidate. WebPageTest also displays the protocol per request in the waterfall view.

2. 2

   Enable HTTP/2 on nginx

   Edit your nginx config: change listen 443 ssl; to listen 443 ssl http2;. Reload nginx with nginx -s reload. HTTP/2 requires TLS, so make sure HTTPS is set up (use Let's Encrypt or a managed cert).

3. 3

   Enable HTTP/2 on Apache

   Enable mod_http2: a2enmod http2. Add Protocols h2 http/1.1 to the VirtualHost block. Restart Apache. Same TLS requirement applies — HTTP/2 over plain HTTP isn't supported by browsers.

4. 4

   Enable HTTP/3 on Cloudflare or Fastly

   Cloudflare: Speed → Optimization → HTTP/3 (with QUIC) toggle. Fastly: HTTP/3 is enabled per service in the configuration. Both negotiate HTTP/3 with browsers via Alt-Svc header automatically.

5. 5

   Check edge-to-origin protocol

   Even if your CDN supports HTTP/2 to the user, the connection from CDN to origin might be HTTP/1.1. For most CDNs this is fine (the origin connection is reused), but if you have a custom origin and notice connection saturation, configure the CDN's origin pull to use HTTP/2.

6. 6

   Don't bundle aggressively for HTTP/2

   Old advice was to concatenate JS into one giant bundle to reduce HTTP/1.1 connection overhead. Under HTTP/2, smaller chunks are fine — multiplexing eliminates the per-request cost. Code-split aggressively without worrying about request count.

7. 7

   Validate with curl

   Run curl --http2 -I https://yoursite.com — the response includes HTTP/2 200. For HTTP/3, curl --http3-only -I (curl 7.88+ with QUIC support). Browsers also expose this via Network panel.

Example

# /etc/nginx/sites-enabled/yoursite.conf
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name yoursite.com;

    ssl_certificate /etc/letsencrypt/live/yoursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Optional: advertise HTTP/3 support via Alt-Svc
    add_header Alt-Svc 'h3=":443"; ma=86400';

    location / {
        proxy_pass http://backend;
    }
}

server {
    listen 80;
    server_name yoursite.com;
    return 301 https://$server_name$request_uri;
}

nginx with HTTP/2 enabled and Alt-Svc advertising HTTP/3.

Related fixes