How the web works: request, response, render

Before writing any HTML it is worth knowing what actually happens when you type an address and press Enter, because almost every confusing thing later — why a page is slow, why an image is missing, why your change is not showing up — is explained by one of these steps.

There are four, and the whole thing usually takes under a second.

1. Your browser finds the server

You type riztechacademy.com. That is a name, and names mean nothing to the network — it needs a number.

So the browser asks DNS, the phone book of the internet: what is the address of riztechacademy.com? It gets back something like 76.76.21.21, an IP address.

You can watch this happen. In a terminal:

nslookup riztechacademy.com

The answer is cached — by your browser, your operating system, your router and your internet provider. This is why a site you have just visited loads faster the second time, and why a DNS change can take hours to reach everybody.

2. It asks for a page

Now the browser opens a connection to that address and sends a request:

GET / HTTP/1.1
Host: riztechacademy.com
User-Agent: Mozilla/5.0 (…)
Accept: text/html

GET is the method — "give me this". / is the path, meaning the home page. Host says which site, because one server holds many. The rest is the browser introducing itself.

That is the whole thing: a few lines of text. HTTP is plain text you could type by hand, which is worth knowing when it feels like magic.

3. The server responds

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 4821

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

The first line carries the status code, and you should know four of them on sight:

Code	Means	Where you will meet it
200	Here it is	Everything working
301 / 302	It moved, go here instead	`http` → `https`, or a renamed page
404	No such thing	A typo in a link or an image path
500	I broke	The server has a bug. Not your fault, unless it is your server

404 is the one you will cause most often, by mistyping an image filename.

Content-Type tells the browser what it is receiving. This matters more than it sounds: the same bytes are a web page if the type says text/html and a wall of text if it says text/plain.

4. The browser builds the page

This is the part people skip, and it is the part that explains the most.

The browser reads the HTML from the top down and builds a tree of elements called the DOM. As it goes it finds references to other files — stylesheets, images, fonts, scripts — and asks for each one. That is a new request per file.

Two consequences you will meet in this course:

A stylesheet blocks rendering. The browser will not paint the page until it has your CSS, because painting first would show unstyled content and then jump. So a slow stylesheet is a blank screen. This is why <link rel="stylesheet"> goes in the head and why its size matters.

Every file is another round trip. Twelve images is thirteen requests. On office wifi you will not notice. On a mid-range Android on mobile data in Pune, each round trip can be 100–300 milliseconds, and that is the difference between a site that feels instant and one that feels broken.

Then it lays everything out — working out the size and position of every box — and paints pixels. When you change one CSS property later and the whole page reflows, that is this step running again.

Where your files live while you are learning

For this course, there is no server. You will open a file directly:

file:///Users/asha/sites/first-page/index.html

That is your own disk, not the network. Everything above still applies except step 1 and step 2 — the browser reads the file and builds the page exactly the same way, which is why you can learn all of HTML and CSS with no server at all.

A few things behave differently on file:// and it is worth knowing now so you do not think you have broken something later: fonts and some scripts can be blocked, and anything involving a server (form submission, fetch) will not work. The last module deploys the site properly, at which point it is https:// like any other.

Client and server, and which is which

You will hear these constantly, so fix them now.

The client is the browser. It runs on the visitor's phone or laptop, a machine you do not control. Everything you write in this course — HTML, CSS — is sent to the client and runs there.

The server is the machine that sent the files. You control it, or you pay somebody who does.

The line between them is the single most important idea in web development, and most of the security in the Full-Stack course comes down to it: anything on the client can be changed by the person holding it. Not relevant yet, but the habit of asking "which side is this on?" starts here.

Watch it happen

Open any site, press F12 (or Cmd + Option + I on a Mac) to open devtools, go to the Network tab, and reload.

You get one row per request: the file, its status code, its size and how long it took. This is the most useful screen in web development and you will spend real time in it. Look for the first row — the HTML document — and notice that everything else was discovered by reading it.

Sort by size. The biggest row is almost always an image, and that will be true in your own projects too.

Check your work

What DNS does. Turns a name into an IP address, because the network only understands numbers.

What a request is. A few lines of plain text: a method, a path, and some headers.

200, 301, 404, 500. Here it is; it moved; no such thing; I broke.

Which one you will cause most. 404, from a mistyped image path.

What Content-Type decides. Whether the same bytes are a page or plain text.

What the DOM is. The tree of elements the browser builds by reading your HTML top to bottom.

Why a stylesheet blocks rendering. Painting before the CSS arrives would show unstyled content and then jump.

Why file count matters. Each file is a round trip, and a round trip on mobile data is 100–300ms.

Client versus server. The client is the visitor's browser and you do not control it. The server sent the files and you do.

Why file:// is fine for now. The browser builds the page identically; only the fetching steps are skipped.

Practice

Run nslookup riztechacademy.com and note the IP address.
Open devtools, go to Network, and reload any site. Count the requests.
Sort by size. What is the biggest file? Is it an image?
Click the first row and read the response headers. Find Content-Type.
Visit a URL you know does not exist on a real site, e.g. riztechacademy.com/this-is-not-a-page, and confirm the status is 404 in the Network tab. Note that the page you see is still a page — a 404 has content.
Find a request with a 301 or 302 in the Network tab. Type a site's address without https:// and watch the redirect.
Throttle the network: in devtools, set throttling to "Slow 4G" and reload. Note how much longer it takes, and which files you waited for.
Explain to somebody, out loud, what happens between pressing Enter and seeing the page. If you cannot do it in four steps, reread the section headings.

Official documentation

MDN — An overview of HTTP — The request/response cycle, methods and headers, in more detail than this lesson.
MDN — HTTP response status codes — The full list, with what each one actually means. Worth bookmarking.
Chrome DevTools — Network reference — Every column and filter in the panel you just opened.

Next: getting an editor set up so you can make a page of your own.