Performance Issues — HTTP/1.1: The Foundation… | OneNoughtOne

0/240

Computer NetworksHTTP/1.1

HTTP/1.1: The Foundation of Modern Web Communication

LevelIntermediate

Duration75 mins

TopicHTTP/1.1

5 / 5

Performance Issues

The Limits of HTTP/1.1

HTTP/1.1 was a remarkable improvement over its predecessor. Persistent connections eliminated connection-per-request overhead. Chunked encoding enabled streaming. The Host header made virtual hosting possible. These innovations served the web well for over 15 years. But as the web evolved—pages grew from kilobytes to megabytes, from a handful of resources to hundreds—HTTP/1.1's fundamental architecture became a bottleneck. By the early 2010s, loading a typical web page meant: 100+ HTTP requests for HTML, CSS, JavaScript, images, fonts, and APIs 6 parallel TCP connections per host (browser limit) Megabytes of redundant headers sent with each request Complex workarounds that obscured application logic This page examines HTTP/1.1's inherent performance limitations: why they exist, how they manifest in practice, the workarounds developers employed, and why these limitations ultimately demanded a new protocol.

What You Will Learn

This page provides deep analysis of HTTP/1.1's performance constraints: head-of-line blocking at both HTTP and TCP layers, connection limits and their implications, header overhead and redundancy, the workarounds that became standard practice, and how these limitations informed HTTP/2's design.

Head-of-Line Blocking Revisited

We discussed pipelining's head-of-line (HOL) blocking earlier, but the problem runs deeper than pipelining's failure. Even without pipelining, HTTP/1.1 suffers from HOL blocking at multiple levels. HTTP-layer HOL blocking (without pipelining): With stop-and-wait semantics, each connection processes one request at a time. If Request A is slow to respond, Request B must wait—even though they're unrelated: Connection 1: [Request A: 3 seconds] \to [Request B: 10ms] \to [Request C: 10ms] Total: 3.02 seconds If Request A were last: [Request B: 10ms] \to [Request C: 10ms] \to [Request A: 3 seconds] Total: 3.02 seconds, but B and C complete in 20ms The ordering of requests dramatically affects user-perceived performance, even when total time is identical.

TCP-layer HOL blocking: HTTP/1.1 runs over TCP, which guarantees in-order, reliable byte stream delivery. If any TCP segment is lost, TCP must retransmit it before delivering subsequent segments—even if those later segments arrived intact. TCP segments: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ↑ Segment 2 lost Application receives: [1] ... waiting ... TCP waits for segment 2 retransmission Segments 3-10 are buffered but not delivered After retransmit: Application receives: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] If segment 2 contained bytes from Response A, but segments 3-10 contained Response B, Response B is blocked by A's lost packet—even though B arrived completely.

Converting Mermaid diagram...

Why Multiple Connections Don't Fully Solve HOL

Using multiple TCP connections (up to 6 per host) mitigates HTTP-layer HOL blocking by allowing parallel requests. However, TCP-layer HOL blocking persists on each connection. On lossy networks (mobile, WiFi), packet loss on one connection still blocks that connection's responses. HTTP/2 makes this worse by putting everything on one connection; QUIC (HTTP/3) solves it with per-stream loss recovery.

Quantifying HOL blocking impact: Research by Google and others measured HOL blocking effects:

Network Condition	Packet Loss Rate	Average HOL Block Duration
Good wired	0.1%	15-50ms
Average WiFi	1-2%	100-500ms
Poor mobile (3G)	2-5%	500ms-2s
Congested network	5-10%	1-5s

On lossy networks, users experience significant delays from HOL blocking alone—separate from actual retransmission time.

Connection Limits and Constrained Parallelism

HTTP/1.1's request-response model means each connection can only have one request in flight at a time (assuming no pipelining, which is effectively the case). To achieve parallelism, clients must open multiple connections. The browser connection limit evolution:

Era	Browser	Connections per Host	Total Connections
1999	HTTP/1.1 spec recommends	2	Not specified
2005	IE6, Firefox 1.x	2	8-24
2008	IE8, Firefox 3	6	30-35
2012	Chrome, Firefox, Safari	6	256
Today	All major browsers	6	256+

The 6-connection limit became the practical standard—a compromise between parallelism benefits and server resource consumption.

