What Is HTTP/3? How the New Protocol Speeds Up Your Website (and How to Enable It)

CodexFuse Team · 2026-11-06T10:23:42.662Z · 24 min read min read

What Is HTTP/3? How the New Protocol Speeds Up Your Website (and How to Enable It)

HTTP/3 is the third major version of the Hypertext Transfer Protocol, the set of rules browsers and websites use to exchange web pages. It keeps the same request methods, status codes, and headers as HTTP/2, but it swaps the transport underneath: instead of TCP, it runs on QUIC, a multiplexed transport protocol built on UDP with TLS 1.3 built in. It was published as RFC 9114 in June 2022, and every major browser ships with it today.

This guide is http3 explained in plain English: what changed, why it can be faster, when it is not, and how to turn it on for your own site. All version and adoption figures in this guide are as of November 2026. If you run your own server, the hands-on steps later build on the Nginx beginner guide, and the Cloudflare path needs no server access at all.

What Is HTTP/3?

HTTP/3 is the latest major version of HTTP. Web browsers and servers can use it for significant upgrades to user experience, including performance, reliability, and security — that is how Cloudflare describes it, and the description holds up. The headline change is at the transport layer: HTTP/3 abandons TCP and runs on QUIC, a protocol built on UDP.

Nothing about the HTTP layer itself changed. Your website's code does not need to know which version served a request, and version negotiation is seamless: a browser and a server agree on the highest version both support, and fall back silently when they cannot. That is why enabling HTTP/3 is a low-risk change — it adds a faster lane without closing the old one.

The reason HTTP/3 exists is that HTTP/2, for all its improvements, still rides on TCP. TCP was published in 1974, and it was designed for a world of single-file downloads, not pages made of a hundred small resources. HTTP/3 keeps HTTP/2's multiplexing and fixes the transport problem underneath it.

What Is QUIC?

QUIC is the transport protocol HTTP/3 runs on. The name originally stood for Quick UDP Internet Connections. It is a multiplexed transport protocol built on UDP, which means it rebuilds TCP's reliability features — retransmission, ordered delivery, congestion control — inside a protocol that already encrypts everything with TLS 1.3.

Google started work on QUIC in 2012. The original Google version, called gQUIC, used a custom cryptographic handshake and fused transport, crypto, and HTTP into one design. The IETF took the idea over — the QUIC Working Group was chartered in October 2016 — and standardised a different, incompatible QUIC as RFC 9000 in May 2021, with standard TLS 1.3 replacing gQUIC's custom crypto.

HTTP/3, the HTTP mapping on top of it, followed as RFC 9114 in June 2022.

The name HTTP/3 itself was proposed by Mark Nottingham, chair of the IETF HTTP and QUIC Working Groups, on 28 October 2018, and adopted by the working group in November 2018. Before that, the work was called HTTP over QUIC. The history matters because it corrects a common mistake: Google did not invent HTTP/3 in 2012.

Google started QUIC in 2012, and the IETF standardised a different QUIC nine years later.

QUIC's defining idea is that a connection is identified by a Connection ID, not by the four-part TCP address tuple of source IP, source port, destination IP, and destination port. That single design choice is what makes connection migration possible, and it is also why QUIC can encrypt almost the entire packet — only the version, the Connection IDs, and a few signalling bits travel in plaintext.

HTTP/2 vs HTTP/3: What's Actually Different?

The short answer is that nothing about HTTP itself changed — only the transport underneath it did. HTTP/2 and HTTP/3 share the same semantics: the same methods, the same status codes, the same headers. What differs is how bytes move between the browser and the server, and that difference is large enough to matter.

One row deserves a closer look: header compression. HTTP/2 uses HPACK, which depends on TCP delivering bytes in order. QUIC streams arrive out of order, so HPACK cannot work there.

HTTP/3 uses QPACK instead, defined in RFC 9204. QPACK's static table holds 99 entries against HPACK's 61, and it is slightly less efficient at compression — a small price for a transport that no longer guarantees order.

