How the web works

01The big picture: a restaurant analogy

Think of visiting a website like ordering in a restaurant you have never been to. First you look up the address (DNS). Then you walk there and get a table (a TCP connection). You agree with the waiter on a private language so nobody else can listen in (TLS). You place your order from the menu (an HTTP request). The kitchen cooks (the server runs code and queries a database). The waiter brings the plate (the HTTP response), and you arrange it on the table and start eating (the browser parses and renders). A CDN is a branch of the restaurant near your house that already has popular dishes ready. Keep this picture in mind; every step below is one part of it.

• URL: https://example.com/products?page=2 = scheme + host + path + query.
• Client = the browser or app; server = the machine that answers.
• Latency (round-trip time) matters more than bandwidth for most pages.

02Step 1–3: DNS, TCP and TLS

The browser needs an IP address, not a name. It checks its own cache, the operating system, then asks a recursive resolver (from your ISP, 1.1.1.1 or 8.8.8.8). The resolver walks root servers, then the .com servers, then the domain's authoritative nameservers, and caches the answer for its TTL. With the IP, the browser opens a TCP connection using a three-way handshake (SYN, SYN-ACK, ACK) to port 443. Then TLS 1.3 runs: browser and server agree on keys and the server proves its identity with a certificate. TLS 1.3 needs one extra round trip; HTTP/3 merges transport and TLS into a single QUIC handshake over UDP. On a 100 ms mobile link these round trips are already 200–300 ms before any HTML arrives, which is why reused connections and nearby servers matter.

1# See each phase of a real request with timings
2curl -o /dev/null -s -w "dns: %{time_namelookup}s
3tcp: %{time_connect}s
4tls: %{time_appconnect}s
5first byte: %{time_starttransfer}s
6total: %{time_total}s
7" https://example.com/

03Step 4–6: request, server, response

Over the secure connection the browser sends an HTTP request: a method (GET), a path, and headers such as Host, Accept-Language, cookies and caching hints. On the server side, a web server like nginx receives it. It may answer directly with a static file, or pass the request to an application (Laravel through PHP-FPM, a Node.js process) that runs business logic, reads a database or cache and builds HTML or JSON. The response comes back with a status code (200, 301, 404, 500), headers (Content-Type, Cache-Control, Set-Cookie) and a body, usually compressed with gzip or Brotli. Time to First Byte (TTFB) measures this whole round: network plus server work. Slow TTFB usually means slow queries, no caching, or a server far away from the user.

1GET /products?page=2 HTTP/1.1
2Host: example.com
3Accept: text/html
4Accept-Encoding: br, gzip
5 
6HTTP/1.1 200 OK
7Content-Type: text/html; charset=utf-8
8Content-Encoding: br
9Cache-Control: public, max-age=60

04Step 7: the browser builds the page

The browser reads HTML as it streams in and builds the DOM, a tree of elements. When it finds CSS it downloads and parses it into the CSSOM; CSS is render-blocking because the browser will not paint unstyled content. Classic script tags block parsing too, unless they use defer or async. DOM and CSSOM combine into a render tree, then the browser computes layout (sizes and positions), paints pixels and composites layers on the GPU. Images, fonts and extra scripts load in parallel. JavaScript can change the DOM later, which can trigger layout again. Core Web Vitals measure the result: LCP (how fast the main content appears), INP (how fast the page reacts to input) and CLS (how much things jump around).

• Put CSS early, scripts with defer, and give images width and height.
• Preload the hero image and main font; lazy-load what is below the fold.
• Less JavaScript almost always means a faster, more responsive page.

05Where a CDN fits

A CDN (Content Delivery Network) such as Cloudflare, Fastly or CloudFront runs servers in hundreds of cities. When your DNS points to the CDN, the visitor's TLS handshake ends at the nearest edge server, often 10–30 ms away instead of 150 ms. The edge serves cached files (images, CSS, JS, sometimes whole HTML pages) directly, and only forwards cache misses to your origin server over a warm, reused connection. Many CDNs also add DDoS protection, a web application firewall and HTTP/3. The cost is one more layer to understand: caching rules, SSL settings between edge and origin, and the fact that your server now sees the CDN's IP unless you restore the real visitor IP from a header.

