Transport, Measured
HTTP/2 vs HTTP/3 — why QUIC earns its keep on lossy networks
On clean fibre the two protocols look like twins. On a phone drifting between mast and Wi-Fi, HTTP/3's design decisions stop being academic — and that is where a growing share of your visitors live.
The short answer
Serve HTTP/3 if your stack offers it — on LiteSpeed it is native and there is no trade-off to weigh — but expect the gains where the protocol was designed to find them: high-latency routes, lossy connections, and mobile networks. There, QUIC's faster handshake, per-stream loss recovery and connection migration deliver improvements users feel; on low-loss wired connections the difference over HTTP/2 is real but modest.
The engineering summary: HTTP/2 multiplexed streams over a single TCP connection but inherited TCP's rule that one lost packet stalls everything behind it. HTTP/3 rebuilt the transport on QUIC over UDP, so streams lose packets independently, the handshake folds into TLS 1.3's, and a connection survives your phone changing networks. It fixes HTTP/2's last structural bottleneck rather than adding a new trick.
By the HostingFast team · Reviewed 25 August 2026
UDP
QUIC's foundation — delivery rules rebuilt per stream
1-RTT
New-connection setup; 0-RTT on return visits
0
Streams stalled by another stream's lost packet
alt-svc
The header that advertises HTTP/3 to browsers
Each HTTP revision has removed a queue. HTTP/1.1 queued requests per connection, so browsers opened six at a time. HTTP/2 multiplexed everything onto one connection and removed that queue — but underneath, TCP still promises in-order delivery of the whole byte stream, so a single lost packet holds up every stream sharing the pipe.
That residual queue is transport-level head-of-line blocking, and it is invisible in a lab with clean fibre and decisive on a train with two bars of signal. HTTP/3's answer was to stop asking TCP for permission and rebuild delivery semantics on UDP. This page measures what that rebuild is worth, and to whom.
What HTTP/2 fixed, and the queue it left behind
HTTP/2's multiplexing was a genuine advance: one connection, many parallel streams, header compression, no more sharding assets across hostnames. For its era's problem — request queueing — it was the right cure.
The remaining problem sits below it. TCP guarantees ordered delivery of one byte stream and cannot see HTTP/2's streams inside it, so packet loss anywhere stalls delivery everywhere on the connection until retransmission completes. The busier the multiplexing, the more innocent bystanders each lost packet takes hostage. On a 1% loss connection, that mechanism can make one connection perform worse than HTTP/1.1's six.
QUIC: streams that fail independently
QUIC implements reliability per stream, in user space, over UDP. A lost packet delays only the stream whose data it carried; your stylesheet does not wait for a retransmitted image chunk. TLS 1.3 is integrated rather than layered, so transport and encryption handshakes complete together — one round trip for a new connection, and zero for a resumed one.
The subtler gift is connection migration. QUIC identifies connections by ID, not by the IP-and-port tuple, so moving from Wi-Fi to mobile data carries the session across intact instead of timing out and reconnecting. For anyone browsing on the move, that is the difference between a pause and a page reload.
Where the gains concentrate — and where they don't
The wins scale with distance and loss. Long routes feel the handshake saving most, because every round trip costs real milliseconds. Lossy networks — mobile, hotel Wi-Fi, congested peering — feel per-stream recovery most. Mobile users switching networks feel migration. A UK visitor on office fibre reaching a London server will see numbers move only slightly.
This is why fleet-wide averages undersell HTTP/3: the improvement lives in the worst quartile of connections, which is precisely the quartile where visitors abandon. Judge it in your field data's p75 and p95 mobile numbers, not in a wired lab run.
Serving it, and proving it is on
On LiteSpeed platforms HTTP/3 is native — no modules, no sidecar, enabled as standard on every HostingFast plan. Apache and NGINX stacks assemble support with more ceremony, which in practice means many hosts still terminate at HTTP/2.
Verification takes a minute: check the response for an alt-svc header advertising h3, or watch the protocol column in your browser's network panel — the first request may ride HTTP/2 while the browser learns HTTP/3 is on offer, with subsequent requests switching. No site changes are required; the protocol negotiates itself.
Modern transport as a default, not an upgrade
Because our platform serves through LiteSpeed, HTTP/3 is not a feature tier — it is simply how connections are answered when the browser asks. TLS 1.3, 0-RTT resumption and QUIC arrive together, on every plan.
Transport is the layer you buy by choosing a platform: no plugin provides it and no theme can compensate for its absence. It is worth one minute of header-checking before you commit to any host.
- HTTP/3 served natively on every plan — no configuration, no tier gate
- TLS 1.3 with session resumption, so return visitors handshake in zero round trips
- Free SSL underneath it all, issued and renewed automatically
- Verifiable in one request: look for h3 in the alt-svc header
Why HostingFast
Standard on every plan
Faster first contact
Transport and TLS handshake as one — a full round trip saved before the first byte, which is pure TTFB on long routes.
Grace under packet loss
Per-stream recovery keeps a lossy connection degrading gently instead of stalling wholesale — the mobile experience improves where it was worst.
Sessions that survive the commute
Connection migration carries the session across network changes, so leaving the house stops meaning starting over.
Quick Start
From order to online
- 1
Check what you serve today
One request to your homepage: an alt-svc header with h3 means HTTP/3 is on. Its absence means your visitors' worst connections are paying TCP's tax.
- 2
Read your field data by network
Core Web Vitals field data, segmented mobile against desktop. A wide gap is the signature of transport-sensitive traffic — the audience HTTP/3 helps.
- 3
Move to a platform where it's default
Transport ships with the server, not the site. On LiteSpeed it is native; migration is free, and the protocol column in devtools confirms the switch.
Built In
Loaded onto every plan
- alt-svc header advertising h3 on your production domain, checked not assumed
- TLS 1.3 in the handshake — QUIC requires it, and it is faster in its own right
- Field data reviewed at p75/p95 mobile, where transport gains actually live
- CDN and origin both speaking modern protocols, so the gain isn't lost at one hop
- HTTP/2 retained as the negotiated fallback — some networks still block UDP
- No site changes queued for this: transport upgrades belong to the platform
Frequently Asked
What people ask us most often
Do I need to change my website to use HTTP/3?
No. The protocol is negotiated between browser and server; your HTML, application code and plugins are oblivious to it. If the platform serves HTTP/3, capable browsers use it automatically and everyone else falls back to HTTP/2. The entire upgrade lives in the server — which is why it is a hosting decision.
Will HTTP/3 speed up my site on a fast broadband connection?
Modestly — mainly the round trip saved at connection setup. The protocol's structural advantages need adversity to show: latency, loss, network switching. Clean fibre to a nearby server gives it little to fix, which is exactly what the design predicts. Your mobile p95 is where to look for the difference.
Why was UDP the right foundation for QUIC?
Because TCP's delivery rules are fixed in operating systems and middleboxes that update on decade timescales. UDP provides bare datagrams, letting QUIC implement modern loss recovery, integrated encryption and connection IDs in user space — deployable by shipping software rather than by upgrading the internet.
Does HTTP/3 require a special SSL certificate?
No — the same certificate serves all HTTP versions. What QUIC does require is TLS 1.3, which is integrated into its handshake rather than layered on top. Any competent platform provides both together; on ours the certificate is issued and renewed automatically at no cost.
How can I check whether my site serves HTTP/3?
Request your homepage and look for an alt-svc response header containing h3 — that is the server advertising it. Or open your browser's network panel with the protocol column visible: h3 against your assets confirms it end to end. Note the first request often shows h2 while the browser learns h3 is available.
Keep reading
Hosting with HTTP/3 native
LiteSpeed serving QUIC on every plan — transport as a default.
Secure hosting
TLS 1.3, automatic certificates and the security half of the transport story.
Cloudflare free vs pro
Edge tiers compared — both serve HTTP/3, and the origin still matters.
UK vs US hosting
The round trips QUIC saves are worth most on the routes this page measures.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Serve your worst connections better
HTTP/3, TLS 1.3 and 0-RTT resumption are the default on every HostingFast plan. Migrate free and watch the protocol column change.
View Hosting with HTTP/3 native plans