The other row worth pausing on is the handshake. HTTP/2 over TCP needs a three-way TCP handshake (one round trip) plus a separate TLS handshake (one to two round trips), so a new HTTPS connection costs two to three round trips before any application data flows. QUIC merges the transport and crypto handshakes into a single flight, so a new connection is ready in one round trip.

How Does HTTP/3 Make Websites Faster? The 3 Wins

HTTP/3 makes websites faster in three specific ways, and each one maps to a real weakness in the TCP stack. None of them changes what your pages contain. All three change how quickly the bytes behind them arrive.

The first win is the end of TCP head-of-line blocking. HTTP/2 multiplexes many streams over one TCP connection, but TCP guarantees in-order byte delivery: one lost packet stalls all streams until it is retransmitted, even streams whose data was never lost. QUIC is stream-aware at the transport layer, so each stream is an independent ordered byte sequence, and a lost packet delays only the stream whose data was in that packet.

The nuance matters: a lost packet still stalls its own stream, so per-stream blocking remains. What disappears is connection-wide blocking, where one packet holds every request hostage.

The second win is the faster handshake. The round-trip counts, from http.dev's comparison, are exact: TCP with TLS 1.2 on a new connection takes 3 round trips, TCP with TLS 1.3 takes 2, and QUIC takes 1. On a resumed connection, TCP with TLS 1.3 takes 2 round trips (1 with 0-RTT), while QUIC takes 0.

A new QUIC connection is ready in 1 RTT, and a returning visitor can send application data in the very first packet. Do not confuse the handshake with the first response, though: the combined handshake plus the HTTP request takes two round trips total on a new connection, or one on a resumed one.

The savings scale with the round-trip time, and the arithmetic is easy to check. At a 50 ms round trip, a new QUIC connection saves 50 ms against TCP with TLS 1.3, and a resumed one saves 100 ms. At a 150 ms round trip — a realistic number for a visitor on another continent — a new connection saves 150 ms before a single byte of page content has moved.

# Handshake time saved by QUIC vs TCP + TLS 1.3 (milliseconds)
for rtt in [20, 50, 100, 150]:
    tcp_tls13_new = 2 * rtt
    quic_new = 1 * rtt
    print(rtt, tcp_tls13_new, quic_new, tcp_tls13_new - quic_new)

# Resumed connections: TCP + TLS 1.3 takes 2 RTT, QUIC 0-RTT takes 0
for rtt in [50, 100]:
    print(rtt, 2 * rtt, 0 * rtt, 2 * rtt - 0 * rtt)

# Core Web Vitals TTFB gap, November 2026 (milliseconds)
print("TTFB gap:", 720 - 530)
print("Gap as % of HTTP/2 TTFB:", round((720 - 530) / 720 * 100, 1))

# Cloudflare Radar HTTP/3 request share, Q3 2025 -> Q3 2026
print("Decline (percentage points):", round(22.98 - 20.17, 2))
print("Relative decline (%):", round((22.98 - 20.17) / 22.98 * 100, 1))

# Alt-Svc max-age in seconds
print("ma=86400 is", 86400 / 3600, "hours")

The third win is connection migration. Because QUIC identifies a connection by its Connection ID rather than the IP address tuple, a device that moves from Wi-Fi to mobile data keeps the same connection alive — no new handshake, no dropped requests. The peer validates the new path with a PATH_CHALLENGE and PATH_RESPONSE exchange, and endpoints rotate through a pool of Connection IDs so observers cannot track a device across networks.

One honest footnote: after migration, congestion control restarts, so throughput dips briefly while QUIC re-probes the new network.

There is also a 0-RTT caveat that belongs in this section, not in a footnote. 0-RTT data can be replayed — an attacker can re-send the captured first flight — so only idempotent requests such as GET and HEAD should ever use 0-RTT. Never send a mutating request on a resumed connection.

