Browsers, servers, and the request

Why this matters

Every web page you will ever build travels the same road: a browser asks for it, a server sends it, and the browser turns it into something you can see and use. When a page is slow, broken or blank, the cause is almost always somewhere on that road. If you can picture each step, you can find the problem instead of guessing.

This lesson walks the road once, slowly. You do not need to memorise every detail; you need a mental model you can come back to.

The two sides: client and server

• The client is the program asking for something. For the web, that is usually a browser such as Firefox, Chrome, Safari or Edge, running on your laptop or phone.
• The server is a computer, somewhere on the internet, running a program that listens for requests and answers them.

A server is not a special kind of machine. It is any computer running server software. During this course your own laptop will act as both: the browser is the client, and when you open a file or run a local server, your machine plays the server too.

Step 1: you type a URL

A URL (Uniform Resource Locator) is an address. Take this one apart:

https://www.example.com:443/blog/post.html?lang=en#comments

Step 2: DNS turns the name into a number

Computers on the internet find each other by IP address, such as 93.184.215.14 or a longer IPv6 address. Names like www.example.com exist for humans. The browser asks the Domain Name System (DNS) to look the name up, much like looking up a contact to get a phone number. The answer is cached, so the second visit skips most of this step.

Step 3: a connection opens

With the IP address in hand, the browser opens a connection to the server (TCP, or QUIC for newer HTTP/3). For https URLs, the two sides also perform a TLS handshake: the server proves its identity with a certificate, and they agree on keys so nobody in between can read or change the traffic. That is what the padlock in the address bar means.

Step 4: the browser sends an HTTP request

Now the browser speaks HTTP, a plain-text protocol (you will read real messages in the next lesson). The request says, in effect: "Please GET /blog/post.html from www.example.com. I understand HTML, and I prefer English."

Step 5: the server responds

The server finds or builds the resource and sends back an HTTP response: a status code (such as 200 OK or 404 Not Found), some headers describing the content, and the content itself, here an HTML document.

Some servers just read a file from disk. These are static sites, and you will publish one at the end of this course. Others run code that builds each page on the fly from a database; those are dynamic sites. To the browser both look the same: it receives HTML.

Step 6: the browser renders the page

This is where HTML and CSS come in.

1. Parse HTML into the DOM. The browser reads the HTML from top to bottom and builds the Document Object Model, a tree of elements (html contains head and body, body contains headings, paragraphs, and so on).
2. Fetch more resources. Along the way it finds references to stylesheets, images, fonts and scripts, and sends a new request for each one. A single page often needs dozens of requests.
3. Apply CSS. It parses the CSS and works out the final style of every element.
4. Layout. It calculates where every box goes and how big it is, based on the screen size.
5. Paint. It draws pixels: text, colours, borders, images.

If JavaScript changes the page later, the browser repeats some of these steps for the parts that changed.

Worked example: watching it happen

You can see every request your browser makes.

1. Open any website, then open the developer tools (F12, or right-click and choose Inspect).
2. Choose the Network tab and reload the page.
3. The first row is usually the HTML document. Click it to see the request URL, the status code and the response headers.
4. Below it, notice the stylesheets, images and scripts the HTML asked for, each with its own status and size.

Try a URL that does not exist on a site, such as /this-page-is-not-real. The first row now shows status 404. The server still answered; it just answered "not found".

Common mistakes

• Thinking the URL is the file. The path often maps to a file, but a server can answer any path however it likes.
• Blaming the HTML for a DNS or network problem. "This site can't be reached" means the browser never got a response at all, so your markup is not the issue yet.
• Forgetting that every image, font and stylesheet is another request. Large or numerous files are the most common reason a simple page feels slow.
• Expecting the fragment (#comments) to reach the server. It stays in the browser and only scrolls the page.

Quick recap

• The browser (client) asks; the server answers.
• URL, then DNS lookup, then a connection (with TLS for HTTPS), then an HTTP request and response.
• The browser parses HTML into the DOM, fetches extra resources, applies CSS, lays out boxes and paints pixels.
• The Network tab in developer tools shows every request and its status.

Try it

Open the Do tab for a short quiz on the journey of a page load.