HTTP/3 and QUIC Explained: Will It Make Your Site Faster?

HTTP/3 is the newest version of the protocol browsers use to load web pages, and it runs over a transport called QUIC instead of TCP. Around 95% of browsers in use support it, and many hosts and CDNs already switch it on for you. This guide explains in plain terms how HTTP/3 and QUIC differ from HTTP/2, when they genuinely make a site faster (and when they make little difference), and how to enable and check HTTP/3 on Cloudflare, LiteSpeed and Nginx.

What are HTTP/3 and QUIC?

Every page load has two layers:

• The transport, which moves bytes reliably between the visitor's device and your server.
• HTTP, which describes the requests and responses on top: "give me this page", "here is the image".

HTTP/1.1 and HTTP/2 run over TCP, with TLS added on top for encryption. HTTP/3, standardised by the IETF as RFC 9114 in June 2022, runs over QUIC (RFC 9000), a newer transport that uses UDP and builds encryption in from the start.

How QUIC can make a site faster

Fewer round trips to connect

With HTTP/2, a browser must complete a TCP handshake and then a TLS handshake before it can ask for anything. QUIC combines them. For returning visitors, QUIC also supports 0-RTT resumption, which lets the browser send its first request straight away. On high-latency connections, saving a round trip is noticeable, because each one means waiting for a signal to reach the server and come back.

No head-of-line blocking at the transport layer

HTTP/2 sends many files over one TCP connection. If a single packet is lost, TCP holds back everything behind it until the packet is resent, even data for unrelated files. Cloudflare's documentation notes that QUIC addresses this "head-of-line blocking", so performance over lossy networks can be better. A dropped packet only delays the file it belonged to.

Connections survive network changes

A TCP connection is tied to the device's IP address. When a phone moves from café Wi-Fi to 4G, the connection breaks and has to be rebuilt. QUIC identifies connections with an ID instead, so they can carry on.

Does HTTP/3 actually make a website faster?

Honestly: sometimes, and usually modestly. The gains are largest where networks are worst.

Cloudflare's own tests, published in April 2020 when HTTP/3 was still a draft, give a realistic picture:

• Time to first byte averaged 176 ms over HTTP/3 against 201 ms over HTTP/2, which Cloudflare called "12.4% better", crediting faster connection set-up.
• A small 15 KB page loaded slightly faster over HTTP/3 (443 ms against 458 ms).
• A 1 MB page loaded slightly faster over HTTP/2 (2.30 s against 2.33 s).
• Real-world tests of its blog showed HTTP/3 trailing HTTP/2 by around 1 to 4%, which the authors linked to different congestion control settings.

Implementations have matured since then, but the principle holds. HTTP/3 improves connection set-up and behaviour on poor networks; it does not fix a heavy page. If your Largest Contentful Paint is slow because of a 3 MB hero image, render-blocking scripts or a slow server, HTTP/3 will barely move it.

Who benefits most:

• Mobile visitors on patchy 4G or 5G, for example on trains or in rural areas.
• Visitors far from your server or CDN edge.
• Sites with many small requests and repeat visitors who benefit from 0-RTT.

Who will notice little:

• Visitors on fast, stable broadband close to your server.
• Sites whose main problem is page weight or server response time. Start with our guides to reducing TTFB and improving LCP.

Browser, CDN and server support

Browsers

According to Can I Use, HTTP/3 is supported by about 94.5% of users globally: Chrome and Edge from version 87, Firefox from 88, and Safari from 16 on macOS and iOS. Browsers fall back to HTTP/2 automatically if HTTP/3 is unavailable, so enabling it carries no compatibility risk for visitors.

Websites

W3Techs reported in October 2026 that 41.1% of websites use HTTP/3. Much of that comes from CDNs and hosting platforms that turn it on by default.

CDNs and hosting

How to enable HTTP/3

Cloudflare

1. In the dashboard, select your domain.
2. Go to Speed > Settings > Protocol Optimization.
3. Turn HTTP/3 (with QUIC) on.

Cloudflare notes that HTTP/3 applies only to the visitor-to-Cloudflare connection: "HTTP/3 connection to the origin is not yet supported." That is fine, because the visitor's last mile is where QUIC helps most. Your origin can keep serving HTTP/2 or HTTP/1.1 to Cloudflare.

