Notes on: Married to HTTP/3


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.
  • 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 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.

Unexpected Results

  • 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