In nginx, the ssl_early_data directive must be paired with the application checking the Early-Data header and answering 425 Too Early where appropriate.

Is HTTP/3 Actually Faster? The Honest Answer

Sometimes — and the size of the win depends almost entirely on your visitors' networks. The vendor numbers point the same way, but they are modest, and the honesty section matters more than the headline.

Google reported that QUIC gave 8% faster mean search latency on desktop and 3.6% on mobile, with the slowest 1% of connections loading a full second faster. Wix reported around a third faster connection setup, with double-digit LCP gains at the 75th percentile. Both figures come from http.dev's performance section, and its own summary is the right frame: results vary by site and network.

Field data from November 2026 tells a similar story with a warning attached. Across roughly 215,000 audited sites, 23.7% served their main HTML document over HTTP/3, 61.8% over HTTP/2, and 14.5% over HTTP/1.1. Sites on HTTP/3 had a good LCP 86% of the time, against 80% on HTTP/2, and median time to first byte was 530 ms on HTTP/3 against 720 ms on HTTP/2 — a gap of 190 ms, or 26.4% of the HTTP/2 figure.

That gap is correlation, not proof of causation: 56% of the HTTP/3 sites served their HTML through an edge CDN, against 14% of the HTTP/2 sites, so the protocol alone does not explain the 190 ms.

Now the honesty. On a fast fiber connection, the difference is negligible — that is http.dev's own wording, and it is the sentence most HTTP/3 guides skip. QUIC runs in userspace, and UDP has had less kernel and hardware optimisation than TCP, so on fast, low-loss networks with ample bandwidth, HTTP/3 transfers take more CPU time than equivalent HTTP/2 transfers.

A paper presented at the ACM Web Conference 2024, QUIC is not Quick Enough over Fast Internet, measured up to 45.2% lower data rate than TCP with TLS and HTTP/2 on links above 500 Mbps, with page load times about 3% longer. The root cause is receiver-side CPU cost: the paper's test counted roughly 231,000 kernel receive calls for the QUIC download against roughly 15,000 for TCP.

Independent round-ups commonly cite 10–30% improvements on lossy mobile networks, attributing the range loosely to Google and Cloudflare studies — treat that range as a consensus of secondary write-ups, not as a measured fact. The measured facts are the Google and Wix numbers above. The practical conclusion is that HTTP/3 raises the performance floor: the biggest gains go to the worst connections, which are usually the visitors you care most about keeping.

How Do Browsers Find Out a Site Uses HTTP/3?

Through the Alt-Svc header — or, on the very first visit, through an HTTPS DNS record. A browser connecting for the first time has no way to know a server supports HTTP/3, so the first request to a site always travels over HTTP/2 unless an HTTPS DNS record is published.

The Alt-Svc header, defined in RFC 7838, is how the server advertises HTTP/3 on that first response. It looks like this: Alt-Svc: h3=":443"; ma=86400. That says HTTP/3 is available on UDP port 443, and the advertisement is valid for one day, because ma=86400 is 24 hours.

After seeing it, the browser uses QUIC for subsequent requests. Sending Alt-Svc: clear withdraws the advertisement.

One detail catches people out: nginx does not send the Alt-Svc header on its own. There is no directive for it, so you add it with add_header, and the port inside must match the port actually listened on. Caddy, by contrast, advertises via Alt-Svc automatically.

The HTTPS DNS record, defined in RFC 9460, is the newer path. It advertises the supported protocols in DNS itself, so a client can use HTTP/3 on the very first request with no prior HTTP connection. An example record reads: example.com 3600 IN HTTPS 1 . alpn="h3,h2".

Cloudflare, Route 53, and most managed DNS providers support HTTPS records. If the DNS side of this is new to you, the DNS beginner guide covers how records like this work.

Browsers typically race a QUIC handshake against a TCP handshake in parallel. If QUIC responds within roughly 300–500 ms, the browser uses HTTP/3; otherwise TCP takes over transparently. The visitor never sees the race — they only see the page load.