Why connection limits matter: Consider loading a page with 60 resources from one domain: 6 parallel connections, 60 resources \to 10 "rounds" of requests \to Each round waits for previous to complete \to Heavily dependent on slowest resource per round Time = Σ(max response time in each round) With unlimited connections: \to All 60 requests in parallel \to Time = max(all 60 response times) The connection limit serializes work that could theoretically happen in parallel, directly increasing page load time.

connection-limit-simulation.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// Simulating page load with connection limits
interface Resource {
    url: string;
    size: number;       // bytes
    serverTime: number; // ms to generate
}
 
function simulatePageLoad(
    resources: Resource[],
    connectionsPerHost: number,
    bandwidth: number,  // bytes/ms
    rtt: number         // ms
): number {
    // Separate resources by host
    const byHost = groupBy(resources, r => new URL(r.url).host);
    
    let totalTime = 0;
    
    for (const [host, hostResources] of Object.entries(byHost)) {
        // Process in rounds of N connections
        for (let i = 0; i < hostResources.length; i += connectionsPerHost) {
            const batch = hostResources.slice(i, i + connectionsPerHost);
            
            // Time for this batch = max time among parallel requests
            const batchTime = Math.max(...batch.map(r => {
                const transmissionTime = r.size / bandwidth;
                return rtt + r.serverTime + transmissionTime;
            }));
            
            totalTime += batchTime;
        }
    }
    
    return totalTime;
}
 
// Example: 60 resources, 100KB each, 10ms server time
const resources = Array(60).fill(null).map((_, i) => ({
    url: `https://example.com/resource${i}`,
    size: 100 * 1024,
    serverTime: 10
}));
 
const bandwidth = 10 * 1024;  // 10 KB/ms (≈80 Mbps)
const rtt = 50;               // 50ms RTT
 
// With 6 connections: 10 sequential batches
const time6Conn = simulatePageLoad(resources, 6, bandwidth, rtt);
// ≈ 10 * (50 + 10 + 100) = 1600ms
 
// With unlimited: 1 batch of 60
const timeUnlimited = simulatePageLoad(resources, 60, bandwidth, rtt);
// ≈ 1 * (50 + 10 + 100) = 160ms
 
console.log(`6 connections: ${time6Conn}ms`);
console.log(`Unlimited: ${timeUnlimited}ms`);
console.log(`Overhead: ${(time6Conn / timeUnlimited - 1) * 100}%`);

The Domain Sharding Workaround

Developers discovered that the 6-connection limit is per-host, not per-server. By distributing resources across multiple subdomains (static1.example.com, static2.example.com, etc.), sites could achieve 6 \times N connections. This "domain sharding" became standard practice despite its downsides: additional DNS lookups, no connection reuse across shards, and increased TLS overhead.

Header Overhead and Redundancy

HTTP/1.1 headers are sent as plain text with every request and response. This seemingly simple format causes significant overhead in modern web applications. Typical request header sizes: A typical browser request includes many standard headers: GET /api/products/12345 HTTP/1.1 Host: api.example.com Connection: keep-alive Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Accept-Language: en-US,en;q=0.9,es;q=0.8 Accept-Encoding: gzip, deflate, br Referer: https://example.com/shop Cookie: session_id=abc123def456; preferences=dark_mode; tracking_id=xyz789; ab_test_group=variant_a; cart_items=5; user_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U If-None-Match: "a1b2c3d4e5f6" Cache-Control: no-cache Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors This single request is ~1,200 bytes of headers —often larger than the response body for small API requests.

Header Size Analysis for Typical Page Load
Metric	Value	Impact
Requests per page	100-200	Average modern web page
Avg request headers	800-2000 bytes	Varies with cookies, auth
Avg response headers	400-800 bytes	Cache, security headers
Total header traffic	150-500 KB	Per page load
Header % of small responses	50-90%	For <1KB API responses
Redundant headers	80-95%	Same headers repeated

The redundancy problem: HTTP/1.1 has no concept of header compression or state. Every request to the same host sends the same cookies, User-Agent, Accept headers—even though they haven't changed since the previous request milliseconds ago. Request 1: 1,200 bytes of headers \to /api/user Request 2: 1,200 bytes of headers \to /api/products (same headers!) Request 3: 1,200 bytes of headers \to /api/cart (same headers!) ... Request 100: 1,200 bytes of headers \to /api/recommendations Total: 120KB of headers for 100 requests Unique information: <5KB (paths differ) Wasted: 115KB (95%) repeating identical headers

HTTP/1.1 Header Problems

