Skip to content
Networking & Protocols

Systems

Listen 0%
Speed

18 · Networking & Protocols

What happens between your fetch() and the server’s response: HTTP/1.1 → HTTP/2 → HTTP/3 (QUIC), TLS, DNS, CDNs, HTTP caching, real-time protocols, and compression. The transport layer that bounds every performance metric you care about.

Positioning

Networking is the floor under your performance ceiling: TTFB, LCP, and request waterfalls (15) are decided here, before a single component renders. A senior frontend engineer needs to reason about round-trips, connection reuse, caching semantics, and protocol capabilities — because the highest-leverage performance wins are often network-shaped (a CDN, a caching header, HTTP/3, fewer round-trips), not code-shaped.

Foundations

The journey of a request

  1. DNS resolution — hostname → IP (recursive resolver, caching at OS/browser; dns-prefetch to warm it).
  2. TCP (or QUIC) connection — handshake round-trips.
  3. TLS handshake — negotiate encryption (1 RTT in TLS 1.3, 0-RTT for resumption).
  4. Request/response — send headers+body, receive status+headers+body.
  5. Connection reuse / close — keep-alive, multiplexing, pooling.

Every RTT costs latency that no amount of bandwidth fixes — which is why reducing round-trips is the central network optimization.

Deep dive

1. HTTP/1.1 → HTTP/2 → HTTP/3

  • HTTP/1.1: one request at a time per connection; browsers open ~6 parallel connections per origin to compensate. Suffers head-of-line (HOL) blocking at the HTTP layer (a slow response blocks the connection). Workarounds of this era — domain sharding, spriting, concatenation, inlining — are now anti-patterns under H2/H3.
  • HTTP/2: multiplexing — many concurrent streams over one TCP connection; header compression (HPACK); stream prioritization; server push (now largely deprecated/removed — use 103 Early Hints + preload instead). Kills HTTP-layer HOL blocking, but TCP-level HOL blocking remains: one lost packet stalls all streams on that connection.
  • HTTP/3: runs over QUIC (built on UDP), not TCP. Eliminates TCP HOL blocking (per-stream loss recovery), faster connection setup (crypto+transport handshake combined, 1-RTT / 0-RTT), and connection migration (survives network switches, e.g., Wi-Fi→cellular, via connection IDs). The default for top sites/CDNs in 2026. Net effect: better performance on lossy/mobile networks especially.

Implication for frontend: under H2/H3, don’t shard domains or over-concatenate; many small cacheable files multiplex fine and cache better. Over-splitting still risks request waterfalls (dependent fetches), which multiplexing doesn’t fix (14).

2. TLS

  • TLS 1.3 is the modern standard: fewer round-trips (1-RTT handshake, 0-RTT resumption), removed legacy ciphers. Always serve over HTTPS; add HSTS to force it (17).
  • Certificates: CA-signed, increasingly automated (Let’s Encrypt/ACME). OCSP stapling, SNI (host selection), and ALPN (negotiates h2/h3) are the moving parts.
  • TLS is also a trust boundary, not just encryption — it authenticates the server.

3. DNS

  • Hierarchical, cached at multiple levels; first-visit resolution is a latency cost.
  • Resource hints: dns-prefetch (resolve early), preconnect (DNS + TCP + TLS early — use for critical third-party origins like fonts/CDN), but use sparingly (each preconnect costs resources).
  • DoH/DoT (DNS over HTTPS/TLS) for privacy; CDN/anycast DNS for fast, geo-routed resolution.

4. CDNs & edge

  • Content Delivery Networks cache static (and increasingly dynamic/edge-rendered) content at points of presence near users, cutting RTT and offloading origin. The biggest single TTFB/LCP lever for global apps.
  • Edge compute (Cloudflare Workers, Vercel Edge, 08) runs logic at the PoP — SSR/personalization/auth close to the user.
  • Anycast routes users to the nearest PoP; cache invalidation/purge and stale-while-revalidate at the edge are key operational concerns.

5. HTTP caching (the highest-ROI network skill)

Two models, used together:

  • Freshness — Cache-Control is king: max-age, s-maxage (shared caches/CDN), public/private, no-store (never cache), no-cache (cache but revalidate), immutable (never revalidate — for hashed assets), and stale-while-revalidate (serve stale instantly, refresh in background — great UX).
  • Validation — when stale, revalidate with ETag/If-None-Match or Last-Modified/If-Modified-Since; server returns 304 Not Modified (no body) if unchanged.
  • The canonical strategy: content-hashed filenames (app.a1b2c3.js) + Cache-Control: max-age=31536000, immutable for static assets; no-cache/short max-age + ETag for HTML; CDN layer with s-maxage + stale-while-revalidate. This is what 14’s hashing and 08’s caching layers plug into.
  • Vary (e.g., on Accept-Encoding) so caches don’t serve the wrong representation.