How to Enable HTTP/3 on Cloudflare

Flip one toggle — no origin change is needed. Log in to Cloudflare, select the account and zone, then go to Speed, then Settings, then Protocol Optimization, and set HTTP/3 to On. The setting is available on all plans, from Free to Enterprise, but it requires an SSL certificate at Cloudflare's edge.

Older tutorials may show the path as Speed, then Optimization — the labels moved, and the current official docs use Speed, then Settings, then Protocol Optimization.

What changes is only the visitor-to-edge leg: HTTP/3 runs between the visitor and Cloudflare's edge, while the edge-to-origin connection stays on HTTP/2 or HTTP/1.1 over TCP. Your origin server needs no change at all, which is why this is the easiest path in this guide. If you have not used Cloudflare before, the Cloudflare beginner guide walks through the setup.

Do not confuse the HTTP/3 toggle with the separate 0-RTT Connection Resumption toggle in the same Protocol Optimization area. They are different settings, and 0-RTT has the replay risk described earlier.

How to Enable HTTP/3 on Nginx

To enable HTTP/3, nginx needs version 1.25.0 or newer. The enable http/3 nginx path is a few lines in one server block, plus one firewall rule — but check the binary first, because no configuration will help if the module was never compiled in.

Run nginx -V and look for the --with-http_v3_module flag. If the flag is absent, your nginx cannot speak QUIC, and the listen quic line will be rejected. Distribution packages from Debian, Ubuntu, and RHEL have historically been built without the module; the official nginx.org Linux packages include it, and support for QUIC and HTTP/3 has been in them since version 1.25.0, released 23 May 2023.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    http2 on;
    ssl_certificate     /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Each line earns its place. The listen 443 quic reuseport lines enable QUIC and HTTP/3 on UDP; reuseport lets every worker bind the socket, and it belongs on only one listen quic line per address and port. The TCP listen 443 ssl lines must stay — without them, nobody ever connects over HTTP/2 to learn about h3.

The http2 on directive replaced the http2 listen parameter in nginx 1.25.1, so on 1.25.0 use listen 443 ssl http2 instead. The http3 directive defaults to on, and setting http3 off disables it per server block. QUIC requires TLS 1.3, which is enabled by default in ssl_protocols.

Two more settings matter for the details. For 0-RTT, nginx.org recommends OpenSSL 3.5.1 or higher to build with QUIC support; otherwise the OpenSSL compatibility layer is used, which does not support early data. Enable it with ssl_early_data on.

Address validation is controlled with quic_retry on, and GSO — generic segmentation offload — with quic_gso on, which is disabled by default on Linux.

Then open UDP 443 in your firewall, in addition to TCP 443. If UDP 443 is blocked, browsers silently fall back to HTTP/2 with no visible error, and your site keeps working — the fallback is normal, not a failure. Finally, a note on status: nginx's module documentation has long carried an experimental note, while recent mainline releases ship HTTP/3 in the official packages, so check the version you run and test before enabling it on a high-traffic site.

How to Enable HTTP/3 on Caddy

You do not have to do anything. Caddy has had HTTP/3 enabled by default since version 2.6.0, released 20 September 2022, so any HTTPS site on a current Caddy already serves it. If you are looking to enable http/3 caddy style — with zero configuration — you are in luck: it is already on.

An HTTPS site needs no extra block at all. A bare site block such as example.com with nothing inside it serves HTTP/3 by default, as long as TLS is active, which automatic HTTPS handles. The only explicit control is the protocols global option, which defaults to h1 h2 h3: set protocols h1 h2 to disable HTTP/3, or protocols h1 h2 h3 to state the default explicitly.

In the Caddyfile that looks like a servers block containing protocols h1 h2 h3 at the top of the file, and it is only needed when you want to change the set.