•Plain text (no compression)
•No state between requests
•Cookies sent with every request
•User-Agent is ~200 bytes alone
•Headers often larger than body

HTTP/2 HPACK Solution

•Binary format + Huffman encoding
•Dynamic header table caches values
•Cookies sent once, referenced after
•Static table for common headers
•90%+ header size reduction

Cookie Overhead Example

A site with analytics, A/B testing, session management, and third-party integrations might have 4-8 KB of cookies. These cookies are sent with every single request to that domain—including requests for tiny 500-byte images. For an image-heavy page, cookies alone might exceed the total image size.

TCP Connection Establishment Overhead

While persistent connections mitigate TCP handshake costs, HTTP/1.1's multiple-connection model still incurs significant overhead—especially with TLS. TCP + TLS establishment costs per connection:

Phase	Round Trips	50ms RTT	200ms RTT
TCP handshake	1.5 RTT	75ms	300ms
TLS 1.2 handshake	2 RTT	100ms	400ms
TLS 1.3 handshake	1 RTT	50ms	200ms
Total (TLS 1.2)	3.5 RTT	175ms	700ms
Total (TLS 1.3)	2.5 RTT	125ms	500ms

With domain sharding using 4 domains: 4 TCP connections \times 3.5 RTT = 14 RTTs of handshake overhead On 200ms RTT: 2.8 seconds before first HTTP request

TCP slow start compounds the problem: Each new TCP connection starts with a small congestion window (typically 10 segments \approx 14 KB). The connection must "probe" for available bandwidth: RTT 1: Send 14 KB, receive ACKs RTT 2: Send 28 KB, receive ACKs RTT 3: Send 56 KB, receive ACKs Continue doubling until congestion detected For a 100 KB resource, slow start alone requires ~4 RTTs to complete transmission. With 6 connections, this ramp-up happens independently on each—wasting bandwidth during the critical early phase of page load.

Converting Mermaid diagram...

HTTP/2's Single Connection Advantage

HTTP/2 multiplexes all requests over a single connection. This means: one TCP handshake, one TLS handshake, one slow start ramp-up. The connection "warms up" quickly and maintains optimal throughput for all subsequent requests—a dramatic efficiency improvement.

The Workaround Era: Anti-Patterns as Best Practices

HTTP/1.1's limitations spawned an entire category of "performance optimizations" that were really workarounds for protocol constraints. These techniques became industry best practices despite being architecturally questionable. Domain Sharding: Distributing resources across multiple subdomains to bypass the 6-connection-per-host limit: # Instead of: https://example.com/assets/style.css https://example.com/assets/app.js https://example.com/assets/logo.png # Use sharding: https://static1.example.com/assets/style.css https://static2.example.com/assets/app.js https://static3.example.com/assets/logo.png # Result: 18 connections instead of 6 Cost of sharding: Additional DNS lookups for each shard No connection reuse across shards Additional TLS handshakes Cookie isolation complexity CDN configuration overhead

Resource Bundling: Combining multiple resources into single files to reduce request count: // Instead of 20 separate HTTP requests: // GET /js/utils.js // GET /js/components/button.js // GET /js/components/modal.js // ... (17 more) // Bundle into one request: // GET /js/bundle.js (concatenated file) Cost of bundling: Any change invalidates entire bundle cache Users download unused code Build complexity increases Source maps needed for debugging Harder to lazy-load granularly

HTTP/1.1 Workarounds and Their Costs
Workaround	Problem Addressed	Negative Consequences
Domain Sharding	6-connection limit	DNS lookups, TLS overhead, no sharing
Bundling JS/CSS	Request count	Cache invalidation, dead code, build complexity
Image Sprites	Request count	Complex CSS, full sprite download, update difficulty
Inline Resources	Critical CSS/JS requests	No caching, HTML bloat, maintenance burden
Resource Prefetching	Waterfall loading	Bandwidth waste, prediction errors
Cookie-less Domains	Header overhead	Multiple domains, CORS complexity

Workarounds That Hurt HTTP/2

Many HTTP/1.1 workarounds actively harm HTTP/2 performance. Domain sharding prevents connection coalescing. Large bundles prevent efficient resource prioritization. Inlined resources can't be cached separately. Sites optimized for HTTP/1.1 often need to be re-optimized when upgrading to HTTP/2.

Real-World Performance Analysis

Studies and measurements from major tech companies quantified HTTP/1.1's performance impact and motivated the development of HTTP/2. Google's SPDY measurements (2012): Google engineers measured page load times across thousands of sites, comparing HTTP/1.1 with their experimental SPDY protocol:

