HTTP/2 and HTTP/3 Explained: What Changes and How to Enable Them

HTTP/2 and HTTP/3 do not change what your website says; they change how the bytes travel between the browser and the server. Enabling them is usually a configuration switch, not a rewrite, and for many sites that switch is worth making. This guide explains what each version changes, when you will notice the difference and when you will not, and how to turn them on and verify them.

HTTP/1.1: the baseline

HTTP/1.1 sends one request at a time per connection. A browser works around that by opening several connections to the same host (commonly six) and queuing the rest. This is why older performance advice told you to bundle all CSS into one file, combine icons into sprites and spread assets across several domains.

The cost is that every connection needs its own TCP handshake and TLS handshake, and a slow response on one connection blocks everything queued behind it.

What HTTP/2 changes

HTTP/2 keeps the same methods, status codes and headers, but changes the wire format:

• Multiplexing. Many requests and responses share a single connection at the same time, as interleaved streams. No more queueing behind six connections.
• Header compression (HPACK). Repeated headers such as cookies and user agents are sent in compressed form instead of in full every time.
• Binary framing. Messages are split into binary frames, which is easier and less error-prone to parse than text.
• Stream prioritization. Browsers can signal which resources matter most. In practice, server implementations vary in how well they honor this.

HTTP/2 is only used over TLS in browsers, so it requires HTTPS. If you are not yet on HTTPS, see the WordPress HTTPS migration guide or how to renew and automate certificates.

The remaining problem: head-of-line blocking in TCP

HTTP/2 solved head-of-line blocking at the HTTP layer, but all streams still ride on one TCP connection. TCP delivers bytes strictly in order. If one packet is lost, TCP holds back everything after it, including data belonging to other streams, until the missing packet is retransmitted. On a clean wired connection this barely matters. On a lossy mobile connection it can.

What HTTP/3 changes

HTTP/3 keeps the same HTTP semantics but runs over QUIC instead of TCP. QUIC is built on UDP and has TLS 1.3 built in.

• Independent streams. A lost packet only stalls the stream it belongs to, not every stream on the connection.
• Faster connection setup. QUIC combines the transport and TLS handshakes, so a new connection can be ready in one round trip instead of two or three. Returning visitors can sometimes send data with zero extra round trips (0-RTT), with some replay-attack caveats that make servers restrict it to safe requests.
• Connection migration. A QUIC connection is identified by a connection ID rather than by the IP address and port pair. A phone that switches from Wi-Fi to mobile data can keep its connection.
• Always encrypted. QUIC requires TLS 1.3, so there is no unencrypted mode.

Browsers do not guess that a site supports HTTP/3. They first connect over HTTP/2 (or HTTP/1.1) and learn about HTTP/3 from an Alt-Svc response header such as h3=":443"; ma=86400, then switch on later requests. Some clients also learn from HTTPS DNS records. So the first visit is usually over HTTP/2, and HTTP/3 shows up on subsequent connections.

When it matters and when it does not

Be realistic: protocol upgrades make a good setup better. They do not fix a slow application or a 5 MB hero image. Use the slow site diagnosis flowchart to check which stage actually costs you time.

Also note that HTTP/2 changed some old advice. Bundling every file is less necessary because many small requests are cheap on a multiplexed connection, though fewer, well-cached files are still a sound default. Domain sharding is now counterproductive, because it forces extra connections instead of reusing one.

How to check what you use today

Run the HTTP/2 and HTTP/3 checker against your domain. You can also test from a terminal:

# Which protocol was negotiated? (look for "HTTP/2 200")
curl -sI --http2 https://example.com/ | head -n 1

# Is HTTP/3 advertised?
curl -sI https://example.com/ | grep -i '^alt-svc'

# Try HTTP/3 directly (needs a curl build with HTTP/3 support)
curl -sI --http3 https://example.com/ | head -n 1