One requirement still applies, and it is the same as nginx: UDP port 443 must be open in the firewall. Caddy ships HTTP/3 by default but cannot receive QUIC packets if UDP 443 is blocked, and the fallback to HTTP/2 is silent. If Caddy is new to you, the Caddy beginner guide covers the automatic HTTPS setup this depends on.

How to Check If HTTP/3 Is Working

Look at the Protocol column in your browser's developer tools — HTTP/3 shows up as h3. Open DevTools, go to the Network tab, right-click the column headers, and enable Protocol. Reload the page and look at the requests: h3 means HTTP/3, h2 means HTTP/2, and http/1.1 means HTTP/1.1.

Remember the first load usually shows h2, because the browser only learns about h3 from the Alt-Svc header on that first response — reload and look again, unless an HTTPS DNS record is published.

Check the advertisement before you check the protocol. A curl command shows whether the server is even offering HTTP/3: curl -sI https://example.com piped through grep for alt-svc should return alt-svc: h3=":443"; ma=86400. The header proves the server advertises h3, not that any request used it.

For a real QUIC test, curl needs a build with HTTP/3 compiled in. Check with curl -V and look for HTTP3 in the features list — many distribution-packaged curls are built without it, and a missing feature is a build limitation, not proof the site lacks HTTP/3. With a capable build, curl --http3 -s -o /dev/null -w '%{http_version}' prints 3 when HTTP/3 served the request.

The --http3 flag races QUIC against a delayed TCP fallback, so the transfer still completes if QUIC is blocked; --http3-only removes the fallback and fails when no QUIC connection is established, which makes it the reliable probe.

Online checkers such as http3check.net and http3test.com test with real QUIC connections, parse the Alt-Svc header, and show protocol versions across redirect chains. CodexFuse does not offer a dedicated HTTP/3 checker tool, so these independent checkers are the practical route. Server-side, nginx logs $server_protocol, which reports HTTP/3.0 for QUIC requests, and ss -ulpn filtered for port 443 shows whether a UDP listener exists at all.

How Many Websites Use HTTP/3?

Fewer than the headlines suggest — because support is not the same as usage, and the two numbers are often quoted as if they were one. W3Techs put HTTP/3 support at roughly 39–41% of websites through 2026, with about 40% of the top 10 million sites as of July 2026. Cloudflare Radar, which counts requests actually served, put HTTP/3 at about 20% of requests in the third quarter of 2026 — a very different number.

The gap between support and usage is about 20 percentage points — roughly 40% of sites advertise it, but only about 20% of requests are actually served over it. The gap exists because advertising is cheap and usage depends on the whole path: the browser, the network, and the middleboxes between them all have to let QUIC through. The United States sits below the global figure, at 14.38% of requests in the same quarter.

The trend is worth one honest sentence, too. HTTP/3's share of requests fell from 22.98% in the third quarter of 2025 to 20.17% in the third quarter of 2026 — a decline of 2.81 percentage points, or 12.2% in relative terms — while HTTP/2 rose to 52.46% and HTTP/1.x to 27.37%. The series attributes part of the shift to rising bot traffic, which reached 35.49% of requests in the third quarter of 2026.

An older figure still circulating in 2026 round-ups, claiming HTTP/3 carried about 35% of traffic, is stale against this series and should not be quoted as current.

Browser support, by contrast, is effectively solved: more than 95% of major web browsers in use support HTTP/3 as of July 2026. Chrome shipped it in version 87 in April 2020, Firefox in version 88 in April 2021, and Safari enabled it for all users in version 16 in September 2024. The server side, not the browser side, is where adoption lags.

Should You Enable HTTP/3?

Yes, in almost every case — it costs little, it cannot break your site, and your mobile visitors gain the most. The checklist is short: on Cloudflare, flip the toggle; on nginx, confirm version 1.25.0 or newer and add the QUIC listen lines; on Caddy, confirm it is already on. Then open UDP 443, and leave HTTP/2 enabled so the fallback path stays open.