Metric	HTTP/1.1	SPDY	Improvement
Page load time (median)	2.4s	1.8s	25% faster
Time to first paint	1.2s	0.8s	33% faster
Header bytes transferred	800 KB	50 KB	94% reduction
Connections per page	18	1	94% reduction

The header compression and multiplexing from SPDY (which became HTTP/2) delivered substantial real-world improvements.

HTTP Archive analysis: The HTTP Archive tracks web page composition over time. Trends show why HTTP/1.1 struggled:

Year	Requests per Page	Total Page Size	Domains per Page
2010	56	702 KB	9
2015	95	2,000 KB	22
2020	74	2,100 KB	20
2023	71	2,400 KB	18

While request counts stabilized (partly due to bundling), the sheer number of resources and domains remained a challenge for HTTP/1.1's connection model.

waterfall-analysis.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Typical HTTP/1.1 waterfall pattern (simplified)
 
Time →
|--TCP+TLS--|--HTML--|
            |--CSS--|
                    |--CSS--|
                            |--JS--|
                                   |--JS--|
                                          |--Image--|
                                                    |--Image--|
 
What's happening:
1. Initial connection + HTML fetch: ~400ms
2. Browser parses HTML, discovers resources
3. CSS files block rendering (critical path)
4. JS files may block on CSS completion
5. Images load after render-blocking resources
 
Problems visible:
- Resources discovered late in HTML can't start early
- Critical CSS/JS compete for 6 connection slots
- Non-critical resources block critical ones
- Slow resources in one batch delay next batch
 
With HTTP/2 multiplexing:
|--TCP+TLS--|
            |--HTML--|
            |--CSS-1--|--CSS-2--|
            |--JS-1--|--JS-2--|
            |--IMG-1--|--IMG-2--|--IMG-3--|
 
All requests start immediately after HTML discovery
Priority system ensures critical resources first
One connection, shared bandwidth, no round-trip serialization

The Mobile Penalty

HTTP/1.1's overhead is particularly punishing on mobile networks: higher RTTs amplify connection setup costs, packet loss triggers more HOL blocking, bandwidth limitations make header overhead more impactful, and battery constraints penalize multiple connections. Mobile performance was a primary driver for HTTP/2 development.

The Path to HTTP/2

HTTP/1.1's limitations ultimately drove the development of HTTP/2. Understanding what HTTP/2 fixed illuminates what was broken in HTTP/1.1. HTTP/2's solutions to HTTP/1.1 problems:

HTTP/1.1 Problems → HTTP/2 Solutions
HTTP/1.1 Problem	HTTP/2 Solution	Improvement
One request per connection	Multiplexed streams	Unlimited concurrent requests
6-connection limit	Single multiplexed connection	No artificial limits
HTTP HOL blocking	Independent streams	Slow response doesn't block others
Uncompressed headers	HPACK compression	90%+ header size reduction
Header repetition	Header table state	Send differences only
No prioritization	Stream priority weights	Critical resources first
Client-initiated only	Server push	Proactive resource delivery
Text protocol	Binary framing	Efficient parsing, less ambiguity

What HTTP/2 doesn't fix: HTTP/2 solved HTTP-layer problems but inherited TCP's limitations: TCP HOL blocking — A lost packet still blocks the entire connection. HTTP/2's single-connection model actually makes this worse than HTTP/1.1's multiple connections. TCP handshake cost — Still required, though only once per connection. TLS handshake cost — Still required, though HTTP/2 mandates TLS in practice. Middlebox incompatibility — Some proxies/firewalls mishandle HTTP/2 negotiation. These TCP limitations are why QUIC (HTTP/3) was developed—a UDP-based transport with built-in encryption, multiplexing, and per-stream loss recovery.

Lessons from HTTP/1.1's Evolution

HTTP/1.1's performance history teaches important lessons: protocol design has long-term consequences, workarounds become entrenched practices, the web grows faster than protocols evolve, and layering (HTTP over TCP) constrains optimization. HTTP/2 and HTTP/3 reflect these lessons, designing for parallel workloads from the start.

Computer NetworksHTTP/1.1

HTTP/1.1: The Foundation of Modern Web Communication

LevelIntermediate

Duration75 mins

TopicHTTP/1.1

5 / 5

Performance Issues

The Limits of HTTP/1.1