6. Real-time & streaming protocols

  • WebSocket — full-duplex, persistent, bidirectional; for chat, multiplayer, collaborative editing. (04)
  • Server-Sent Events (SSE) — server→client one-way stream over plain HTTP, auto-reconnect; ideal for notifications, live feeds, LLM token streaming. Simpler than WS when you don’t need client→server.
  • HTTP streaming / chunked transfer — the basis of streaming SSR and RSC payload streaming (07).
  • Long-polling — the legacy fallback.
  • WebTransport (over HTTP/3/QUIC) — emerging low-latency bidirectional transport, a future WebSocket alternative for some cases.
  • Choosing: one-way server push → SSE; bidirectional/low-latency → WebSocket; just streaming a response → HTTP streaming.

7. Compression

  • Brotli (br) for text assets (better ratios than gzip), gzip fallback; negotiated via Accept-Encoding/Content-Encoding. Pre-compress static assets at build; let the CDN handle the rest.
  • Don’t double-compress already-compressed formats (images/video/woff2).

Worked example: a caching + hints setup for a SPA/SSR app

# Hashed static assets — cache forever, never revalidate
/assets/app.a1b2c3.js   Cache-Control: public, max-age=31536000, immutable
                         Content-Encoding: br

# HTML (or SSR document) — always revalidate, allow stale at the edge
/                        Cache-Control: no-cache
                         CDN: s-maxage=60, stale-while-revalidate=600

# API responses (cacheable GETs)
/api/products            Cache-Control: private, max-age=30, stale-while-revalidate=120
                         ETag: "v42"      # → 304 on revalidation
<!-- Warm critical third-party origins; preload the LCP image -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://analytics.example.com">
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

Result: repeat visits hit immutable caches (no network for JS/CSS), HTML revalidates cheaply with a 304, the edge serves instantly-stale-then-fresh, and the critical path is warmed — directly improving TTFB/LCP (15).

Pitfalls & gotchas

  • HTTP/1.1-era hacks under H2/H3 — domain sharding, spriting, mega-bundles now hurt (defeat multiplexing + caching).
  • Caching HTML with a long max-age — users get stale apps; use no-cache/short TTL + ETag.
  • No content hashing — can’t safely cache assets long-term.
  • Over-using preconnect — each one costs a connection; reserve for critical origins.
  • Request waterfalls — chained dependent fetches; aggregate server-side (BFF/RSC, 12) — multiplexing doesn’t fix sequential dependency.
  • WebSocket where SSE suffices — extra complexity for one-way data.
  • Forgetting Vary: Accept-Encoding — caches serve wrong-encoded bodies.
  • Assuming bandwidth fixes latency — RTTs dominate; reduce round-trips.

Interview questions

  1. HTTP/1.1 vs 2 vs 3 — what does each fix? What is HOL blocking at each layer?
  2. Why does HTTP/3 use QUIC/UDP, and what does connection migration buy?
  3. Which HTTP/1.1 optimizations became anti-patterns under H2/H3, and why?
  4. Explain the HTTP caching model: freshness vs validation, ETag/304, immutable, stale-while-revalidate.
  5. Design a caching strategy for hashed assets vs HTML vs API.
  6. preconnect vs dns-prefetch vs preload — when each?
  7. WebSocket vs SSE vs HTTP streaming — choose for a use case.
  8. What does a CDN do for TTFB/LCP, and what’s edge compute?
  9. What changed in TLS 1.3, and why does it matter for performance?
  10. Why doesn’t multiplexing fix request waterfalls?

Recommendations

  • Serve over HTTP/3 (+H2 fallback) and TLS 1.3; put a CDN in front globally.
  • Don’t shard domains or over-bundle; ship many small hashed, cacheable files and let multiplexing work.
  • Master Cache-Control: immutable for hashed assets, no-cache+ETag for HTML, s-maxage+stale-while-revalidate at the edge.
  • Warm the critical path with preconnect/preload/fetchpriority (sparingly); avoid waterfalls by aggregating server-side (12).
  • Brotli text assets; negotiate via Accept-Encoding; set Vary.
  • Pick the right real-time protocol (SSE for one-way, WS for bidirectional, HTTP streaming for SSR/RSC).
  • Optimize for round-trips, not bandwidth.

Books & references

  • “High Performance Browser Networking” — Ilya Grigorik (free at hpbn.co). The definitive, current-enough deep dive on TCP/TLS/HTTP/2/QUIC/WebSocket/SSE for web engineers. The book for this file.
  • “HTTP: The Definitive Guide” — Gourley & Totty. Thorough HTTP/caching reference (pre-H2 but foundational).
  • MDN HTTP docs — caching, Cache-Control, CORS, conditional requests, status codes; current and practical.
  • web.dev — “Network reliability,” resource hints, HTTP caching, and CWV-network guides (15).
  • RFCs for the rigorous: 9110–9114 (HTTP semantics, HTTP/1.1, HTTP/2, HTTP/3, QUIC), 8446 (TLS 1.3), 9111 (HTTP caching).
  • Cloudflare Learning Center — accessible explainers on QUIC, TLS, CDNs, anycast.

Connections

Frontend Deep-Dive Library · content is the single source of truth.