High Performance Browser Networking

1Speed is a feature, and it is paid in milliseconds

"Speed is a feature." Not a nicety: a feature, with revenue numbers behind it. The book's most telling example: Bing measured that an artificial 2,000 ms delay cut revenue per user by 4.3%. And human perception has precise thresholds, which the book lays out in a table: under 100 ms feels instant; between 300 and 1,000 ms, "the machine is working"; past 1,000 ms, the visitor's mind is already elsewhere. The book's rule of thumb: render something within 250 ms.

At the other end of the scale, finance puts an exact price on a millisecond: the Hibernia Express cable, $300M of fiber laid between New York and London to shave ~5 ms off the existing routes. $60M per millisecond.

2Bandwidth (almost) doesn't matter anymore

The founding experiment, run by Mike Belshe (the future creator of SPDY): vary the connection, time the page load. Going from 1 to 2 Mbps almost halves the load time. But going from 5 to 10 Mbps only buys ~5%. The curve flattens: past a few Mbps, your fiber stops speeding anything up.

Latency, on the other hand, never flattens: every 20 ms you shave improves load time linearly. Why? Because a page is not ONE download: it is ~90 requests to 15 hosts (the average 2013 page: 1,311 KB). Dozens of small round trips, and every round trip pays for the distance. "Bandwidth doesn't matter, much." That measured fact is what launched SPDY, and therefore HTTP/2.

And latency has a physical floor: light in fiber travels at ~200,000 km/s (the refractive index of glass slows it down by a third). New York to London: 56 ms round trip, incompressible. You can always buy more bandwidth; you cannot buy the speed of light.

3Every new connection pays a toll

Before sending the first useful byte, TCP demands a courtesy round trip: the handshake (SYN, SYN-ACK, ACK: "I'd like to talk", "fine, me too", "then let's talk"). Then slow start: TCP has no idea what the path can carry, so it starts cautiously (10 segments today, ~14 KB) and doubles every round trip. A new connection is therefore slow BY DESIGN, whatever your fiber.

The book's worked example: serving 64 KB between New York and London (56 ms RTT) takes 264 ms on a new connection, 96 ms on a reused one. Almost three times faster, for the same file and the same network. The operational lesson fits in one word: reuse (keepalive, connection pools, CDNs that terminate TLS close to the user).

4TLS is no longer expensive, but it needs tuning

The "HTTPS is slow" myth died in January 2010, when Gmail went all-HTTPS. Adam Langley (Google): less than 1% of CPU, less than 10 KB of memory per connection, less than 2% network overhead. "SSL/TLS is not computationally expensive anymore", and the author adds: if you stop reading here, at least remember that.

The real cost of TLS is not computation, it is, once again, round trips: a full handshake adds 2 RTTs before the first byte. All the tuning work consists of shaving them off: session resumption (client and server remember each other: 1 RTT), OCSP stapling (the server attaches the proof that its certificate is valid instead of letting the browser go fetch it, which cost up to +350 ms as measured by Firefox). Since the book, TLS 1.3 (2018) baked the lesson into the protocol: 1 RTT by default.

5For the battery, there is no such thing as a small request

On mobile, the radio chip is the second biggest battery drain after the screen, and it doesn't charge per byte: it charges per wake-up. Going from idle to transmitting costs ~10 joules per cycle, whatever the payload. The book's math: an app that polls its server every minute burns ~600 joules per hour, about 3% of the whole battery, per hour and per app, to carry next to nothing. "There is no such thing as a 'small request' as far as the battery is concerned."

The fix: batch. Prefetch in one burst and let the radio sleep, rather than a steady drip that keeps waking it up. It is the deliberate "load everything at once", the exact opposite of the server-side reflex.

6HTTP/1.1, the art of the workaround

HTTP/1.1 has a structural flaw: a connection serves only one response at a time (head-of-line blocking: the first response in the queue blocks all the others). Browsers compensate by opening 6 connections per host, and developers invented a whole culture of workarounds: domain sharding (spreading assets across several domains to get more connections), JS concatenation, image sprites, inlining. The book documents them while calling them what they are: band-aids.

Two numbers to measure the damage: 15 bytes of JSON cost 352 bytes of HTTP headers (96% packaging), and Apple gained +300% throughput in iTunes just by turning on keepalive and pipelining (WWDC 2012). Hence the chapter's most durable maxim: "The fastest request is a request not made."

7HTTP/2 changes the rules: unlearning is an optimization

HTTP/2 (2015, born from SPDY) keeps the semantics (GET, statuses, headers) and changes the plumbing: a single connection per origin, where all requests and responses travel chopped into interleaved frames. HTTP head-of-line blocking disappears. Patrick McManus's measurement (Firefox): 74% of HTTP/1 connections carry only ONE transaction; 25% with HTTP/2.

The consequence, and it is the book's most precious idea: the workarounds of idea 6 become ANTI-patterns. Sharding breaks the single connection, concatenation breaks granular caching, spriting makes you re-download 100 icons because one changed. "The best optimization for HTTP/1.x is to deploy HTTP/2." An optimization can have an expiry date: what the protocol fixes, your tooling must unlearn.

8Real-time is a choice, not a hack

To push data from the server to the page, the natural hack is polling: ask again every N seconds. The book prices it: 10,000 clients polling every 60 seconds consume ~1.13 Mbps continuously, even when there is NOTHING to deliver. Emptiness, wrapped in headers.

The real tools exist, from simplest to most powerful: SSE (a one-way text stream from server to client, reconnection for free), WebSocket (bidirectional, binary, but you lose HTTP caching and compression: everything is on you), WebRTC (peer-to-peer over UDP, for audio and video where a late frame is a frame worth dropping). The choice is a trade-off, not a modernity ladder: the simplest option that covers the need wins.