HTTP/1.1 was a remarkable improvement over its predecessor. Persistent connections eliminated connection-per-request overhead. Chunked encoding enabled streaming. The Host header made virtual hosting possible. These innovations served the web well for over 15 years. But as the web evolved—pages grew from kilobytes to megabytes, from a handful of resources to hundreds—HTTP/1.1's fundamental architecture became a bottleneck. By the early 2010s, loading a typical web page meant: 100+ HTTP requests for HTML, CSS, JavaScript, images, fonts, and APIs 6 parallel TCP connections per host (browser limit) Megabytes of redundant headers sent with each request Complex workarounds that obscured application logic This page examines HTTP/1.1's inherent performance limitations: why they exist, how they manifest in practice, the workarounds developers employed, and why these limitations ultimately demanded a new protocol.

What You Will Learn

This page provides deep analysis of HTTP/1.1's performance constraints: head-of-line blocking at both HTTP and TCP layers, connection limits and their implications, header overhead and redundancy, the workarounds that became standard practice, and how these limitations informed HTTP/2's design.

Head-of-Line Blocking Revisited

We discussed pipelining's head-of-line (HOL) blocking earlier, but the problem runs deeper than pipelining's failure. Even without pipelining, HTTP/1.1 suffers from HOL blocking at multiple levels. HTTP-layer HOL blocking (without pipelining): With stop-and-wait semantics, each connection processes one request at a time. If Request A is slow to respond, Request B must wait—even though they're unrelated: Connection 1: [Request A: 3 seconds] \to [Request B: 10ms] \to [Request C: 10ms] Total: 3.02 seconds If Request A were last: [Request B: 10ms] \to [Request C: 10ms] \to [Request A: 3 seconds] Total: 3.02 seconds, but B and C complete in 20ms The ordering of requests dramatically affects user-perceived performance, even when total time is identical.

TCP-layer HOL blocking: HTTP/1.1 runs over TCP, which guarantees in-order, reliable byte stream delivery. If any TCP segment is lost, TCP must retransmit it before delivering subsequent segments—even if those later segments arrived intact. TCP segments: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ↑ Segment 2 lost Application receives: [1] ... waiting ... TCP waits for segment 2 retransmission Segments 3-10 are buffered but not delivered After retransmit: Application receives: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] If segment 2 contained bytes from Response A, but segments 3-10 contained Response B, Response B is blocked by A's lost packet—even though B arrived completely.

Converting Mermaid diagram...

Why Multiple Connections Don't Fully Solve HOL

Using multiple TCP connections (up to 6 per host) mitigates HTTP-layer HOL blocking by allowing parallel requests. However, TCP-layer HOL blocking persists on each connection. On lossy networks (mobile, WiFi), packet loss on one connection still blocks that connection's responses. HTTP/2 makes this worse by putting everything on one connection; QUIC (HTTP/3) solves it with per-stream loss recovery.

Quantifying HOL blocking impact: Research by Google and others measured HOL blocking effects:

Network Condition	Packet Loss Rate	Average HOL Block Duration
Good wired	0.1%	15-50ms
Average WiFi	1-2%	100-500ms
Poor mobile (3G)	2-5%	500ms-2s
Congested network	5-10%	1-5s

On lossy networks, users experience significant delays from HOL blocking alone—separate from actual retransmission time.

Connection Limits and Constrained Parallelism

HTTP/1.1's request-response model means each connection can only have one request in flight at a time (assuming no pipelining, which is effectively the case). To achieve parallelism, clients must open multiple connections. The browser connection limit evolution:

Era	Browser	Connections per Host	Total Connections
1999	HTTP/1.1 spec recommends	2	Not specified
2005	IE6, Firefox 1.x	2	8-24
2008	IE8, Firefox 3	6	30-35
2012	Chrome, Firefox, Safari	6	256
Today	All major browsers	6	256+

The 6-connection limit became the practical standard—a compromise between parallelism benefits and server resource consumption.

Why connection limits matter: Consider loading a page with 60 resources from one domain: 6 parallel connections, 60 resources \to 10 "rounds" of requests \to Each round waits for previous to complete \to Heavily dependent on slowest resource per round Time = Σ(max response time in each round) With unlimited connections: \to All 60 requests in parallel \to Time = max(all 60 response times) The connection limit serializes work that could theoretically happen in parallel, directly increasing page load time.

connection-limit-simulation.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// Simulating page load with connection limits
interface Resource {
    url: string;
    size: number;       // bytes
    serverTime: number; // ms to generate
}
 