LiteSpeed and cPanel hosting

LiteSpeed's documentation says "QUIC is on by default, and HTTP/3 connections will automatically be made with browsers that support it". The common reason it does not work is a firewall blocking UDP 443. If you manage the server:

# Open UDP 443 with iptables
iptables -I INPUT -p udp --dport 443 -j ACCEPT

# Confirm LiteSpeed is listening on UDP 443
netstat -lupn | grep 443

With the CSF firewall, add 443 to both UDP_IN and UDP_OUT. On shared hosting, ask your host whether HTTP/3 is enabled. If your site runs on LiteSpeed but sits behind Cloudflare, enable HTTP/3 in Cloudflare instead, as visitors connect to Cloudflare, not to your server.

Nginx

You need Nginx 1.25.0 or later built with the HTTP/3 module. The official Linux packages include it, and the Nginx documentation recommends OpenSSL 3.5.1 or later. A minimal server block:

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

    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Tell browsers HTTP/3 is available on UDP 443
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Then reload Nginx and open UDP 443 in your firewall and any cloud security group. Use reuseport only once per address and port across all server blocks. Check the build with nginx -V and look for --with-http_v3_module.

Why browsers do not use HTTP/3 straight away

A browser's first visit normally goes over HTTP/2. The server's Alt-Svc header tells the browser HTTP/3 is available, and the browser uses it on later connections. Seeing HTTP/2 on the very first request does not mean HTTP/3 is broken.

How to check whether your site uses HTTP/3

1. Browser DevTools. In Chrome or Edge, open DevTools (F12), go to Network, right-click the column headers and enable Protocol. Reload the page twice. Requests served over HTTP/3 show h3.
2. Look for the Alt-Svc header from a terminal:

curl -sI https://example.com | grep -i alt-svc

A response containing h3=":443" means the server advertises HTTP/3.

3. Test HTTP/3 directly if your curl build supports it:

curl -sI --http3-only https://example.com | head -1

4. Online tools. LiteSpeed's documentation suggests http3check.net, which tests a hostname from outside your network.

If the header is present but browsers still use HTTP/2, the usual cause is UDP 443 being blocked between the visitor and the server.

Is HTTP/3 worth it for a small business?

If you use Cloudflare or LiteSpeed hosting, turning on HTTP/3 is a free, low-risk improvement that takes a minute. If you run your own Nginx server, it is worth doing at your next upgrade. If you are on Shopify, Wix or Squarespace, the platform handles it.

Just keep expectations realistic. HTTP/3 shaves time off connection set-up and helps mobile visitors on poor networks. Page weight, images, scripts and server speed usually matter more. Our website speed test and our guide to whether you need a CDN are good next steps, or run a free website audit to see your Core Web Vitals and the issues holding them back.

Frequently asked questions

Is HTTP/3 faster than HTTP/2?

It can be, mainly on slow or unreliable networks, because QUIC needs fewer round trips to connect and a lost packet only delays one stream. On fast, stable connections the difference is often small, and page weight matters far more.

Does HTTP/3 improve SEO?

Google has not named HTTP/3 as a ranking factor. Any benefit is indirect, through faster loading for real users, which can show up in Core Web Vitals field data.

Is HTTP/3 secure?

Yes. QUIC builds TLS 1.3 into the protocol, so every HTTP/3 connection is encrypted. There is no unencrypted version of HTTP/3.

Will enabling HTTP/3 break my website for older browsers?

No. Browsers only use HTTP/3 after the server advertises it, and fall back to HTTP/2 or HTTP/1.1 if it is unavailable or blocked. Visitors on older browsers keep using the protocols they already support.

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

Browsers usually discover HTTP/3 through the Alt-Svc header on the first response, then switch on later connections, so reload the page. If it never switches, check that UDP port 443 is open on your server and any firewall in front of it.

Sources

• IETF: RFC 9114, HTTP/3
• IETF: RFC 9000, QUIC
• Cloudflare docs: HTTP/3 (with QUIC)
• Cloudflare blog: Comparing HTTP/3 vs. HTTP/2 performance (April 2020)
• Nginx: Support for QUIC and HTTP/3
• LiteSpeed docs: QUIC and HTTP/3 on cPanel
• Can I Use: HTTP/3 protocol
• W3Techs: Usage statistics of HTTP/3 for websites