High Performance Browser Networking Framework

A systematic approach to web performance optimization grounded in how browsers, protocols, and networks actually work. Apply these principles when building frontend applications, reviewing performance budgets, configuring servers, or diagnosing slow page loads.

Core Principle

Latency, not bandwidth, is the bottleneck. Most web performance problems stem from too many round trips, not too little throughput. A 5x bandwidth increase yields diminishing returns; a 5x latency reduction transforms the user experience.

The foundation: Every network request passes through DNS resolution, TCP handshake, TLS negotiation, and HTTP exchange before a single byte of content arrives. Each step adds round-trip latency. High-performance applications minimize round trips, parallelize requests, and eliminate unnecessary network hops. Understanding the protocol stack is not optional -- it is the prerequisite for meaningful optimization.

Scoring

Goal: 10/10. When reviewing or building web applications, rate performance 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.

The High Performance Browser Networking Framework

Six domains for building fast, resilient web applications:

1. Network Fundamentals

Core concept: Every HTTP request pays a latency tax: DNS lookup, TCP three-way handshake, and TLS negotiation -- all before any application data flows. Reducing or eliminating these round trips is the single highest-leverage optimization.

Why it works: Light travels at a finite speed. A packet from New York to London takes ~28ms one way regardless of bandwidth. TCP slow start means new connections begin transmitting slowly. TLS adds 1-2 more round trips. These physics-level constraints cannot be solved with bigger pipes -- only with fewer trips.

Key insights:

• TCP three-way handshake adds one full RTT before data transfer begins
• TCP slow start limits initial throughput to ~14KB (10 segments) in the first round trip -- keep critical resources under this threshold
• TLS 1.2 adds 2 RTTs; TLS 1.3 reduces this to 1 RTT (0-RTT with session resumption)
• Head-of-line blocking in TCP means one lost packet stalls all streams on that connection
• Bandwidth-delay product determines in-flight data capacity; high-latency links underutilize bandwidth
• DNS resolution can add 20-120ms; pre-resolve with dns-prefetch

Code applications:

See: references/network-fundamentals.md for TCP congestion control, bandwidth-delay product, and TLS handshake details.

2. HTTP Protocol Evolution

Core concept: HTTP has evolved from a simple request-response protocol to a multiplexed, binary, server-push-capable system. Choosing the right protocol version and configuring it properly eliminates entire categories of performance problems.

Why it works: HTTP/1.1 forces browsers into workarounds like domain sharding and sprite sheets because it cannot multiplex requests. HTTP/2 solves multiplexing but inherits TCP head-of-line blocking. HTTP/3 (QUIC) moves to UDP, eliminating head-of-line blocking and enabling connection migration. Each generation removes a bottleneck.

Key insights:

• HTTP/1.1 allows only one outstanding request per TCP connection; browsers open 6 connections per host as a workaround
• HTTP/2 multiplexes unlimited streams over a single TCP connection, making domain sharding counterproductive
• HPACK header compression in HTTP/2 reduces repetitive header overhead by 85-95%
• HTTP/3 runs over QUIC (UDP), eliminating TCP head-of-line blocking and enabling 0-RTT connection resumption
• Server Push (HTTP/2) sends resources before the browser requests them -- use sparingly and prefer 103 Early Hints instead
• Connection coalescing in HTTP/2 lets one connection serve multiple hostnames sharing a certificate

Code applications:

See: references/http-protocols.md for protocol comparison, migration strategies, and server push vs. Early Hints.

3. Resource Loading and Critical Rendering Path

Core concept: The browser must build the DOM, CSSOM, and render tree before painting pixels. Any resource that blocks this pipeline delays first paint. Optimizing the critical rendering path means identifying and eliminating these bottlenecks.

Why it works: CSS is render-blocking: the browser will not paint until all CSS is parsed. JavaScript is parser-blocking by default: <script> halts DOM construction until the script downloads and executes. Fonts can block text rendering for up to 3 seconds. Each blocking resource adds latency directly to time-to-first-paint.

Key insights:

• Critical rendering path: HTML bytes -> DOM -> CSSOM -> Render Tree -> Layout -> Paint -> Composite
• CSS blocks rendering; JavaScript blocks parsing -- these have different optimization strategies
• async downloads scripts in parallel and executes immediately; defer downloads in parallel but executes after DOM parsing
• <link rel="preload"> fetches critical resources at high priority without blocking rendering
• <link rel="prefetch"> fetches resources for likely next navigations at low priority
• Inline critical CSS (above-the-fold styles) and defer the rest to eliminate the render-blocking CSS request
• Fonts: use font-display: swap to avoid invisible text during font loading

Code applications:

See: references/resource-loading.md for async/defer behavior, resource hint strategies, and image optimization.

4. Caching Strategies

Core concept: The fastest network request is one that never happens. A layered caching strategy -- browser memory, di