How the web works

Every frontend bug you will ever chase happens somewhere along one journey: a URL becomes an IP address, a connection opens, an HTTP request goes out, a response comes back, and the browser turns bytes into pixels. If you can picture that journey, you can reason about slow pages, broken caches, missing styles and CORS errors instead of guessing. This lesson walks through each step in order.

#Clients, servers and URLs

The web is a conversation between two kinds of programs. A client (usually a browser) asks for things, and a server answers. Neither remembers the other between conversations unless something like a cookie is used to carry that memory.

The client says what it wants with a URL. Every part of a URL has a job:

https://shop.example.com:443/products/shoes?color=red&size=42#reviews
└─┬─┘   └──────┬───────┘ └┬┘ └─────┬──────┘ └───────┬───────┘ └──┬──┘
scheme       host       port     path            query        fragment

#DNS: turning names into addresses

Computers on the internet find each other by IP address, such as 203.0.113.10 (IPv4) or 2001:db8:85a3::8a2e:370:7334 (IPv6). Humans prefer names. The Domain Name System (DNS) is the distributed phone book that maps one to the other.

When you visit shop.example.com, the lookup checks progressively further away until it finds an answer:

1. Browser cache – did this tab or another one resolve the name recently?
2. Operating system cache – including the local hosts file.
3. Recursive resolver – a server run by your ISP, your company, or a public provider. If it does not have the answer cached, it does the legwork:
   • asks a root server, which says "ask the .com servers";
   • asks the .com TLD server, which says "ask example.com's authoritative servers";
   • asks the authoritative server, which returns the actual record.

The answer comes with a TTL (time to live) in seconds, telling every cache along the way how long it may reuse the answer. The record types you will meet most often are:

You can query DNS yourself with dig (macOS and Linux) or nslookup (all platforms):

dig +short example.com A

203.0.113.10
203.0.113.11

You will see real addresses rather than these placeholders, and large sites often return different ones depending on where you are.

#Opening a connection: TCP, TLS and QUIC

With an IP address in hand, the browser opens a connection to the server. Each step costs round trips – a message there and a reply back – and on a mobile network one round trip can easily take 100 ms.

• TCP gives a reliable, ordered stream of bytes. Setting it up takes a three-way handshake (SYN, SYN-ACK, ACK): one round trip.
• TLS runs on top of TCP for https. It proves the server's identity using a certificate signed by an authority the browser trusts, then agrees on encryption keys. TLS 1.3 needs one more round trip.
• HTTP/3 replaces TCP with QUIC, which runs over UDP and combines the transport and encryption handshakes into a single round trip.

That is why browsers work hard to reuse connections. Once a connection to a host is open, every later request to that host skips the handshakes entirely.

Here is the whole journey for a first visit to an https site, end to end. Press Play to walk through it one message at a time.

#HTTP: the request and the response

HTTP is the language spoken over the connection. A request has a method, a path, headers, and sometimes a body. Written out in the readable HTTP/1.1 form, it looks like this:

GET /products/shoes?color=red&size=42 HTTP/1.1
Host: shop.example.com
Accept: text/html
Accept-Language: en-GB
Cookie: session=abc123

The server replies with a status code, headers, and a body:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 5120
Cache-Control: max-age=300

<!doctype html>
<html lang="en">…

HTTP/2 and HTTP/3 send the same information in a compact binary format and can carry many requests at once over one connection, but the meaning – methods, headers, status codes – is identical. Learn it once and it applies everywhere.

#Methods

#Status codes

The first digit tells you the category:

#Headers worth knowing

• Content-Type – what the body is (text/html, application/json, image/png).
• Cache-Control – how long the response may be reused without asking again.
• Location – where to go next, sent with a 3xx redirect.
• Set-Cookie / Cookie – how a server asks the browser to remember a value and send it back on later requests. This is how a stateless protocol supports logins.

You can see real headers with curl. The -I flag sends a HEAD request, which returns only the headers:

curl -I https://example.com

HTTP/2 200
content-type: text/html
cache-control: max-age=3600
content-length: 1256

Your exact headers will differ, but the shape is always the same.

#From bytes to pixels: the rendering pipeline

The HTML document is only the beginning. The browser reads it as it streams in and discovers everything else it needs.

<!doctype html>
<html lang="en">
  <head>
    <link rel="stylesheet" href="/styles.css">
    <script src="/app.js" defer></script>
  </head>
  <body>
    <h1>Shoes</h1>
    <img src="/img/red-shoe.jpg" alt="Red running shoe">
  </body>
</html>

Loading this page triggers at least four HTTP requests: the document, styles.css, app.js, and the image. Then the browser runs its pipeline:

1. Parse HTML → DOM. The parser turns tags into a tree of objects called the Document Object Model.
2. Parse CSS → CSSOM. Stylesheets become a tree of rules. CSS is render-blocking: the browser will not paint the page until the stylesheets in the <head> have arrived, to avoid flashing unstyled content.
3. Run JavaScript. A plain <script> is parser-blocking: the parser stops, downloads and runs the script, then continues. With defer, the script downloads in parallel and runs after the document has been parsed, in order. With async, it runs as soon as it downloads, in no guaranteed order.
4. Style. The browser works out the final styles for every visible element (elements with display: none are skipped).
5. Layout. It calculates the size and position of every box.
6. Paint. It fills in pixels: text, colours, borders, images.
7. Composite. It combines painted layers into the final image on screen.

When JavaScript later changes the page, the browser repeats only the steps it has to. Changing a colour needs a repaint; changing a width needs layout again, which is more expensive.

#Common misconceptions

• "A web page is one file." A typical page makes dozens of requests. Each image, font, stylesheet and script is fetched separately, usually over a reused connection.
• "The server sees everything in the URL." It never receives the #fragment. If you need the server to know something, put it in the path or query.
• "A 404 means nothing came back." Error responses usually have a body – the "page not found" page you see is that body.
• "HTTPS just hides passwords." It also prevents anyone on the network from reading or altering any content, and proves you reached the real server. Browsers block http:// scripts on https:// pages for exactly this reason (this is called mixed content).
• "DNS changes are instant." Cached answers live until their TTL expires.

#Practice

Trace a real page load end to end.

1. Run dig +short (or nslookup) for a site you use daily and note the addresses.
2. Run curl -I against the same site with and without www.. Note the status codes and any Location header.
3. Open the site in a browser, open DevTools (F12), go to the Network tab, tick Disable cache, and reload. Find the first request (the document), then answer: how many requests did the page make in total? What Content-Type did the document have? Click the document and open its Timing section – which phases appear before "Waiting for server response"?
4. Reload again without "Disable cache" and compare the number of bytes transferred.

#Key takeaways

• A URL names the scheme, host, port, path and query; the fragment never leaves the browser.
• DNS resolves a hostname to an IP address through a chain of caches and servers, and TTLs control how long answers are reused.
• HTTPS connections cost round trips (TCP + TLS, or QUIC), so browsers reuse them.
• HTTP is requests (method, path, headers, body) and responses (status, headers, body); the meaning is the same across HTTP/1.1, 2 and 3.
• Browsers parse HTML into the DOM and CSS into the CSSOM, then style, lay out, paint and composite. CSS blocks rendering; plain scripts block parsing, so use defer.