skip to content

A team enabled HTTP/2 on their servers and page-load times barely moved. What kinds of workloads does HTTP/2 actually speed up, and which ones does it leave essentially unchanged?

level: middleimportance: must knowfreq 42%

answer

  1. benefit ~ request count x round-trip time
  2. h1.1 ~6 connections/origin -> request 7 queues
  3. one handshake, one congestion window, one HPACK table
  4. big files / few calls / low RTT -> no win
  5. undo domain sharding; connection coalescing partly saves you

basics

~20 s

HTTP/2 helps when many small requests go to one origin over a high-latency link: one connection, no six-connection cap, no client-side queueing, compressed headers. It barely helps a few large transfers, low-request-count APIs, or fast local networks, where the bottleneck is bandwidth or the server.

solid answer

~50 s

HTTP/2's wins are all about **per-request overhead and connection scarcity**: - Browsers cap HTTP/1.1 at roughly six connections per origin, so request seven waits. - Each HTTP/1.1 connection pays its own TCP and TLS handshakes and starts with a cold congestion window. One HTTP/2 connection warms up once. - HPACK removes hundreds of duplicated header bytes per request. So the profile that gains is: **many small resources, one origin, high round-trip time** - classic asset-heavy pages on mobile. The profiles that gain little: - A handful of large downloads or uploads: bandwidth-bound, one request each, header bytes irrelevant. - A backend API where a screen makes two or three calls: nothing was queued. - Fast local or datacenter links with sub-millisecond round trips - the queueing HTTP/2 removes cost almost nothing to begin with. - Anything whose real bottleneck is server think-time, render-blocking JavaScript, or an unindexed query. HTTP/2 also makes old HTTP/1.1 workarounds counterproductive: domain sharding now fragments the single connection and dilutes compression.

code

bash · 6 lines
bash
curl -sI --http2 https://example.com/app.js | head -1
# HTTP/2 200

# and from the proxy toward the origin, if you can reach it directly
curl -sI --http2 https://origin.internal/app.js | head -1
# HTTP/1.1 200   <-- front half h2, back half h1.1

go deeper

for a junior

Know that HTTP/2 multiplexes many requests over one connection and helps pages with lots of small assets, not big single downloads.

for a middle

Name the three costs removed - connection cap, repeated handshakes and cold congestion windows, header redundancy - and state that the win scales with request count and round-trip time.

for a senior

Diagnose a no-op rollout from the waterfall, verify negotiation on both legs, and identify HTTP/1.1 workarounds such as sharding and inlining that now need undoing.

for a principal

Express it as fixed-overhead reduction per request and decide where to spend effort instead - server think-time, caching, payload size - when the workload does not fit the profile.

## What HTTP/2 actually removes Three specific costs, and it is worth being precise because 'HTTP/2 is faster' is not an answer. **1. The per-origin connection limit.** Browsers open about six parallel HTTP/1.1 connections per origin. A page needing 60 assets processes them six at a time; the seventh request sits in a client-side queue while the network is idle. HTTP/2 multiplexes concurrent streams on one connection, so all 60 requests are in flight subject only to flow control and the server's concurrency limit. **2. Per-connection setup and congestion-window warm-up.** Every HTTP/1.1 connection pays a TCP handshake plus a TLS handshake and then starts with a small initial congestion window (typically 10 packets, about 14 KB). Six connections mean six warm-ups, six sets of round trips. One HTTP/2 connection pays once and the window grows for everyone. **3. Header redundancy.** HPACK collapses repeated `User-Agent`, `Accept-*` and `Cookie` bytes from roughly 700 per request to a handful. On a page with 100 requests over a narrow uplink, that is real time saved before requests even leave the device. Notice what all three have in common: they scale with **request count** and with **round-trip time**. That is the shape of the win. ## Where the win is large - Asset-heavy pages: many CSS, JS, font, image and icon requests to one origin. - Mobile and long-haul networks, where round trips are 50-200 ms so every avoided one is visible. - Anything issuing bursts of small requests - tile-based maps, sprite-free icon sets, chatty service-to-service calls over gRPC, which mandates HTTP/2 for exactly this reason. ## Where the win is small or zero - **Few large transfers.** One video segment, one big JSON export, one file upload: a single request each, bandwidth-bound. Multiplexing has nothing to multiplex and header compression is noise. - **Low request counts.** An API screen making three calls was never queued behind the six-connection cap. - **Low latency.** On a datacenter link with 0.3 ms round trips, the queueing HTTP/2 eliminates barely registers. - **Server-bound work.** If time-to-first-byte is 400 ms because of a slow query, transport concurrency changes nothing. - **Already-optimised HTTP/1.1 pages.** Sites that bundled aggressively already reduced request count to the point where HTTP/2's advantage is small. ## The anti-patterns HTTP/2 inverts HTTP/1.1 practice was to work around the connection cap: - **Domain sharding** - serving assets from img1, img2, img3 subdomains to get six connections each. Under HTTP/2 this is actively harmful: it splits traffic across several connections, each with its own cold congestion window and its own HPACK table, so compression and warm-up benefits are diluted. Modern browsers partially compensate with **connection coalescing** - reusing one connection for different hostnames that resolve to the same IP and are covered by the same certificate - but relying on that is fragile. - **Spriting and heavy concatenation** - less necessary; oversized bundles hurt caching granularity because one changed byte invalidates the whole bundle. - **Inlining assets into HTML** - makes the HTML uncacheable and duplicates bytes; usually worth undoing. ## Diagnosing 'we enabled it and nothing happened' Ask in order: how many requests per page view, to how many distinct origins, at what round-trip time, and where does the waterfall actually spend its time? If the waterfall shows long server think-time, or three requests total, or everything on a 1 ms link, HTTP/2 was never going to help and the measurement is correct rather than the deployment being broken. Also verify the protocol was actually negotiated - devtools' Protocol column - because a TLS-terminating proxy in front may be downgrading to HTTP/1.1 on the back half. ## Honest framing for an interview HTTP/2 is a **fixed-overhead reduction per request**, not a bandwidth improvement. Its benefit is roughly proportional to request count times round-trip time, minus whatever you already worked around by hand. Stating that relationship is worth more than reciting a feature list.

  • Should a site keep domain sharding after moving to HTTP/2?
    No. Sharding existed only to escape the roughly six-connections-per-origin limit, which HTTP/2 removes. Keeping it splits traffic over several connections, each paying its own handshake and cold congestion window and maintaining its own HPACK table, so compression and warm-up gains are diluted. Browser connection coalescing recovers some of this when the shards share an IP and certificate, but consolidating the origins is the real fix.
  • gRPC requires HTTP/2. Why does that make sense for service-to-service traffic even though round trips inside a datacenter are tiny?
    gRPC's needs are concurrency and streaming rather than latency: many concurrent RPCs must share one long-lived connection without head-of-line queueing, and bidirectional streaming needs interleaved frames in both directions, which HTTP/1.1 cannot express. Header compression also matters because RPC metadata repeats on every call and call rates are high.

HTTP/1.1 is six checkout lanes each with its own queue; HTTP/2 is one wide lane serving everyone at once. It transforms a crowd of shoppers holding one item each, and does nothing for four shoppers with full carts.

saying these in an interview costs you the question

  • Claiming HTTP/2 increases bandwidth or makes large downloads faster
  • Saying HTTP/2 removes all head-of-line blocking - it removes the HTTP-layer one, not TCP's
  • Keeping domain sharding 'because more connections are always better'
  • Assuming enabling h2 at the CDN means the origin leg is h2 too
  • Explaining the win without mentioning request count or round-trip time

context

resolving links…