HTMLHow the Web Works

How the Web Works

Before writing more HTML, it's worth understanding the journey a page takes from "you type a URL" to "pixels appear on your screen." HTML is just one piece of this bigger picture — but understanding the whole flow makes everything about it click into place.

The client-server model

The web runs on a simple relationship: a client (your browser) asks a server (a computer somewhere else) for something, and the server responds. This is called the client-server model.

  • Client — your browser (Chrome, Firefox, Safari), or any program that makes requests: a mobile app, a command-line tool like <code>curl</code>, another server.

  • Server — a computer that stores files and programs, listens for requests, and sends back responses. It could be a single machine or thousands working together.

  • Request/response — the client sends a request ("give me this page"); the server sends a response (the page's HTML, or an error if something went wrong).

Step 1: Turning a domain name into an address (DNS)

When you type example.com into the address bar, your computer doesn't actually know where that is — computers communicate using numeric IP addresses like 93.184.216.34, not names. The Domain Name System (DNS) is the internet's phonebook: it translates the human-friendly domain name into the IP address of the server that hosts it.

DNS is cached
Your browser, operating system, and router all cache DNS results so this lookup usually only happens once per domain for a while — which is why the very first visit to a site can feel slightly slower than subsequent ones.
Step 2: The HTTP request/response cycle

Once the browser knows the server's address, it opens a connection and sends an HTTP request — a small text message describing what it wants.

Text
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html

The server processes that request and sends back an HTTP response — a status code plus the actual content:

Text
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 512

<!DOCTYPE html>
<html>...</html>

Status code

Meaning

200 OK

The request succeeded; here is the content

301/302

Redirect — the resource has moved elsewhere

404 Not Found

No resource exists at that address

500 Internal Server Error

Something went wrong on the server

Step 3: The browser parses HTML into the DOM

Once the raw HTML text arrives, the browser's HTML parser reads it character by character and builds the DOM (Document Object Model) — an in-memory tree representing every element and how they nest inside each other. This parsing happens incrementally: the browser doesn't wait for the entire file before starting to build the tree.

Step 4: CSS and JavaScript join in

While parsing HTML, the browser also discovers references to other resources and fetches them:

  • <code><link rel="stylesheet"></code> tags point to CSS files. The browser downloads and parses them into the CSSOM (a tree of style rules), which combines with the DOM to determine what each element should look like.

  • <code><script></code> tags point to JavaScript files, which can read and modify the DOM, respond to user actions, and fetch even more data.

  • <code><img></code>, <code><video></code>, and similar tags trigger requests for media files.

Order matters
Where you place <script> tags, and whether they use async or defer, affects how soon the page becomes interactive. This is covered in depth later, in the performance section of this series.
A simplified request-to-render path
  1. You type a URL and press Enter.

  2. The browser resolves the domain name to an IP address via DNS.

  3. The browser opens a connection and sends an HTTP request to the server at that address.

  4. The server processes the request and sends back an HTTP response containing HTML.

  5. The browser parses the HTML into the DOM as it downloads, discovering CSS and JavaScript along the way.

  6. CSS is parsed into the CSSOM; DOM + CSSOM combine into a render tree.

  7. The browser calculates layout (where everything sits) and paints pixels to the screen.

  8. JavaScript may run at various points, updating the DOM and triggering the browser to repeat layout/paint for the changed parts.

This whole sequence — often called the critical rendering path — usually takes well under a second on a fast connection. A dedicated later page, How Browsers Render HTML, goes one level deeper into steps 5 through 8.

Key takeaway: HTML is the content the server sends, and the browser's job is to turn that content — plus CSS and JavaScript — into something you can see and interact with. Next, we'll get hands-on and set up the tools you'll actually use to write HTML.