HTTP/2 and HTTP/3 for Frontend

What H2/H3 change for waterfalls, prioritization, and why domain sharding died — frontend-relevant bits only.

advanced3 min readUpdated Aug 4, 2026

performance
http2
http3
networking
cdn

HTTP/2 and HTTP/3 change how browsers multiplex requests on a connection. Frontend bundles and host strategy should match the protocol era: stop H1-era hacks, lean on one strong origin, and still care about bytes and priorities.

Docs: web.dev HTTP/2, HTTP/3 overview, MDN HTTP.

Comparison for FE engineers

	HTTP/1.1	HTTP/2	HTTP/3
Multiplexing	~6 connections/origin	Many streams / connection	Many streams over QUIC
Head-of-line	TCP + H1	TCP HOL remains	Better under loss
Header compression	No	HPACK	QPACK
Encryption	Optional (practically TLS)	Practically always TLS	TLS 1.3 integrated

Enable H2/H3 on CDN/origin — not in React. Check Network panel protocol / h3.

Dead pattern: domain sharding

Splitting static1/2/3.example.com helped H1 connection limits. On H2/H3 it adds DNS/TLS cost and splits prioritization. Prefer one asset origin.

Still care about request count?

Yes, but differently. Hundreds of tiny modules without bundling create compression and priority overhead; over-bundling one multi‑MB file blocks useful parallelism for images. Balance: reasonable chunks + modern protocol + cache — code splitting.

Prioritization and hints

Browsers assign priorities (CSS high, async scripts lower, etc.). Help with:

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />
<script src="/analytics.js" defer></script>

H2 server push largely failed in practice; preload is the replacement story.

HTTP/3 benefits you’ll actually feel

Lossy mobile networks: QUIC recovers without stalling all streams like TCP HOL. Connection migration across network changes helps some mobile cases. Measure with field RUM by protocol when CDN supports it.

Frontend checklist

Confirm H2/H3 at edge for HTML and assets.
Collapse unnecessary hostnames; preconnect only critical third parties.
Compress and cache correctly.
Avoid anti-patterns from 2014 blogs (sharding, image spriting only for H1).
Spriting/inlining still have niche uses (icons) but not “because H1”.

Interview out-loud

“H2/H3 multiplex streams so domain sharding dies; I use one CDN origin, preload critical assets, and still minimize bytes. Protocol is edge config; frontend controls discovery, priority, and payload size.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.