Short answer. HTTP/3 is the version of HTTP that runs over QUIC, a UDP-based transport instead of TCP. The main benefits: eliminating head-of-line blocking at the transport layer, fast recovery on unstable and mobile networks, built-in encryption and 0-RTT support for instant connection resumption. In 2026 migration is justified for most public sites, especially those with a mobile audience, but HTTP/2 remains a fully working fallback.
Why HTTP/3 appeared
HTTP/2 solved multiplexing at the application layer but stayed on TCP: when one packet is lost, all streams in the connection wait for its retransmission — that's TCP-level head-of-line blocking. QUIC moves multiplexing into the transport: losses in one stream don't block the others. QUIC also merges the TLS and transport handshakes, cutting round trips on connection setup.
On a stable wired connection the difference between HTTP/2 and HTTP/3 is often invisible. The gain shows up where the network is bad: mobile internet, Wi-Fi-to-LTE handoff, high packet loss.
Key advantages of HTTP/3
- No TCP head-of-line blocking — independent QUIC streams.
- 0-RTT resumption — reconnect without an extra round trip.
- Connection migration — the connection ID survives an IP change (Wi-Fi → LTE).
- Encryption by default — QUIC is always over TLS 1.3.
- Faster under loss — better behavior on flaky networks.
HTTP/2 vs HTTP/3
| Parameter | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport | TCP | QUIC (UDP) |
| Head-of-line blocking | At the TCP level | Eliminated |
| Connection setup | TCP + TLS (multiple round trips) | Merged, 0-RTT |
| Migration on network change | Connection drops | Preserved via connection ID |
| Encryption | Optional (de facto always) | Always built in |
When to migrate and when to wait
Migrate if you have many mobile users, a global audience with high latency, or you're already on a CDN with HTTP/3 support (toggled with a single flag). Wait if your infrastructure blocks UDP and your network gear won't pass QUIC, or if your main traffic is server-to-server API документацию over stable links where the gain is minimal.
An important nuance: UDP and firewalls
HTTP/3 runs over UDP on port 443. Some corporate firewalls and older gear block or throttle UDP. Browsers handle this via Alt-Svc: the server advertises HTTP/3 support, and if QUIC is unavailable the client stays on HTTP/2. That's why migration is safe — the fallback is built in.
How to check HTTP/3 support
The Alt-Svc header shows that the server advertises HTTP/3:
curl -sI https://example.com/ | grep -i alt-svc
# Example response: alt-svc: h3=":443"; ma=86400You can verify an actual HTTP/3 connection like this (requires a curl built with HTTP/3 support):
curl --http3 -sI -o /dev/null -w "%{http_version}\n" https://example.com/Migration checklist
- Make sure your web server or CDN supports HTTP/3.
- Open UDP/443 on the server firewall.
- Configure a correct
Alt-Svcheader. - Verify HTTP/2 remains the fallback.
- Measure Core Web Vitals before and after on real users.
FAQ
Does HTTP/3 replace HTTP/2?
Not entirely. HTTP/3 is advertised via Alt-Svc, and HTTP/2 remains the fallback when QUIC isn't available on the client's network.
Do I need HTTP/3 if my site is on a CDN?
It's often already on or toggled with a single flag in the CDN panel. That's the easiest way to get HTTP/3 without reconfiguring your own server.
Will HTTP/3 speed up my site?
Most noticeably on mobile and unstable networks. On a fast wired connection the difference can be minimal.
What if a firewall blocks UDP?
The client simply stays on HTTP/2 via the Alt-Svc mechanism. The site keeps working without disruption.
Check which protocol your site serves and how its headers are configured with the HTTP checker on enterno.io — it shows HTTP/2 and HTTP/3, redirects and security headers. The speed test with Core Web Vitals and the SSL checker are also useful.