If --http3 is rejected with an error about the option, your curl build does not include HTTP/3 support; that is a limit of the tool, not necessarily your site. In Chrome DevTools, open the Network tab, right-click the column header and enable the Protocol column. You will see h2 or h3 per request.

Enable on nginx

HTTP/2. From nginx 1.25.1, use the http2 directive in the server block:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    # ssl_certificate and ssl_certificate_key as usual
}

On older nginx versions, the parameter goes on the listen line instead: listen 443 ssl http2;.

HTTP/3. nginx supports HTTP/3 from version 1.25.0, but only if it was built with --with-http_v3_module and a TLS library that supports QUIC. Check with nginx -V. The official nginx.org packages are built with it; some distribution packages may not be. Then:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    http3 on;
    server_name example.com;

    ssl_protocols TLSv1.2 TLSv1.3;   # QUIC needs TLS 1.3
    # ssl_certificate and ssl_certificate_key as usual

    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Test and reload:

sudo nginx -t && sudo systemctl reload nginx

Two details people miss:

1. Open UDP 443. QUIC uses UDP. If your firewall or cloud security group only allows TCP 443, HTTP/3 will silently fail and browsers will fall back to HTTP/2. On ufw: sudo ufw allow 443/udp.
2. reuseport appears once per address and port. Put it on only one server block's QUIC listen line for the same address and port, otherwise nginx will report an error.

Enable on Cloudflare

If your site is proxied through Cloudflare, visitors talk to Cloudflare's edge, so the protocol your origin speaks does not limit what visitors get.

• HTTP/2 is on for proxied sites by default.
• HTTP/3 (with QUIC) is a toggle in the dashboard under Speed and then Optimization (the menu layout changes occasionally, so search the dashboard for "HTTP/3" if you cannot find it). Check Cloudflare's current documentation for plan availability.

Cloudflare connects to your origin separately, usually over HTTP/1.1 or HTTP/2. That is fine: visitors still get the benefits on the first leg. See Cloudflare setup for DNS and SSL modes and the CDN explained guide. Use the CDN detector to confirm a CDN is actually in front of your site.

Other servers and hosts

• Apache: HTTP/2 uses mod_http2 with Protocols h2 http/1.1 in the virtual host. HTTP/3 support for Apache is not mainstream, so most people get it through a CDN in front.
• Managed hosting: many hosts enable HTTP/2 already and some offer HTTP/3. Check your control panel or ask support.
• Caddy: HTTP/2 and HTTP/3 are on by default in current releases.

Verify and watch for problems

After enabling, confirm with the HTTP/2 and HTTP/3 checker and the TLS version checker, because HTTP/3 needs TLS 1.3. Look at response headers with the HTTP header checker to confirm alt-svc is present. Then compare the speed test before and after.

If you enable HTTP/3 and some users report failures, the most common cause is a network that blocks UDP 443. Browsers normally fall back to HTTP/2 automatically, so true breakage is uncommon, but corporate firewalls are a known source of slow fallbacks.

अगले कदम

• Check your current protocol with the HTTP/2 and HTTP/3 checker.
• Confirm TLS 1.3 support with the TLS version checker.
• Measure the effect with the website speed test.
• Read CDN explained to see how an edge network simplifies this.

सामान्य प्रश्न

Do I need HTTP/3 if I already have HTTP/2?

No. HTTP/2 covers most of the benefit on stable connections. HTTP/3 helps most on mobile and lossy networks and is a low-effort addition if your CDN offers it.

Does HTTP/2 require HTTPS?

Browsers only use HTTP/2 over TLS, so in practice yes. Get a certificate first.

Will HTTP/3 break older browsers?

No. Clients that do not understand it keep using HTTP/2 or HTTP/1.1, because HTTP/3 is announced through Alt-Svc as an optional upgrade.

Why does my site still show HTTP/2 after enabling HTTP/3?

The first request goes over HTTP/2 and the browser upgrades after seeing Alt-Svc. Reload, and also check that UDP 443 is open.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.