function simulatePageLoad(
    resources: Resource[],
    connectionsPerHost: number,
    bandwidth: number,  // bytes/ms
    rtt: number         // ms
): number {
    // Separate resources by host
    const byHost = groupBy(resources, r => new URL(r.url).host);
    
    let totalTime = 0;
    
    for (const [host, hostResources] of Object.entries(byHost)) {
        // Process in rounds of N connections
        for (let i = 0; i < hostResources.length; i += connectionsPerHost) {
            const batch = hostResources.slice(i, i + connectionsPerHost);
            
            // Time for this batch = max time among parallel requests
            const batchTime = Math.max(...batch.map(r => {
                const transmissionTime = r.size / bandwidth;
                return rtt + r.serverTime + transmissionTime;
            }));
            
            totalTime += batchTime;
        }
    }
    
    return totalTime;
}
 
// Example: 60 resources, 100KB each, 10ms server time
const resources = Array(60).fill(null).map((_, i) => ({
    url: `https://example.com/resource${i}`,
    size: 100 * 1024,
    serverTime: 10
}));
 
const bandwidth = 10 * 1024;  // 10 KB/ms (≈80 Mbps)
const rtt = 50;               // 50ms RTT
 
// With 6 connections: 10 sequential batches
const time6Conn = simulatePageLoad(resources, 6, bandwidth, rtt);
// ≈ 10 * (50 + 10 + 100) = 1600ms
 
// With unlimited: 1 batch of 60
const timeUnlimited = simulatePageLoad(resources, 60, bandwidth, rtt);
// ≈ 1 * (50 + 10 + 100) = 160ms
 
console.log(`6 connections: ${time6Conn}ms`);
console.log(`Unlimited: ${timeUnlimited}ms`);
console.log(`Overhead: ${(time6Conn / timeUnlimited - 1) * 100}%`);

The Domain Sharding Workaround

Developers discovered that the 6-connection limit is per-host, not per-server. By distributing resources across multiple subdomains (static1.example.com, static2.example.com, etc.), sites could achieve 6 \times N connections. This "domain sharding" became standard practice despite its downsides: additional DNS lookups, no connection reuse across shards, and increased TLS overhead.

Header Overhead and Redundancy

HTTP/1.1 headers are sent as plain text with every request and response. This seemingly simple format causes significant overhead in modern web applications. Typical request header sizes: A typical browser request includes many standard headers: GET /api/products/12345 HTTP/1.1 Host: api.example.com Connection: keep-alive Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Accept-Language: en-US,en;q=0.9,es;q=0.8 Accept-Encoding: gzip, deflate, br Referer: https://example.com/shop Cookie: session_id=abc123def456; preferences=dark_mode; tracking_id=xyz789; ab_test_group=variant_a; cart_items=5; user_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U If-None-Match: "a1b2c3d4e5f6" Cache-Control: no-cache Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors This single request is ~1,200 bytes of headers —often larger than the response body for small API requests.

Header Size Analysis for Typical Page Load
Metric	Value	Impact
Requests per page	100-200	Average modern web page
Avg request headers	800-2000 bytes	Varies with cookies, auth
Avg response headers	400-800 bytes	Cache, security headers
Total header traffic	150-500 KB	Per page load
Header % of small responses	50-90%	For <1KB API responses
Redundant headers	80-95%	Same headers repeated

The redundancy problem: HTTP/1.1 has no concept of header compression or state. Every request to the same host sends the same cookies, User-Agent, Accept headers—even though they haven't changed since the previous request milliseconds ago. Request 1: 1,200 bytes of headers \to /api/user Request 2: 1,200 bytes of headers \to /api/products (same headers!) Request 3: 1,200 bytes of headers \to /api/cart (same headers!) ... Request 100: 1,200 bytes of headers \to /api/recommendations Total: 120KB of headers for 100 requests Unique information: <5KB (paths differ) Wasted: 115KB (95%) repeating identical headers

HTTP/1.1 Header Problems

•Plain text (no compression)
•No state between requests
•Cookies sent with every request
•User-Agent is ~200 bytes alone
•Headers often larger than body

HTTP/2 HPACK Solution

•Binary format + Huffman encoding
•Dynamic header table caches values
•Cookies sent once, referenced after
•Static table for common headers
•90%+ header size reduction

Cookie Overhead Example

