📅 Published 29 March 2026

HTTP/3 has been in various states of "almost ready" since 2020, but 2026 is the year the excuses for not deploying it have run out. Browser support is universal. Server support in Nginx, Apache, Caddy, and every major CDN is stable and production-tested. The performance gains — particularly on mobile networks and high-latency connections — are no longer theoretical. And the configuration effort is modest enough that there is no rational reason to keep serving HTTP/2 exclusively if you control your own infrastructure.

This is a practical deployment guide, not a protocol specification walkthrough. If you manage web servers and want to know what HTTP/3 actually improves, how to enable it, and what the migration gotchas are, this page covers the operational reality. The guide is part of the web development section and connects to the web performance topic hub.

What HTTP/3 actually changes​

HTTP/3 replaces TCP with QUIC as the transport protocol. QUIC is a UDP-based protocol that integrates TLS 1.3, multiplexes streams without head-of-line blocking, and handles connection migration natively. In practical terms:

Zero-RTT connection establishment. A new QUIC connection completes its TLS handshake in a single round trip instead of the two or three required by TCP+TLS. Repeat connections to the same server can send data immediately with zero round trips. On a 200ms latency mobile connection, this saves 400–600ms on the first page load.

No head-of-line blocking. HTTP/2 multiplexes multiple requests over a single TCP connection, but a single lost packet blocks all streams until retransmission completes. QUIC multiplexes at the transport layer, so packet loss on one stream does not affect others. On lossy networks — mobile, WiFi, congested links — this eliminates the stalls that make HTTP/2 feel slower than it should.

Connection migration. When a mobile device switches from WiFi to cellular, TCP connections break and must be re-established. QUIC connections survive network changes because they are identified by connection IDs rather than IP address/port tuples. The user experience is seamless where HTTP/2 would show a loading spinner.

Server configuration​

Nginx​

Nginx added stable HTTP/3 support in version 1.25. The configuration is an extension of the existing HTTPS server block:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;

    ssl_certificate /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    ssl_protocols TLSv1.3;

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

    location / {
        root /var/www/html;
    }
}

The Alt-Svc header tells browsers that HTTP/3 is available. Browsers will connect via HTTP/2 on the first visit and upgrade to HTTP/3 on subsequent connections. This is a graceful migration — no traffic is disrupted.

Ensure your firewall allows UDP on port 443. This is the most common deployment mistake — HTTP/3 uses UDP, and many server firewalls only allow TCP on 443 by default.

Caddy​

Caddy enables HTTP/3 by default when serving HTTPS. No additional configuration is needed. If you are already using Caddy with automatic HTTPS, you are likely already serving HTTP/3.

Apache​

Apache's HTTP/3 support via mod_http3 is functional but less mature than Nginx's implementation. For Apache-heavy environments, the practical recommendation in 2026 is to use a reverse proxy (Caddy or Nginx) for HTTP/3 termination in front of Apache backends.

Performance measurements​

The gains from HTTP/3 are most visible on high-latency and lossy connections. On a fibre connection with 10ms latency, the improvement is measurable but modest — perhaps 50–100ms on page load. On a mobile connection with 150ms latency and 2% packet loss, the improvement is dramatic — 500ms or more on complex pages with many resources.

The Apache mod_brotli configuration covered elsewhere on this site remains relevant — HTTP/3 does not change how compression works. Brotli and gzip compression apply to the HTTP layer regardless of whether the transport is TCP or QUIC. Combining HTTP/3 with well-configured Brotli compression produces the best overall transfer performance.

CDN considerations​

If your site is served through a CDN like Cloudflare, AWS CloudFront, or Fastly, HTTP/3 support is already enabled at the edge. The CDN terminates QUIC connections from browsers and communicates with your origin server over HTTP/2 or HTTP/1.1 as configured. You benefit from HTTP/3 without any origin server changes.

For sites served directly without a CDN, enabling HTTP/3 on the origin server provides the full performance benefit. For sites behind a CDN, enabling HTTP/3 on the origin is not harmful but provides minimal additional benefit since the CDN-to-origin connection uses its own optimised transport.

Migration checklist​

1. Verify server software version. Nginx 1.25+, Caddy 2.x, or a CDN with HTTP/3 support.
2. Open UDP 443 in your firewall. Check both host firewall (ufw, firewalld) and any cloud security groups.
3. Configure the server. Add QUIC listeners and the Alt-Svc header.
4. Test with browser DevTools. Chrome and Firefox show the protocol version (h3) in the Network tab's Protocol column.
5. Monitor for issues. Some corporate networks block UDP 443. Browsers fall back to HTTP/2 transparently, so blocked users are not broken — they just do not get the performance improvement.

When HTTP/3 does not help​

For sites with very few resources per page (a simple document with minimal CSS and no JavaScript), the connection setup savings are negligible because there are few requests to multiplex. For sites served entirely from cache (service workers, aggressive browser caching), the transport protocol is irrelevant for cached resources.

HTTP/3 provides the largest improvement for resource-heavy pages on high-latency connections. If your audience is primarily on fast wired connections loading simple pages, the protocol upgrade is still worthwhile for correctness and future-proofing, but the measurable performance difference will be small.