HTTP/1.1 vs HTTP/2: What Actually Changes for Your Project

Have you ever wondered why bundling everything into a single JavaScript file was "best practice" in 2015, but today the recommendation is aggressive code splitting? The answer has three characters: H/2.

HTTP/2 changed the rules of the game. And understanding these differences affects real architecture decisions.

Mental Model Think of it like traffic engineering:

• HTTP/1.1 = single-lane road. One car at a time, and if you want more throughput you build 6 parallel roads (connections).
• HTTP/2 = multi-lane highway on the same asphalt. Many cars, no extra toll booths (handshakes).
• HTTP/3 = same highway, paved with a faster surface (UDP/QUIC instead of TCP). A pothole in one lane doesn't stop the others.

A bit of history: HTTP/1.1 landed in 1997 (yes, the Spice Girls era). HTTP/2 arrived in 2015, based on Google's SPDY experiments. HTTP/3 was formalized as RFC 9114 in June 2022. Each jump took roughly 18 and 7 years. The web moves fast, its plumbing doesn't.

The Fundamental Difference

HTTP/1.1 is text-based. One request at a time per connection. The browser opens up to 6 parallel connections per domain and that's it.

HTTP/2 is binary. Multiple streams on the same connection (multiplexing). Headers compressed with HPACK. Optional server push.

Why Multiplexing Changes Everything

HTTP/1.1 caps you at 6 simultaneous connections per domain. Request number 7 waits in the queue. HTTP/2 sends them all through the same connection without blocking.

Analogy: HTTP/1.1 is a supermarket with 6 checkouts. Customer 7 waits. HTTP/2 is a single checkout that scans 20 items in parallel.

This Changes Your Build Strategy

With HTTP/1.1, concatenating everything reduced the cost of multiple requests. With HTTP/2, smaller chunks mean better granular caching and parallel loading.

Backend: Implementing HTTP/2 in Node.js

Heads up: Server Push is effectively dead. Chrome removed HTTP/2 Server Push by default in version 106 (October 2022), and the other major browsers followed. The code above still runs, but clients will ignore the push. The modern replacement is 103 Early Hints, recommended by Chrome, Cloudflare and Fastly: it tells the browser "start preloading these assets while I finish building the HTML." Same intent, better track record.

In practice, most projects use Nginx as an HTTP/2 reverse proxy in front of an HTTP/1.1 backend:

server {
    listen 443 ssl http2;
    server_name api.example.com;
    location / {
        proxy_pass http://localhost:3000;  # HTTP/1.1 backend
    }
}

gRPC: Native HTTP/2

gRPC uses HTTP/2 as its native transport. Bidirectional streaming, binary protobuf, perfect for microservice communication:

Real Performance Numbers

• Latency (50 requests): HTTP/1.1 ~850ms vs HTTP/2 ~200ms (4x faster)
• Header overhead (100 requests): HTTP/1.1 ~80KB vs HTTP/2 ~8KB (HPACK compresses 10x)
• TCP connections per domain: HTTP/1.1 uses 6, HTTP/2 uses 1 (6x fewer handshakes)

Head-of-Line Blocking: The Remaining Problem

HTTP/2 solves Head-of-Line Blocking at the HTTP level with multiplexing. But the problem persists at the TCP level: if a single packet is lost, every stream stalls waiting for retransmission.

HTTP/3 sidesteps this by running over UDP via QUIC, with 0-RTT handshakes and connection migration (switch from Wi-Fi to 4G without reconnecting).

How to Check Which Version Your Site Uses

Three quick ways:

• Chrome DevTools: open the Network tab, right-click the columns header, enable "Protocol". You'll see h2, h3, or http/1.1 next to each request.
• Online: http2.pro or tools.keycdn.com/http2-test give a one-click verdict.

When to Use What

• HTTP/1.1: legacy applications, simple debugging, simple internal APIs.
• HTTP/2: modern web production, APIs with many requests, gRPC.
• HTTP/3: mobile-first apps, unstable connections, critical performance.

FAQ

Do I need to migrate to HTTP/3 right now? No. HTTP/2 covers 95% of use cases. HTTP/3 pays off mainly on mobile and lossy networks. If your CDN offers it for free, enable it and move on.

Is HTTPS mandatory for HTTP/2? Technically the spec allows h2c (cleartext), but no browser implements it. In practice: yes, HTTPS is mandatory. Same for HTTP/3.

My CDN already does this automatically, right? Usually yes. Cloudflare, Fastly, CloudFront and friends negotiate H/2 and H/3 by default at the edge. The backend behind them can stay on HTTP/1.1 without drama.

Does bundle size still matter with HTTP/2? Yes, just for different reasons. Multiplexing solves the request cost, but parse, compile and execution time on the client are still linear with size. Ship less JavaScript, period.

gRPC vs gRPC-Web, which one? gRPC for server-to-server (needs raw HTTP/2 trailers, which browsers can't access). gRPC-Web for browser clients: a proxy-friendly variant that runs over normal HTTP/1.1 or HTTP/2 requests. Different tools, same IDL.

Key Takeaways

HTTP/2 isn't a marginal optimization. It changes how you structure builds (code splitting > bundling), how you fire parallel requests (no 6-connection limit), and unlocks patterns like gRPC and Early Hints. If your site is still on HTTP/1.1, migrating is probably the easiest performance win you can ship this quarter.