FrontendHaltHTTP/2, HTTP/3, and connection performance
Understand multiplexing, header compression, and QUIC, and which HTTP/1-era frontend optimizations are now anti-patterns.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain http/2, http/3, and connection performance in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
HTTP/2 and HTTP/3 changed how requests travel — many requests share one connection instead of each needing its own, headers are compressed, and HTTP/3 moves off TCP onto QUIC to remove a head-of-line blocking problem. Several old frontend optimizations only exist to work around HTTP/1 limits and can now hurt.
One-line definition: Understand multiplexing, header compression, and QUIC, and which HTTP/1-era frontend optimizations are now anti-patterns.
02Mental model
HTTP/1.1 allowed roughly six parallel connections per origin, each with setup cost, so the community bundled aggressively and sharded across domains. HTTP/2 multiplexes many streams over one connection with header compression and prioritization, making small-file bundling and domain sharding counterproductive. HTTP/2 still suffers TCP head-of-line blocking. HTTP/3 runs over QUIC, giving independent stream loss recovery and faster setup, especially on lossy mobile networks.
03Step by step
- Confirm which protocol your CDN and origin actually serve — the frontend benefits are the CDN's job to enable.
- Stop sharding assets across multiple domains; it forces extra connections and defeats multiplexing.
- Loosen extreme bundling — dozens of tiny chunks are fine on H2/H3 and improve cache granularity.
- Use Link preload and 103 early hints to start critical requests before the HTML finishes.
- Keep connections warm to third-party origins you'll need with preconnect.
- Measure with the network panel's protocol column and real-user connection timings.
04Working example
<link rel="preconnect" href="https://api.example.com" /><link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin />
# Server, ideally as a 103 Early Hint:Link: </app.css>; rel=preload; as=stylepreconnect completes DNS, TCP, and TLS to an origin before the first request needs it; preload tells the browser to fetch a critical resource at high priority now rather than when the parser reaches it. Sent as a 103 Early Hint, the Link header lets the browser start fetching while the server is still generating the HTML.
05Where it is used
- Deciding whether legacy bundling and sharding optimizations still help or now hurt
- Speeding up first render by starting critical requests earlier
- Improving performance on lossy mobile networks via HTTP/3
- Reducing connection overhead to APIs and font or asset origins
06Common mistakes
- Sharding static assets across cdn1/cdn2/cdn3 domains, which multiplies connection setup and breaks H2 multiplexing and prioritization
- Bundling everything into one huge file to reduce requests on H2/H3, which wrecks caching and delays first execution
- Assuming HTTP/2 fixed head-of-line blocking — it moved it to the TCP layer; only HTTP/3 addresses it
- Preloading too many resources, which contends for bandwidth and delays the truly critical ones
07Interview answer
Name the specific mechanism — multiplexing, header compression, TCP vs QUIC head-of-line blocking — and call out which HTTP/1-era optimizations, like sharding and aggressive bundling, are now anti-patterns.
A team serves assets over HTTP/2 but still shards them across static1, static2, and static3 subdomains. Why is this now counterproductive?
Each subdomain requires its own connection setup and its own HTTP/2 session, which fragments the multiplexing and prioritization a single connection would handle better; the sharding only helped under HTTP/1's per-origin connection limit, which no longer applies.
DDConcept deep dives
Deep dive 1
HTTP/2 multiplexing invalidated the HTTP/1 optimization playbook
Under HTTP/1.1, roughly six connections per origin each carried one request at a time, so the community bundled aggressively, inlined assets, spliced images into sprites, and sharded across domains. HTTP/2 carries many concurrent streams over one connection with header compression and prioritization, so domain sharding now just adds handshakes and fragments prioritization, and extreme bundling hurts cache granularity and first-execution time.
- Consolidate assets onto one origin so a single connection can multiplex and prioritize them.
- Bundle less — route and vendor chunks — rather than one monolith or hundreds of tiny files.
- Sprite sheets and asset inlining were HTTP/1 workarounds and can usually be undone.
Deep dive 2
Head-of-line blocking moved down the stack, and HTTP/3 addresses it
HTTP/2 removed head-of-line blocking at the protocol level, but every stream still shares one TCP connection, so a single lost packet stalls all of them until it's retransmitted. HTTP/3 runs over QUIC on UDP, where each stream recovers from loss independently, plus it establishes connections faster and can survive a network change. The benefit is largest on lossy or changing mobile networks.
- 'We enabled HTTP/2' does not mean head-of-line blocking is gone — it moved to TCP.
- HTTP/3's gains show up most under packet loss and on mobile, less on a clean fast connection.
- The protocol is negotiated by the server and CDN; the frontend can't opt in from the page.
Deep dive 3
The frontend levers are about starting critical work earlier
Regardless of protocol version, the wins available from page code are: preconnect to warm up DNS, TCP, and TLS to origins you'll need; preload to fetch a critical resource the browser would otherwise discover late; and 103 Early Hints to let the browser preload while the server is still building the HTML. Overusing preload backfires by making everything contend for bandwidth.
- preconnect for origins; preload for specific critical files like the LCP image and a key font.
- Early Hints reclaim server think-time for useful network work.
- Preload only the handful of resources that are genuinely render-critical.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What problem did HTTP/2 multiplexing solve?Open model answer
Model answer
Under HTTP/1.1 a connection handled one request at a time, and browsers opened only about six connections per origin, so many resources queued. HTTP/2 lets many request-response streams share one connection concurrently, removing that per-connection serialization and the need for as many connections.
Open question page →Intermediate · Conceptual · 1 min · Question 2Why is domain sharding an anti-pattern under HTTP/2?Open model answer
Model answer
Sharding split assets across subdomains to get past the six-connection-per-origin limit. Under HTTP/2 that limit is gone, and each extra domain now costs a fresh DNS lookup, TCP handshake, and TLS negotiation, and fragments the single connection's multiplexing and prioritization.
Open question page →Advanced · Conceptual · 1 min · Question 3What is head-of-line blocking, and how do HTTP/2 and HTTP/3 differ on it?Open model answer
Model answer
It's when one delayed item blocks everything queued behind it. HTTP/2 removed it at the HTTP layer but all streams still ride one TCP connection, so a single lost packet stalls every stream until it's retransmitted. HTTP/3 runs over QUIC, where each stream's loss recovery is independent, so one lost packet only affects its own stream.
Open question page →Advanced · Conceptual · 1 min · Question 4What does QUIC bring beyond fixing TCP head-of-line blocking?Open model answer
Model answer
Faster connection establishment by combining transport and cryptographic handshakes (often 1-RTT, or 0-RTT on resumption), and connection migration, so a connection survives a network change like Wi-Fi to cellular without a full re-handshake. Both especially help mobile.
Open question page →Intermediate · Conceptual · 1 min · Question 5Does HTTP/2 make bundling unnecessary?Open model answer
Model answer
It makes aggressive bundling of many tiny files less necessary and often harmful, since per-request overhead is much lower and smaller files cache and invalidate more granularly. Some bundling still helps — reducing compression overhead and module-resolution cost — so the answer is 'bundle less', not 'don't bundle'.
Open question page →Advanced · Conceptual · 1 min · Question 6What is a 103 Early Hints response?Open model answer
Model answer
An informational status the server can send before the final response while it's still assembling the page, carrying Link headers that tell the browser to start preloading or preconnecting to critical resources. It reclaims the server's think-time for useful network work.
Open question page →Intermediate · Conceptual · 1 min · Question 7How do preconnect and preload differ?Open model answer
Model answer
preconnect performs the DNS, TCP, and TLS setup to an origin ahead of need, so the first request there is faster. preload actually fetches a specific resource now at high priority, for something the browser wouldn't discover early otherwise, like a font referenced deep in CSS.
Open question page →Advanced · Conceptual · 1 min · Question 8Can HTTP/2 server push improve performance?Open model answer
Model answer
In theory it let the server send resources before the client asked, but in practice it often pushed things already cached, wasting bandwidth, and was hard to tune. It has been deprecated or removed in major browsers in favor of preload and Early Hints.
Open question page →Intermediate · Conceptual · 1 min · Question 9How do you tell which protocol a resource actually used?Open model answer
Model answer
The browser's network panel has a protocol column showing h2, h3, or http/1.1 per request, and the connection view shows reuse. The protocol is negotiated during the connection, and support depends on the server and CDN, not the page.
Open question page →Beginner · Conceptual · 1 min · Question 10Does HTTP/3 replace the need for a CDN?Open model answer
Model answer
No. A CDN still provides geographic proximity, caching, and offload; HTTP/3 is a transport improvement the CDN itself terminates and benefits from. The two are complementary — a CDN with HTTP/3 support gives both proximity and efficient transport.
Open question page →SCScenario questions
Scenario 1
A site was optimized years ago: 40 sprite sheets, all JS concatenated into one 900KB file, assets sharded across three CDN subdomains. It now serves over HTTP/2 and performance has plateaued.
- Confirm the protocol actually in use for each asset origin.
- Consolidate the three asset subdomains onto one to restore multiplexing.
- Split the 900KB bundle along route and vendor boundaries for cache granularity and faster first execution.
- Replace sprite sheets with individually cached images, or SVG where appropriate.
- Add preconnect and preload for the genuinely critical early resources.
Reveal worked answer
Every one of those optimizations targets HTTP/1 constraints that no longer apply. I'd move the assets back to a single origin so the one HTTP/2 connection can multiplex and prioritize properly, then break the monolithic bundle into route and vendor chunks so a small change doesn't invalidate 900KB and the browser isn't parsing everything before first paint. Sprite sheets can become individual images since request overhead is cheap now. Finally I'd add preconnect to the API origin and preload the LCP image and critical font.