A site with analytics, A/B testing, session management, and third-party integrations might have 4-8 KB of cookies. These cookies are sent with every single request to that domain—including requests for tiny 500-byte images. For an image-heavy page, cookies alone might exceed the total image size.

TCP Connection Establishment Overhead

While persistent connections mitigate TCP handshake costs, HTTP/1.1's multiple-connection model still incurs significant overhead—especially with TLS. TCP + TLS establishment costs per connection:

Phase	Round Trips	50ms RTT	200ms RTT
TCP handshake	1.5 RTT	75ms	300ms
TLS 1.2 handshake	2 RTT	100ms	400ms
TLS 1.3 handshake	1 RTT	50ms	200ms
Total (TLS 1.2)	3.5 RTT	175ms	700ms
Total (TLS 1.3)	2.5 RTT	125ms	500ms

With domain sharding using 4 domains: 4 TCP connections \times 3.5 RTT = 14 RTTs of handshake overhead On 200ms RTT: 2.8 seconds before first HTTP request

TCP slow start compounds the problem: Each new TCP connection starts with a small congestion window (typically 10 segments \approx 14 KB). The connection must "probe" for available bandwidth: RTT 1: Send 14 KB, receive ACKs RTT 2: Send 28 KB, receive ACKs RTT 3: Send 56 KB, receive ACKs Continue doubling until congestion detected For a 100 KB resource, slow start alone requires ~4 RTTs to complete transmission. With 6 connections, this ramp-up happens independently on each—wasting bandwidth during the critical early phase of page load.

Converting Mermaid diagram...

HTTP/2's Single Connection Advantage

HTTP/2 multiplexes all requests over a single connection. This means: one TCP handshake, one TLS handshake, one slow start ramp-up. The connection "warms up" quickly and maintains optimal throughput for all subsequent requests—a dramatic efficiency improvement.

The Workaround Era: Anti-Patterns as Best Practices

HTTP/1.1's limitations spawned an entire category of "performance optimizations" that were really workarounds for protocol constraints. These techniques became industry best practices despite being architecturally questionable. Domain Sharding: Distributing resources across multiple subdomains to bypass the 6-connection-per-host limit: # Instead of: https://example.com/assets/style.css https://example.com/assets/app.js https://example.com/assets/logo.png # Use sharding: https://static1.example.com/assets/style.css https://static2.example.com/assets/app.js https://static3.example.com/assets/logo.png # Result: 18 connections instead of 6 Cost of sharding: Additional DNS lookups for each shard No connection reuse across shards Additional TLS handshakes Cookie isolation complexity CDN configuration overhead

Resource Bundling: Combining multiple resources into single files to reduce request count: // Instead of 20 separate HTTP requests: // GET /js/utils.js // GET /js/components/button.js // GET /js/components/modal.js // ... (17 more) // Bundle into one request: // GET /js/bundle.js (concatenated file) Cost of bundling: Any change invalidates entire bundle cache Users download unused code Build complexity increases Source maps needed for debugging Harder to lazy-load granularly

HTTP/1.1 Workarounds and Their Costs
Workaround	Problem Addressed	Negative Consequences
Domain Sharding	6-connection limit	DNS lookups, TLS overhead, no sharing
Bundling JS/CSS	Request count	Cache invalidation, dead code, build complexity
Image Sprites	Request count	Complex CSS, full sprite download, update difficulty
Inline Resources	Critical CSS/JS requests	No caching, HTML bloat, maintenance burden
Resource Prefetching	Waterfall loading	Bandwidth waste, prediction errors
Cookie-less Domains	Header overhead	Multiple domains, CORS complexity

Workarounds That Hurt HTTP/2

Many HTTP/1.1 workarounds actively harm HTTP/2 performance. Domain sharding prevents connection coalescing. Large bundles prevent efficient resource prioritization. Inlined resources can't be cached separately. Sites optimized for HTTP/1.1 often need to be re-optimized when upgrading to HTTP/2.

Real-World Performance Analysis

Studies and measurements from major tech companies quantified HTTP/1.1's performance impact and motivated the development of HTTP/2. Google's SPDY measurements (2012): Google engineers measured page load times across thousands of sites, comparing HTTP/1.1 with their experimental SPDY protocol:

Metric	HTTP/1.1	SPDY	Improvement
Page load time (median)	2.4s	1.8s	25% faster
Time to first paint	1.2s	0.8s	33% faster
Header bytes transferred	800 KB	50 KB	94% reduction
Connections per page	18	1	94% reduction

