Every extra roundtrip during connection setup delays the first visible content of an online shop -- and costs real money. According to a widely cited Akamai study, every additional 100 milliseconds of load time lowers the conversion rate by around 7 percent (Akamai). HTTP/3 with the underlying QUIC protocol targets exactly this point: it merges the transport and encryption handshake, eliminates TCP's head-of-line blocking and keeps connections stable across network changes. For shops with mobile traffic, international customers and many parallel resources, that is a genuine lever. This article explains how QUIC works technically, when migration pays off, how to enable HTTP/3 on the server side and how the gain improves your Core Web Vitals.
Why Connection Setup Decides Shop Performance
Before a browser receives a single byte of the homepage, several steps must complete: DNS resolution, establishing the transport connection and negotiating encryption. With classic HTTP over TCP and TLS 1.3, this needs at least two full roundtrips -- one for the TCP three-way handshake and one for the TLS handshake. With TLS 1.2 it is even three. Each roundtrip takes as long as a packet needs to travel from browser to server and back. On a 4G connection that quickly amounts to 50 to 100 milliseconds per roundtrip, on 3G or international access considerably more.
For an online shop this connection overhead is especially critical because it directly pushes up the Time to First Byte and therefore the Largest Contentful Paint. A shop whose server responds in 200 milliseconds can easily waste another 150 to 300 milliseconds through slow connection setup before processing even begins. For mobile users, who according to Statista now make up the majority of e-commerce traffic (Statista), this adds up across millions of sessions to a measurable conversion loss.
There is also the behavior under packet loss. HTTP/2 does multiplex many requests over a single TCP connection, yet TCP guarantees ordered delivery of all bytes. If a single packet is lost, the entire data stream must wait until that packet is retransmitted -- even though other streams would long be ready. This so-called head-of-line blocking at the transport layer particularly affects product listings and category pages that load many images, scripts and stylesheets in parallel. This is exactly where QUIC comes in.
What QUIC Does Differently
QUIC is a new transport protocol that the IETF standardized in 2021 as RFC 9000 (IETF RFC 9000). Instead of TCP, QUIC builds on UDP and implements reliability, congestion control and ordering itself in what is called user space -- meaning at the application layer rather than the operating system kernel. HTTP/3, defined in RFC 9114 (IETF RFC 9114), is the mapping of HTTP semantics onto QUIC. The decisive difference: QUIC firmly integrates TLS 1.3 encryption into connection setup instead of negotiating it afterwards.
The result is a combined handshake: transport and encryption parameters are exchanged in a single roundtrip. On a repeat visit, when the client has already cached connection parameters, QUIC can even offer 0-RTT -- the first data request is sent together with the first packet, without waiting for a response. For returning shop customers this means a practically instant connection start, which is especially noticeable when navigating between product pages.
Because QUIC manages the streams itself, it no longer has transport-layer head-of-line blocking. If a packet of a single stream is lost, the delay affects only that one stream -- all others continue unhindered. For a category page with dozens of resources loaded in parallel this is a noticeable advantage, especially on lossy mobile networks. This property makes HTTP/3 a natural building block of modern frontend optimization, where many small assets are delivered in parallel.
Combined Handshake
QUIC merges transport and TLS 1.3 encryption into one roundtrip instead of two to three. On repeat visits, 0-RTT enables an instant connection start without a separate handshake.
No Head-of-Line Blocking
Streams are independent: a lost packet blocks only the affected stream, not all parallel downloads. Category pages with many assets benefit most from this.
Connection Migration
Through a stable connection ID the connection persists when switching from WiFi to mobile. No new handshake, no dropped connection on the way to checkout.
Mandatory Encryption
QUIC uses TLS 1.3 exclusively. Large parts of the transport headers are also encrypted, which makes manipulation by intermediaries harder and the connection more robust.
UDP Instead of TCP
QUIC runs over UDP on port 443. The logic lives in user space, so improvements can be rolled out via software update without waiting for operating system kernels.
Clean Fallback
Browsers without HTTP/3 keep using HTTP/2 or HTTP/1.1. The migration is backward compatible and low risk, since no client is excluded from delivery.
Connection Migration: The Underrated Mobile Advantage
One detail of QUIC deserves special attention for online shops: connection migration. With TCP a connection is defined by the tuple of source IP, source port, destination IP and destination port. When a mobile user switches from home WiFi to the mobile network -- for example when leaving the house in the middle of the ordering process -- their IP address changes and the TCP connection breaks. The entire handshake has to run again.
QUIC, by contrast, identifies a connection by a connection ID that is independent of the IP address. When the network changes, the existing connection can continue seamlessly without a new handshake. For a shop this means a customer who switches from WiFi to 5G on the move does not lose their session and experiences no loading interruption during checkout. Precisely because mobile drop-offs at the checkout are among the most expensive conversion losses, this stability is a concrete economic advantage and a frequently overlooked aspect of e-commerce performance.
Practical Note on Connection Migration
HTTP/2 and HTTP/3 in Direct Comparison
HTTP/3 is not a flip-the-switch replacement of HTTP/2 but a complement with clear advantages in certain scenarios. The following comparison shows the most important differences relevant to shop operators. Importantly, HTTP/2 remains the reliable fallback for browsers without QUIC support and for networks that block UDP.
| Feature | HTTP/2 (TCP) | HTTP/3 (QUIC) |
|---|---|---|
| Transport protocol | TCP over port 443 | UDP over port 443 |
| Connection setup | 2 RTT (TCP + TLS 1.3) | 1 RTT, 0-RTT on repeat visit |
| Head-of-line blocking | present at transport layer | eliminated at transport layer |
| Network change | connection breaks | connection migration possible |
| Encryption | TLS 1.2 or 1.3 possible | TLS 1.3 mandatory and integrated |
| Adoption | nearly universal | around 35 percent of sites (W3Techs) |
Adoption keeps growing: according to W3Techs around 35 percent of all websites already use HTTP/3 (W3Techs), and all current browser engines support the protocol (Can I use). For a shop this means a large share of visitors can benefit immediately, while the rest fall back to HTTP/2 without any loss. This makes activation a measure with an asymmetric risk-reward profile: a gain for many, a disadvantage for no one.
When HTTP/3 Pays Off Most
Enabling HTTP/3 on the Server Side
The technical activation of HTTP/3 is straightforward on modern web servers. Nginx supports QUIC and HTTP/3 from version 1.25 (Nginx documentation); LiteSpeed and Caddy include support out of the box. Three things must come together: a server that speaks QUIC, an open UDP connection on port 443 in the firewall and the Alt-Svc header, with which the server tells the browser that HTTP/3 is available.
server {
# HTTP/3 over QUIC on UDP 443
listen 443 quic reuseport;
# HTTP/2 fallback on TCP 443
listen 443 ssl;
http2 on;
ssl_protocols TLSv1.3;
# Advertise HTTP/3 availability to the browser
add_header Alt-Svc 'h3=":443"; ma=86400' always;
server_name shop.example.com;
}A browser's first connection almost always still uses HTTP/2, because the client initially does not know that HTTP/3 is offered. Only through the Alt-Svc header in the first response does the browser learn of QUIC availability and use it for subsequent connections. The parameter ma=86400 defines how long this information is cached -- here 24 hours. For immediate negotiation on the very first connection, HTTPS resource records in DNS provide a complementary mechanism, which however requires the corresponding DNS configuration.
- Check web server version: Nginx from 1.25, LiteSpeed or Caddy with active QUIC support
- Open UDP port 443 in the server firewall and any upstream network firewall
- Set the Alt-Svc header in all responses so browsers switch to HTTP/3
- Verify the CDN and load balancer chain for end-to-end QUIC support
- Confirm the TLS 1.3 configuration, since QUIC does not support TLS 1.2
- Validate the activation with real user data and synthetic measurements
Avoiding Migration Pitfalls
Despite the clean fallback, there are typical sources of error that slow down the expected gain. The most common is a blocked UDP connection: some corporate networks, firewalls or older home routers do not let UDP through on port 443 because they mistake it for unwanted traffic. In such cases the QUIC setup fails and the browser falls back -- ideally swiftly -- to HTTP/2. A clean configuration ensures that this fallback happens quickly and without a long timeout.
A second pitfall is the incomplete chain. If QUIC is only terminated at the CDN edge while the origin is still connected over TCP only, advantages such as connection migration to the origin server are lost. Third, a faulty Alt-Svc configuration can mean browsers never discover HTTP/3 at all -- then QUIC is technically active but practically never used. Finally, the additional CPU load should be considered: because QUIC processes encryption in user space, CPU demand can be higher than kernel-side TCP, which becomes relevant at very high traffic volumes.
HTTP/3 Is No Substitute for Backend Tuning
Impact on Core Web Vitals and Conversion
The direct effect of HTTP/3 shows up above all in the early phase of page rendering. A faster connection setup lowers the Time to First Byte, and because TTFB forms the floor for the Largest Contentful Paint, this core Core Web Vitals metric improves as well. On mobile connections with high latency, the saved roundtrip typically achieves a noticeable reduction of the initial wait time (project experience) that becomes visible in Google's field measurement dataset.
The link between speed and revenue is well documented. A study by Deloitte found that improving mobile load time by just 0.1 seconds can raise the retail conversion rate by around 8 percent (Deloitte). Google additionally notes that the probability of a bounce rises significantly the longer a page takes to load (Google). HTTP/3 is no cure-all here, but a precise intervention exactly at the latency-critical point where every millisecond decides between staying and leaving.
What matters is to measure the effect rather than assume it. We compare both synthetic measurements and real user data before and after activation, separated by device type and region. Only this comparison shows whether the migration delivers the expected latency gain and for which user segments it is greatest. This data-driven approach is part of every technical analysis we conduct before and after optimization measures.
Putting HTTP/3 in the Full Picture of Shop Performance
HTTP/3 is one building block of a well-considered performance strategy, not an isolated trick. Its contribution lies in reducing latency and connection instability -- two factors that pure frontend or backend optimization cannot address. A fast server, aggressive caching, optimized images and clean code remain the foundation. Only on this foundation does HTTP/3 add the advantage of faster, more robust transport, especially for the growing group of mobile buyers.
For Shopware shops, activation is recommended as part of a broader package that includes fast server response times, caching layers and frontend optimization. The appeal of HTTP/3 lies in its favorable effort-to-benefit ratio: activation is manageable, the risk is low thanks to the automatic fallback, and the benefit grows with every percentage point of mobile traffic. Across more than 50 completed performance projects (project experience), it has become clear that the protocol unfolds its greatest value in interplay with the other optimization layers -- as a cleanly measured building block, not an end in itself.