Tags: web-dev concept

How the Web Works

Date: 2026-08-17

---

One request, end to end — from typing a URL to pixels on screen. Every performance problem, outage and security control in this vault sits at one of these steps, so knowing the sequence is knowing where to look.

---

A page load is a chain of lookups, connections and transfers, each of which can fail or be slow independently. Here is the whole of it.

The sequence

1  URL PARSED
   scheme, host, path, query
   → https://shop.example.com/products/x

2  DNS RESOLUTION            ~20–120ms
   hostname → IP address
   browser cache → OS → resolver → root
   → TLD → authoritative

3  TCP CONNECTION            1 round trip
   SYN → SYN-ACK → ACK

4  TLS HANDSHAKE             1–2 round trips
   certificate, cipher, keys
   → the connection is now encrypted

5  HTTP REQUEST SENT
   GET /products/x
   Host, Cookie, Accept, User-Agent…

6  SERVER WORK               varies wildly
   routing, database, templating
   → Time to First Byte

7  RESPONSE STREAMS BACK
   status, headers, then body

8  BROWSER PARSES HTML
   discovers CSS, JS, images
   → requests them — back to step 2
     for any new hostname

9  RENDER
   DOM + CSSOM → layout → paint →
   composite

10 INTERACTIVE
   JavaScript executes, handlers bound

Steps 2 to 4 happen before a single byte of your page is requested. On a fresh connection that is three or four round trips of pure setup — which on mobile is often 300ms before anything useful starts.

Where the time actually goes

FAST CONNECTION, CACHED DNS
  DNS      0ms  (cached)
  TCP+TLS  0ms  (connection reused)
  TTFB    80ms
  render  ~400ms total

COLD, MOBILE
  DNS     100ms
  TCP      60ms
  TLS     120ms
  TTFB    300ms
  render  ~1.8s total

Latency dominates, not bandwidth. Each round trip costs the same regardless of how much data moves, which is why reducing the number of round trips beats reducing bytes on most pages — Latency and Bandwidth.

The consequences worth carrying

• Every new hostname repeats steps 2–4. A page pulling from six third-party domains pays that setup six times. This is the real cost of tag managers and script sprawl — Third-Party Scripts
• preconnect buys back the handshake for a domain you know you’ll need
• A CDN shortens step 2–7 by putting a server geographically closer, which reduces every round trip in the chain — Content Delivery Networks
• Step 8 is why script placement matters. A blocking script found early stops parsing — The Critical Rendering Path
• Caching skips steps entirely. A valid cached response skips 2 through 7 — HTTP Caching

What each layer contributes

DNS       names → addresses           DNS
TCP       reliable, ordered bytes     TCP and UDP
TLS       encryption + identity       TLS and HTTPS
HTTP      what you want, and how
          the answer is described     HTTP Semantics
HTML/CSS  what to render
JS        what happens next

See: DNS · TCP and UDP · TLS and HTTPS · HTTP Semantics

Each layer knows nothing about the ones above it. TCP doesn’t know it’s carrying HTTP; HTTP doesn’t know it’s carrying HTML. That separation is why HTTP/3 could replace TCP with QUIC without touching anything above it — HTTP Versions.

Where it breaks

DNS misconfigured      site unreachable,
                       cached for the TTL
                       — hours

certificate expired    browser blocks the
                       page entirely

slow server            TTFB dominates;
                       no front-end work
                       helps

blocking resources     white screen while
                       the parser waits

third-party down       page hangs on a
                       script nobody owns

The failure at each step looks different to a user, and the diagnostic value of knowing the sequence is being able to say which step from the symptom — a slow first byte and a slow render are unrelated problems with unrelated fixes.