high-perf-browser

What this skill does

# 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:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Connection warmup** | Pre-establish connections to critical origins | `<link rel="preconnect" href="https://cdn.example.com">` |
| **DNS prefetch** | Resolve third-party domains early | `<link rel="dns-prefetch" href="https://analytics.example.com">` |
| **TLS optimization** | Enable TLS 1.3 and session resumption | Server config: `ssl_protocols TLSv1.3;` with session tickets |
| **Initial payload** | Keep critical HTML under 14KB compressed | Inline critical CSS, defer non-essential scripts |
| **Connection reuse** | Keep-alive connections to avoid repeated handshakes | `Connection: keep-alive` (default in HTTP/1.1+) |

See: [references/network-fundamentals.md](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:**

| Context | Pattern | Example |
|---------|---------|---------|
| **HTTP/2 migration** | Remove HTTP/1.1 workarounds | Undo domain sharding, remove sprite sheets, stop concatenating files |
| **Stream prioritization** | Signal resource importance to the server | CSS and fonts at highest priority; images at lower priority |
| **103 Early Hints** | Send preload hints before the full response | Server sends `103` with `Link: </style.css>; rel=preload` |
| **QUIC/HTTP/3** | Enable HTTP/3 on CDN or origin | Add `Alt-Svc: h3=":443"` header to advertise HTTP/3 support |
| **Header optimization** | Minimize custom headers to reduce overhead | Audit cookies and custom headers; remove unnecessary ones |

See: [references/http-protocols.md](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:**

| Context | Pattern | Example |
|---------|---------|---------|
| **Critical CSS** | Inline above-the-fold styles in `<head>` | `<style>/* critical styles */</style>` + async load full CSS |
| **Script loading** | Use `defer` for most scripts; `async` for independent scripts | `<script src="app.js" defer></script>` |
| **Resource hints** | Preload critical fonts, hero images, above-fold assets | `<link rel="preload" href="font.woff2" as="font" crossorigin>` |
| **Image optimization** | Lazy-load below-fold images; use modern formats | `<img loading="lazy" src="photo.avif" srcset="...">` |
| **Font loading** | Prevent invisible text with font-display | `@font-face { font-display: swap; }` |

See: [references/resource-loading.md](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, d