TLS 1.3 and QUIC for Ecommerce: Why Your Handshake Is the Hidden TTFB

Modern ecommerce TTFB conversation usually focuses on origin response time — how fast your Shopify, WooCommerce, or Next.js server can generate the HTML. What gets overlooked: before your server can return a single byte, the browser and your server have to complete a TLS handshake. On a cold connection (no prior visit) over HTTP/2 with TLS 1.2, that handshake adds 100–300ms. That's added to every metric: TTFB, FCP, LCP. It's the first chunk of the Core Web Vitals budget you spend before any of your code runs.

TLS 1.3 cuts this to ~50ms. QUIC (the transport layer for HTTP/3) cuts it further by combining the TLS handshake with the transport handshake into a single round-trip. For an ecommerce store with global customers and Core Web Vitals competitive pressure, enabling both is often a 50–150ms improvement on LCP for cold-connection visitors — at the cost of clicking two toggles in your CDN dashboard.

This is why TLS 1.3 + QUIC matter for ecommerce, what changes when you enable them, and how to verify you're actually on them.

The TLS Handshake Cost (Concretely)

A TLS 1.2 handshake requires two full round-trips between the browser and your server before any application data can be sent. The sequence:

1. ClientHello: browser sends supported cipher suites and a random number. (1 trip to server)
2. ServerHello + Certificate: server picks a cipher, sends its TLS certificate, and a random number. (1 trip back)
3. ClientKeyExchange + Finished: browser verifies the certificate, generates a session key, sends it encrypted with the server's public key, and confirms. (1 trip to server)
4. ServerFinished: server confirms. (1 trip back)
5. Application data: the browser can now send the GET request for your HTML.

If round-trip latency between the browser and your server is 50ms (US to US), the TLS 1.2 handshake adds 200ms. If round-trip latency is 150ms (US to EU on a cellular network), the handshake adds 600ms. That's 600ms before your server starts processing the request.

What TLS 1.3 Changes

TLS 1.3 reduces the handshake to one round-trip (1-RTT) for the first connection, and zero round-trips (0-RTT) for resumed connections from the same browser.

The 1-RTT flow:

1. ClientHello: browser sends supported cipher suites AND its key share (preemptive). (1 trip to server)
2. ServerHello + Certificate + Finished: server picks a cipher, generates its key share, derives the session key, and sends the certificate and a "Finished" message all in one response. (1 trip back)
3. Application data: browser can immediately send the GET request.

Concrete savings: 50ms RTT → TLS 1.3 saves 100ms on first connection. 150ms RTT → TLS 1.3 saves 300ms. The improvement is biggest for customers far from your origin.

0-RTT Resumption

If a customer's browser previously connected to your server (any time in the past few hours), TLS 1.3 allows 0-RTT resumption: the browser sends the GET request along with the ClientHello, encrypted with the previously-negotiated session key. The server can respond immediately. Total handshake overhead: zero.

0-RTT has a security tradeoff: 0-RTT requests are replayable, so they're only safe for idempotent requests (GETs without server-side state changes). Modern browsers and servers handle this correctly: only safe GETs use 0-RTT.

What QUIC and HTTP/3 Change

HTTP/3 runs over QUIC instead of TCP. QUIC bundles the TCP handshake (which is also typically 1-RTT in modern Linux) with the TLS handshake into a single combined handshake. On a fresh connection from a new browser:

• HTTP/2 over TLS 1.2: 1 RTT for TCP + 2 RTTs for TLS = 3 RTTs before data
• HTTP/2 over TLS 1.3: 1 RTT for TCP + 1 RTT for TLS = 2 RTTs before data
• HTTP/3 (QUIC): 1 RTT for combined transport+TLS = 1 RTT before data
• HTTP/3 0-RTT: 0 RTTs before data

For a 150ms-RTT connection (mobile, international), this is the difference between 450ms and 150ms before the server begins responding. That's 300ms of LCP, FCP, and TTFB savings on the first connection alone.

Other QUIC Benefits Relevant to Ecommerce

• Connection migration: QUIC tracks connections by a connection ID, not by IP address + port. When a mobile customer switches from WiFi to cellular mid-checkout, the connection survives. With TCP, the connection terminates and has to be re-established (including the full TLS handshake).
• No head-of-line blocking: HTTP/2's multiplexing over TCP suffers from packet-level head-of-line blocking — if one TCP packet is lost, all streams stall until it's retransmitted. QUIC's per-stream framing means a lost packet only stalls the stream it belongs to. Particularly relevant for product pages that fetch many resources in parallel.
• Better congestion control: QUIC implements modern congestion control algorithms (BBR, CUBIC) in user space, allowing rapid iteration. Server operators can pick the right algorithm for their traffic pattern.