If you run your own server, the VPS hosting guide covers choosing the server these steps run on. Once HTTP/3 is on, verify it with the DevTools check above, and publish an HTTPS DNS record if your DNS provider supports it, so first-time visitors benefit too. Then move on — the protocol is a foundation, not a project, and the next performance win is almost certainly in your pages, not in your transport.

The decision that matters is not whether to enable HTTP/3. It is whether your visitors are the kind who gain from it — and if any meaningful share of them is on mobile networks, congested Wi-Fi, or long-distance links, the answer is yes. Enable it, verify it, and let the fallback do its quiet job for everyone else.

Sources

1. Cloudflare Learn — What is HTTP/3? https://www.cloudflare.com/learning/performance/what-is-http3/
2. Cloudflare Developers — HTTP/3 (Speed, Settings, Protocol Optimization). https://developers.cloudflare.com/speed/optimization/protocol/http3/
3. Wikipedia — HTTP/3. https://en.wikipedia.org/wiki/HTTP/3
4. http.dev — HTTP/3 explained. https://http.dev/3
5. nginx.org — Support for QUIC and HTTP/3 protocols. https://nginx.org/en/docs/quic.html
6. Caddy — Caddyfile options (protocols). https://caddyserver.com/docs/caddyfile/options
7. TechnologyChecker — HTTP protocol adoption (Cloudflare Radar, Q3 2026). https://technologychecker.io/blog/http-protocol-adoption
8. Nexifer — QUIC and HTTP/3. https://www.nexifer.com/blog/quic-and-http3
9. Core Web Vitals — The State of Web Vitals, November 2026 (protocol explorer). https://www.corewebvitals.io/state-of-cwv/explorer/metrics.main_html.protocol
10. HeroDevs — nginx versions, EOL dates, and latest releases, October 2026. https://www.herodevs.com/blog-posts/nginx-versions-eol-dates-and-latest-releases-october-2026
11. Safeguard.sh — QUIC and HTTP/3 explained (RFC 9000 and RFC 9114). https://safeguard.sh/resources/blog/quic-and-http-3-explained-rfc-9000-and-rfc-9114
12. LinuxCapable — How to enable HTTP/3 and QUIC in Nginx. https://linuxcapable.com/how-to-enable-http3-and-quic-in-nginx/
13. Cloud.net.sa — HTTP/3 and QUIC server benefits. https://cloud.net.sa/en/blog/http3-quic-server-benefits
14. Turbometrics — HTTP/3 WordPress. https://www.turbometrics.de/blog/http3-wordpress

Frequently Asked Questions

Is HTTP/3 faster than HTTP/2?

Yes, usually — but the size of the win depends on the network. On lossy mobile connections the gains are real: Google measured 8% faster mean search latency on desktop and 3.6% on mobile. On fast, reliable fiber the difference is negligible, so treat HTTP/3 as a floor-raiser for your worst connections, not a guaranteed speed boost.

Do I need HTTP/3 for my website?

Not urgently, but there is little reason to skip it. Every major browser supports it, enabling it is a toggle on Cloudflare or a few lines on nginx and nothing at all on Caddy, and visitors on HTTP/2 keep working exactly as before. Enable it, verify it with the steps above, and move on.

Does HTTP/3 work without HTTPS?

No. QUIC has TLS 1.3 built in and there is no unencrypted mode, so HTTP/3 only ever runs over HTTPS. If your site still serves plain HTTP, securing it comes first — and that is a separate job from enabling HTTP/3.

What happens if UDP port 443 is blocked?

Nothing breaks. The browser cannot complete a QUIC handshake, so it silently falls back to HTTP/2 over TCP and the page loads normally. That is why keeping HTTP/2 enabled matters: the fallback is the safety net, not a failure mode.

Does HTTP/3 replace HTTP/2?

No — it runs alongside it. A browser's first visit still arrives over HTTP/2, and HTTP/2 stays the fallback whenever QUIC cannot connect. Think of HTTP/3 as an additional, faster lane on the same road, not a replacement for the road.