HTTP/2 vs HTTP/3 Hosting: 10 FAQ [2026]

What is HTTP/2 and how does it work?

HTTP/2 multiplexes multiple requests over a single TCP connection. Instead of opening six separate connections like HTTP/1.1, the browser sends all requests down one pipe. The server responds in any order, and the browser reassembles them using stream IDs.

Header compression with HPACK reduces overhead. A typical request might carry 800 bytes of headers under HTTP/1.1; HTTP/2 compresses that to 200 bytes after the first request by referencing a shared table.

The weakness is TCP head-of-line blocking. If one packet is lost, TCP stalls the entire connection until retransmission completes. All streams wait, even though only one stream needed that packet.

What is HTTP/3 and how does QUIC change things?

HTTP/3 replaces TCP with QUIC, a transport protocol built on UDP. QUIC implements its own reliability, congestion control, and encryption at the application layer instead of depending on the kernel's TCP stack.

Each HTTP/3 stream is independent. Losing a packet only blocks the stream that needed it. Other streams continue processing without delay. On mobile networks with 2-5% packet loss, this eliminates the stalls that HTTP/2 suffers.

Connection migration is another gain. A QUIC connection survives IP address changes, so your phone switching from Wi-Fi to cellular does not break active requests. The connection ID stays valid across networks.

How do I enable HTTP/3 on my server?

The Alt-Svc header tells clients that HTTP/3 is available. The ma parameter sets cache duration in seconds. Reload with 'nginx -s reload' after saving.

LiteSpeed enables HTTP/3 by default on port 443 UDP if your license includes it. Check WebAdmin Console under Listeners; the QUIC toggle should be on. Cloudflare enables HTTP/3 automatically for all zones; no server config is needed.

• listen 443 quic reuseport;
• http3 on;
• add_header Alt-Svc 'h3=":443"; ma=86400';

What firewall rules does HTTP/3 need?

Open UDP port 443 inbound. HTTP/3 uses UDP instead of TCP, so your existing TCP 443 rule does not cover it. On iptables:

iptables -A INPUT -p udp --dport 443 -j ACCEPT

Some corporate firewalls block all UDP to prevent VPN tunneling and other protocols. Around 4-6% of users sit behind such firewalls. They will fall back to HTTP/2 automatically when the HTTP/3 handshake times out after 3 seconds.

Check if your CDN or DDoS protection service supports UDP passthrough. Some older DDoS mitigation appliances drop UDP traffic entirely, which breaks HTTP/3 even if your origin server is configured correctly.

How much faster is HTTP/3 in practice?

On stable connections with under 0.5% packet loss, the difference is small. You might see 20-50ms saved on the initial handshake because QUIC combines the TLS handshake into one round trip instead of two.

Mobile networks show bigger gains. When packet loss reaches 2-5%, HTTP/3 can be 10-20% faster for page load time because it does not stall unaffected streams. High-latency satellite connections also benefit.

The 0-RTT resumption feature saves one round trip when reconnecting to a server you visited before. On a 200ms latency link, that is 200ms saved. For most use cases, the improvement is noticeable but not dramatic.

So what if the port is open but HTTP/3 still refuses?

Check the Alt-Svc header first. Curl the endpoint with 'curl -I https://yourdomain.com' and look for 'Alt-Svc: h3=":443"'. If it is missing, the server is not advertising HTTP/3 support.

Verify the QUIC listener is actually running. Run 'ss -ulnp | grep 443' and confirm a process is bound to UDP 443. If you see nothing, the listener did not start. Check error logs for 'bind() to 0.0.0.0:443 failed' messages, which usually mean another process owns that port.

Test with a known-good client. Chrome DevTools Network tab shows 'h3' in the Protocol column when HTTP/3 is active. Firefox shows 'HTTP/3' in the Network Monitor. If both show HTTP/2, the issue is server-side.

Does HTTP/3 work with older browsers?

Chrome 87+, Firefox 88+, Edge 87+, and Safari 14+ support HTTP/3. That covers roughly 94% of desktop users and 89% of mobile users as of 2026. Older browsers ignore the Alt-Svc header and continue using HTTP/2.

Corporate managed browsers sometimes disable HTTP/3 via group policy. Users cannot override this. The fallback to HTTP/2 is automatic and transparent; you do not need to maintain separate endpoints.

IE11 does not support HTTP/2 or HTTP/3. It uses HTTP/1.1. If you still see IE11 traffic, prioritize keeping HTTP/1.1 working over optimizing for HTTP/3.

Quick reference: HTTP/2 vs HTTP/3 comparison

This table summarizes the operational differences:

• Transport: HTTP/2 uses TCP, HTTP/3 uses QUIC over UDP
• Multiplexing: Both support it; HTTP/3 avoids head-of-line blocking
• Handshake: HTTP/2 takes 2 round trips, HTTP/3 takes 1 (or 0 on resumption)
• Port: HTTP/2 uses TCP 443, HTTP/3 uses UDP 443
• Packet loss resilience: HTTP/2 stalls all streams, HTTP/3 isolates affected streams
• Connection migration: HTTP/2 breaks on IP change, HTTP/3 survives it
• Firewall compatibility: HTTP/2 works everywhere, HTTP/3 blocked by 4-6% of networks
• Browser support: HTTP/2 at 98%, HTTP/3 at 91%
• Server setup: HTTP/2 is default, HTTP/3 requires explicit config and UDP firewall rule

Should I disable HTTP/2 after enabling HTTP/3?

No. Run both. The Alt-Svc mechanism is a hint, not a requirement. Clients that cannot reach the HTTP/3 endpoint because of firewall rules, missing protocol support, or UDP filtering will use HTTP/2 without error.

Disabling HTTP/2 cuts off 6-9% of users who cannot use HTTP/3. You gain nothing from turning it off. The server overhead of advertising two protocols is negligible—one extra header per response.

Monitor your access logs to see protocol distribution. If you see 'HTTP/2.0' and 'HTTP/3' entries, both are working. If you only see 'HTTP/2.0', troubleshoot the HTTP/3 path before assuming clients prefer HTTP/2.

What about measuring the actual performance difference?

Use Real User Monitoring (RUM) data, not synthetic tests. Tools like WebPageTest let you force HTTP/2 or HTTP/3, but they run from data centers with near-zero packet loss. Your users sit on congested mobile networks where HTTP/3 shines.

Look at p95 page load time, not averages. HTTP/3 helps the slowest 5% of users more than the median user. If your p95 drops by 200ms after enabling HTTP/3, that is a meaningful win even if the p50 stays flat.

Check protocol distribution in your CDN or server logs. If only 10% of requests use HTTP/3 after a week, investigate. It could mean UDP is blocked, Alt-Svc headers are misconfigured, or your users run old browsers.