Notes on: Married to HTTP/3

June 21, 2022

At #SmashingConf San Francisco, Robin Marx gave a presentation about HTTP/3. Here are my notes.

HTTP/3 work started in 2012 with Google working on QUIC, adopted by IETF in 2017, RFC’s published in June 2022
All major browsers support thanks to iOS starting with version 16

What and Why?

HTTP/3 builds on top of UDP, not TCP
UDP often blocked as it is frequently used in attacks
The TLS + QUIC layer makes UDP safer to use, but a lot of networks will likely still block for awhile
HTTP/3 brings faster connection setup, better header compression, stream prioritization, packet loss handlnig, tunable congestion control, connection migration
Establishing a connection in HTTP/2 requires 3 RTT (round-trip times)
Establishing a connection in HTTP/3 only requires 2 RTT
HTTP/3 introduces 0 RTT mode which can reduce the total round trip to 1
In general, HTTP/3 is 1 to 2 RTTs faster than HTTP/2

Fewer domains: consolidate on 1-3 conenctions
Less bundling: 10-40 files is sufficient
Help the browser: async, defer, preload, preconnect, priority hints, lazy loading
No server push! Use 103 Early Hints instead

Easy way to setup HTTP/3: All major CDN’s provide HTTP/3, often with the flip of a switch.
Scalemates.com flipped the switch to enable HTTP/3 and almost immediately HTTP/3 traffic rose to ~13% of all requests on the landing page, ~49% for all pages in total
The RSVP problem: HTTP/3 might be blocked on the network or may not be enabled on the server. So the browser will only try HTTP/3 if it’s certain the server supports it.
For a new domain, the browser connects using H/1 or H/2. The server sends back an “alternative services” header indicating H/3 support. The browser stores alt-svc info in alt-svc cache. From then on, the browser tries HTTP/3 in parallel with HTTP/1 and 2 so that there’s an immediate fallback if the network blocks.
Setting up HTTP/3 on your own is much harder and server support is still improving

To check if HTTP/3 is supported, use either HTTP3Check.net or curl.
Browser devtools will also show you which protocol is being used for a given request.
Lighthouse and browser devtools are excellent tools, but not for network protocol throttling.
WebPageTest uses a built-in network throttling suite which provides much more realistic network throttling.
Because of the alt-svc process, testing to compare HTTP/2 and HTTP/3 is tricky.
A lot of browsers will start switching to the new HTTP/3 connection during page load
In WebPageTest, you can pass custom command-line commands to enable or disable quic for Chromium based brosers
Connection view is still a little buggy in HTTP/3, with SSL sometimes missing.
However, WebPageTest provides low-level packet trace and network logs that can surface exactly what is happening.

Protocol performance is rarely low0hanging fruit. You need a relatively optimized page to see impact, and even then it’s mainly going to benefit your 90th percentile and up.
Google Search with QUIC: p90 went down 6% on desktop, 5% on mobile. p99 went down 16% on desktop, 14% on mobile.
Wix saw TTFB (Time to First Byte) in India get 47.5% faster at p75, and 55% faster in Philippines.
Digging in though, TTFB metric was heaviliy influenced by the HTTP/2 connections including a DNS lookup and the HTTP/3 connections not including the DNS lookup.
Better than TTFB is to look at connection time (“honest TTFB”). Updating still saw improvements of ~30% faster at p75.
Wix also saw a 21% improvement in LCP (Largest Contentful Paint) at p75 on mobile
Microsoft found similar with Outlook: p90 saw a 30% faster “honest TTFB” and up to 64% faster at the p99.99
LoveHolidays saw a 18% faster TTFB at p75 when using HTTP/3 versus HTTP/2, but only 2% faster LCP.