High Performance Browser Networking What every web developer should know about networking and web performance (Ilya Grigorik)（Z-Library）

【One-Line Pitch】 A practical, protocol-by-protocol guide to why web applications feel slow and how to make them faster, written for developers who want to reason about latency, bandwidth, and browser networking instead of guessing. Read it if you build or operate web-facing software and want a durable mental model of the network beneath your code. 【Book Arc】 - **Opening (~0%–10%)**: Frames the case for performance as a business feature, then grounds it in the two fundamental constraints—latency and bandwidth—and how they shape every network interaction. - **Early (~10%–32%)**: Builds the transport foundation: TCP handshakes, flow and congestion control, head-of-line blocking, UDP's minimal contract, and the trade-offs of choosing one over the other. - **Middle (~32%–48%)**: Adds the security and wireless layers—TLS handshake costs and optimization, plus the unique constraints of radio: signal-to-noise ratio, interference, and path loss. - **Late (~48%–75%)**: Moves up the stack into HTTP's evolution and web performance analysis, including resource waterfalls, the performance pillars, and why more bandwidth often doesn't help. - **Ending (~75%–100%)**: Covers modern browser APIs for real-time and peer-to-peer communication—XHR improvements, SSE, WebSocket, and WebRTC—and how to apply protocol best practices in application design. 【Key Takeaways】 - **Speed is a feature, not a polish item** (Opening): Faster sites drive engagement, retention, and conversions—so performance work is product work, not an afterthought. - **Latency, not bandwidth, is usually the bottleneck** (Early): Round-trip time and protocol handshakes dominate perceived speed; adding bandwidth rarely fixes a latency-bound experience. - **TCP's reliability guarantees have a cost** (Early): In-order delivery and retransmission create head-of-line blocking, which is why some real-time applications deliberately choose UDP. - **UDP is a blank slate, not a free lunch** (Early): It omits connection state, congestion control, and flow control, so applications must reimplement them carefully or risk network collapse. - **TLS is no longer computationally expensive** (Middle): Modern commodity hardware handles encryption cheaply; the real costs lie in handshake round-trips, certificate size, and deployment configuration. - **Wireless adds physics to the problem** (Middle): Signal power, interference, and path loss mean mobile networks behave differently and demand their own optimization strategies. - **HTTP's history explains its performance limits** (Late): From HTTP 0.9 to 2.0, each version responds to transport inefficiencies—understanding the progression clarifies why modern optimizations work. - **The browser offers more than request-response** (Ending): XHR, SSE, WebSocket, and WebRTC each fit different communication patterns; choosing the right one is itself a performance decision. 【Reading Tips】 - Deep-read the TCP and UDP chapters if you've ever been confused by "why is my API slow"—they explain the mechanics behind most latency complaints. - Skim the TLS chapter's cryptographic details but study the operational guidance on certificates, handshakes, and server configuration. - Treat the HTTP history and web performance chapters as the bridge from theory to practice; the resource waterfall and performance pillars are the most actionable mental tools. - For the real-time APIs (SSE, WebSocket, WebRTC), focus on when to use each rather than implementation minutiae—the decision framework matters more than the syntax. - Keep the wireless chapter nearby when optimizing for mobile; its constraints are easy to forget when developing on a fast wired connection. 【Coverage Limits】 This guide is based on stratified excerpts covering roughly the first half of the book in detail, with lighter coverage of the later HTTP and real-time API chapters; specific examples, figures, and chapter-level nuance beyond the excerpts are not fully represented.