Web hosting
HTTP/2 vs HTTP/3 for websites: what changes and what to measure
HTTP/2 and HTTP/3 change connection and multiplexing behavior, but protocol labels alone do not make a site fast. The useful decision is whether clients can negotiate the protocols reliably and whether application, caching, payload, or origin latency remains the dominant cost.
Verify public negotiation
Use browser network tools, curl with protocol support, or a TLS/HTTP checker to see whether the public endpoint serves h2 and/or h3. HTTP/2 normally negotiates via ALPN over TLS; HTTP/3 uses QUIC/UDP and can be advertised through Alt-Svc.
A reverse proxy/CDN may serve a newer protocol to clients while using HTTP/1.1 to the origin.
Understand what multiplexing changes
HTTP/2 can carry many streams on one TCP connection and compress headers; HTTP/3 moves transport to QUIC and avoids TCP-level head-of-line blocking across streams. Neither removes application server time or huge asset bytes.
Old “domain sharding” or concatenation tactics may be unnecessary or harmful under multiplexed connections.
Check firewall and UDP reachability for HTTP/3
QUIC generally uses UDP/443. Restrictive networks may fall back to HTTP/2/1.1, so the service should remain correct when HTTP/3 is unavailable.
Do not block TCP/443 because HTTP/3 is enabled.
Measure real page and API behavior
Compare connection setup, TTFB, transfer, concurrency, loss sensitivity, and browser waterfall. Optimize origin/cache/assets first when protocol negotiation is not the bottleneck.
- Verify negotiated protocol publicly.
- Keep fallback paths working.
- Allow required UDP for QUIC.
- Measure application impact, not protocol badge.