06Debugging the chain in practice

When something is wrong, test each link in order instead of guessing. Does the name resolve to the right IP? Can you open a TCP connection to port 443? Is the certificate valid for this hostname? What status code and headers come back? Is the server slow (high TTFB) or is the browser slow (long scripting or rendering in DevTools)? The browser's Network tab shows DNS, connect, TLS, waiting and download time for every file. The Performance tab and Lighthouse show parsing, layout and paint. On the server, access and error logs tell you whether the request even arrived.

1dig +short example.com A           # 1. DNS
2nc -vz example.com 443             # 2. TCP port open?
3openssl s_client -connect example.com:443 -servername example.com </dev/null | head -n 20   # 3. TLS
4curl -sI https://example.com/      # 4. status + headers
5sudo tail -f /var/log/nginx/access.log   # 5. did it reach the server?

07Why the first 14 KB matter: TCP slow start

A new TCP or QUIC connection does not know how fast the path is, so it starts carefully. The sender may only have about ten packets in flight (the initial congestion window, roughly 14 KB) before it must wait for acknowledgements, then it doubles that amount each round trip while nothing is lost. So a 100 KB HTML document on a fresh connection needs several round trips, not one, even on a fast line. That is why inlining critical CSS and keeping the top of the HTML small helps the first paint, and why reused, already-warm connections feel so much faster. Packet loss makes the sender shrink its window again, which is why lossy mobile networks hurt more than raw bandwidth numbers suggest. Modern congestion control such as BBR reacts better to loss than older algorithms, but the physics of round trips stays.

• Small, server-rendered HTML with critical CSS gets painted sooner.
• Connection reuse (keep-alive, HTTP/2 multiplexing) skips slow start for later requests.
• Each extra origin means a new DNS lookup, handshake and cold window.

08How the browser decides what to fetch first

Browsers do not download resources in page order. While the main parser is blocked on a script, a preload scanner reads ahead in the raw HTML and starts fetching images, stylesheets and scripts it finds. Each request gets a priority: CSS and blocking scripts are high, images in the viewport are raised after layout, async scripts and below-the-fold images are low. You can steer this. rel=preload fetches something the scanner cannot see, such as a font referenced only inside CSS. fetchpriority=high marks the LCP image as important. 103 Early Hints lets the server or CDN send preload links before the HTML is ready, using server think-time. The trap is overuse: if everything is high priority, nothing is, and preloading unused files wastes bandwidth on the critical path.

1<!-- In the <head>: help the browser find critical files early -->
2<link rel="preconnect" href="https://cdn.example.com" crossorigin>
3<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
4<img src="/img/hero.avif" width="1200" height="630" fetchpriority="high" alt="Product hero">
5<img src="/img/footer.webp" width="400" height="300" loading="lazy" alt="Team photo">
6<script src="/js/app.3f9a1c.js" defer></script>

09The layers of cache between user and database

A request can be answered at many layers, and each one is cheaper than the next. In the browser: the back/forward cache keeps whole pages in memory for instant back navigation; the memory and HTTP disk caches hold files according to Cache-Control; a service worker can answer from its own cache, even offline. Then the CDN edge, sometimes with a regional tier in front of the origin. On the origin, a reverse proxy like nginx can cache whole responses (microcaching for a few seconds absorbs traffic spikes). Inside the app, Redis or memory caches hold computed data, and the database has its own buffer pool. The engineering question is always the same: where can this answer be safely reused, for whom, and for how long? Personalised data can only live in caches keyed to that user.

10Trust along the chain: what can be spoofed

Each step trusts something. Plain DNS answers can be forged on a hostile network, which is why DNSSEC exists and why encrypted DNS (DNS over HTTPS or TLS) hides lookups from the local network. The real protection, though, is TLS: even if DNS sends you to the wrong IP, the attacker cannot present a valid certificate for example.com, so the browser stops. HSTS removes the first insecure http:// request that an attacker could intercept. Inside the browser, the same-origin policy keeps one site from reading another site's data, cookies with SameSite limit cross-site requests, and Content-Security-Policy restricts which scripts may run. On the server side, anything in the request (headers, cookies, X-Forwarded-For) is user input until a trusted proxy vouches for it.