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
Adapting pages to HTTP/3
- 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
Setting up HTTP/3
- 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
Testing the Performance of HTTP/3
- To check if HTTP/3 is supported, use either HTTP3Check.net or
- 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.
- Know what the feature actually does. A deeper understanding is always helpful.
- Use a CDN
- Understand the limitations of your tools
- Hypothesize first, and always confirm with data