How to Verify You're on TLS 1.3 + HTTP/3

Chrome DevTools

Open DevTools → Network → click a request. The "Headers" tab shows the connection details. Look for:

• Protocol: should show h3 (HTTP/3) or at least h2 (HTTP/2).
• Security: click the Security tab. Should show TLS 1.3, not TLS 1.2. Cipher suite should be one of the AEAD-suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, or TLS_CHACHA20_POLY1305_SHA256.

Command Line

From a terminal: curl -sI --http3 https://yourstore.com — if HTTP/3 works, the response will succeed. If not, curl will fail or fall back to HTTP/2.

For TLS version: openssl s_client -connect yourstore.com:443 -tls1_3 — should connect successfully.

Online Test Tools

• SSL Labs (ssllabs.com/ssltest): tests TLS configuration, certificate health, and protocol support. Should show TLS 1.3 enabled.
• HTTP/3 Check (http3check.net): tests HTTP/3 support specifically.

Enabling TLS 1.3 and HTTP/3 on Your Platform

Shopify

Shopify enabled TLS 1.3 by default in 2020 and HTTP/3 in 2023. If your store is on Shopify, you should already be on both. Verify with the curl/DevTools checks above.

Cloudflare

Dashboard → SSL/TLS → Edge Certificates → enable "TLS 1.3" (should be on by default). Network → enable "HTTP/3 (with QUIC)". Both are free on all plans.

Vercel

TLS 1.3 is on by default. HTTP/3 is enabled on Vercel Edge Network as of 2023. No configuration needed.

AWS CloudFront

Distribution settings → Security policy → choose TLSv1.2_2021 or newer (TLS 1.3 is included as the highest supported). HTTP/3 (QUIC) requires enabling the "HTTP/3 supported" toggle, which is currently in preview as of late 2025.

WooCommerce / WordPress on Generic Hosting

Depends on the web server. Nginx 1.25+ supports HTTP/3 (with QUIC) experimentally. Apache 2.4 does not support HTTP/3 natively. Most ecommerce WP hosts route through Cloudflare or another CDN that handles HTTP/3 at the edge — the origin doesn't need to support it. Just verify the CDN is configured.

BigCommerce

Default platform configuration includes TLS 1.3. HTTP/3 was enabled via their Akamai CDN partnership in 2024. No customer configuration needed.

The Browser Compatibility Caveat

Not every browser uses HTTP/3 even when the server supports it. Browser usage as of 2026:

• Chrome / Edge (Chromium): HTTP/3 enabled by default since 2020. Will negotiate HTTP/3 if the server advertises it via the alt-svc header.
• Firefox: HTTP/3 enabled by default since 2021.
• Safari (macOS / iOS): HTTP/3 enabled by default since iOS 14 / Safari 14.
• Older browsers / corporate firewalls: may not support HTTP/3 and fall back to HTTP/2. They still benefit from TLS 1.3 if it's enabled.

The HTTP/3 negotiation: on the first response over HTTP/2, the server sends an alt-svc: h3=":443"; ma=86400 header. The browser remembers this for 24 hours (the ma value) and uses HTTP/3 for subsequent connections. The very first visit is still HTTP/2; the second visit and onward is HTTP/3.

This means: HTTP/3's benefit is greatest for returning visitors. For first-time visitors (cold connections), TLS 1.3 alone is the optimization that helps.

The Underlying Truth

TLS handshake cost is invisible in most performance dashboards. Vercel Speed Insights, Cloudflare Analytics, and Google Search Console don't break out "handshake time" as a separate metric — it's bundled into TTFB. Enabling TLS 1.3 and HTTP/3 reliably shaves 50–300ms off LCP for cold-connection visitors, and the work to enable them on most modern platforms is a two-click toggle. The combination of "high impact" and "low effort" makes this one of the highest-ROI performance optimizations available to ecommerce stores. The reason it gets skipped is the same reason a lot of foundational performance work gets skipped: it doesn't show up in any dashboard until you're already at the 95th percentile of optimization, by which point most stores have moved on to other projects.

Run a StoreVitals scan. We'll verify your store negotiates TLS 1.3, confirm HTTP/3 is advertised via alt-svc, check that your cipher suites include the modern AEAD options, and surface any mixed-content or TLS misconfiguration that would prevent the latest browsers from using the fastest available connection.