The header compression and multiplexing from SPDY (which became HTTP/2) delivered substantial real-world improvements.

HTTP Archive analysis: The HTTP Archive tracks web page composition over time. Trends show why HTTP/1.1 struggled:

Year	Requests per Page	Total Page Size	Domains per Page
2010	56	702 KB	9
2015	95	2,000 KB	22
2020	74	2,100 KB	20
2023	71	2,400 KB	18

While request counts stabilized (partly due to bundling), the sheer number of resources and domains remained a challenge for HTTP/1.1's connection model.

waterfall-analysis.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Typical HTTP/1.1 waterfall pattern (simplified)
 
Time →
|--TCP+TLS--|--HTML--|
            |--CSS--|
                    |--CSS--|
                            |--JS--|
                                   |--JS--|
                                          |--Image--|
                                                    |--Image--|
 
What's happening:
1. Initial connection + HTML fetch: ~400ms
2. Browser parses HTML, discovers resources
3. CSS files block rendering (critical path)
4. JS files may block on CSS completion
5. Images load after render-blocking resources
 
Problems visible:
- Resources discovered late in HTML can't start early
- Critical CSS/JS compete for 6 connection slots
- Non-critical resources block critical ones
- Slow resources in one batch delay next batch
 
With HTTP/2 multiplexing:
|--TCP+TLS--|
            |--HTML--|
            |--CSS-1--|--CSS-2--|
            |--JS-1--|--JS-2--|
            |--IMG-1--|--IMG-2--|--IMG-3--|
 
All requests start immediately after HTML discovery
Priority system ensures critical resources first
One connection, shared bandwidth, no round-trip serialization

The Mobile Penalty

HTTP/1.1's overhead is particularly punishing on mobile networks: higher RTTs amplify connection setup costs, packet loss triggers more HOL blocking, bandwidth limitations make header overhead more impactful, and battery constraints penalize multiple connections. Mobile performance was a primary driver for HTTP/2 development.

The Path to HTTP/2

HTTP/1.1's limitations ultimately drove the development of HTTP/2. Understanding what HTTP/2 fixed illuminates what was broken in HTTP/1.1. HTTP/2's solutions to HTTP/1.1 problems:

HTTP/1.1 Problems → HTTP/2 Solutions
HTTP/1.1 Problem	HTTP/2 Solution	Improvement
One request per connection	Multiplexed streams	Unlimited concurrent requests
6-connection limit	Single multiplexed connection	No artificial limits
HTTP HOL blocking	Independent streams	Slow response doesn't block others
Uncompressed headers	HPACK compression	90%+ header size reduction
Header repetition	Header table state	Send differences only
No prioritization	Stream priority weights	Critical resources first
Client-initiated only	Server push	Proactive resource delivery
Text protocol	Binary framing	Efficient parsing, less ambiguity

What HTTP/2 doesn't fix: HTTP/2 solved HTTP-layer problems but inherited TCP's limitations: TCP HOL blocking — A lost packet still blocks the entire connection. HTTP/2's single-connection model actually makes this worse than HTTP/1.1's multiple connections. TCP handshake cost — Still required, though only once per connection. TLS handshake cost — Still required, though HTTP/2 mandates TLS in practice. Middlebox incompatibility — Some proxies/firewalls mishandle HTTP/2 negotiation. These TCP limitations are why QUIC (HTTP/3) was developed—a UDP-based transport with built-in encryption, multiplexing, and per-stream loss recovery.

Lessons from HTTP/1.1's Evolution

HTTP/1.1's performance history teaches important lessons: protocol design has long-term consequences, workarounds become entrenched practices, the web grows faster than protocols evolve, and layering (HTTP over TCP) constrains optimization. HTTP/2 and HTTP/3 reflect these lessons, designing for parallel workloads from the start.

Performance Issues

The Limits of HTTP/1.1

Head-of-Line Blocking Revisited

Connection Limits and Constrained Parallelism

Header Overhead and Redundancy

TCP Connection Establishment Overhead

The Workaround Era: Anti-Patterns as Best Practices

Real-World Performance Analysis

The Path to HTTP/2

There’s more to understand.

Performance Issues

The Limits of HTTP/1.1

Head-of-Line Blocking Revisited

Connection Limits and Constrained Parallelism

Header Overhead and Redundancy

TCP Connection Establishment Overhead

The Workaround Era: Anti-Patterns as Best Practices

Real-World Performance Analysis

The Path to HTTP/2

There’s more to understand.