How the web works

Every day you type an address, tap a link and a page appears. In this lesson we open the box and look at what really happens in that half second, so that every line of code you write later makes sense. We also meet the project you will build throughout this course: your own portfolio website.

Where we are going

By the end of this course you will have a small but complete website: a personal portfolio presenting who you are, a few projects, and a contact form. It will work on phones and computers, it will be accessible and tidy, and it will be online. We will build it piece by piece, one chapter at a time.

You can choose the subject. A portfolio for a photographer, a student, a craftsperson, a local club or a hobby all work well. In the examples we will follow a fictional person, Maya Carter, who takes photographs and draws illustrations. Replace Maya with yourself whenever you like.

Clients and servers

The web is a giant conversation between two kinds of computers. Your phone, laptop or tablet is the client. The software on it that talks to the web is the browser. On the other side, a server is a computer that is always switched on and connected to the Internet, and whose job is to hand out files when someone asks for them.

An analogy helps. Think of a restaurant. You (the browser) read the menu and place an order. The kitchen (the server) prepares it and sends it back. You never see the kitchen, you only see what arrives on your table.

What happens when you open a page

Suppose you type https://www.example.org/projects/index.html and press Enter. Here is the sequence, simplified:

1. The browser reads the address, called a URL, and extracts the domain name, www.example.org.
2. It asks a directory service, the DNS, which numeric address (an IP address) belongs to that name. Think of it as looking up a phone number from a contact name.
3. The browser opens a connection with that server and sends an HTTP request: “Please send me /projects/index.html.”
4. The server answers with a response: a status code and, most of the time, the file itself.
5. The browser reads the HTML, notices it needs a stylesheet, some images and maybe a script, and sends more requests for each of them.
6. Once everything has arrived, the browser assembles the page and draws it on screen. This step is called rendering.

All of this usually takes a fraction of a second, which is why it feels like magic.

HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the set of rules the browser and server follow to talk to each other. HTTPS is the same conversation, but encrypted, so that someone listening on the network cannot read or alter what is exchanged. Today you should always publish your sites over HTTPS, and most hosting services make this easy.

Status codes you will meet

The first line of every response contains a three-digit status code. You do not need to memorize many of them, but these few show up constantly:

Code	Meaning	What it tells you
200	OK	The file was found and sent.
301	Moved permanently	The address has changed; the browser follows the new one.
404	Not found	The server has no file at that address. Often a typo in a link or a file name.
500	Server error	Something went wrong on the server side, not in your page.

Anatomy of a URL

https://www.example.org/projects/index.html#contact
\___/   \_____________/\_______________/ \______/
  |            |               |             |
protocol    domain           path        fragment

• The protocol (https) says how to communicate.
• The domain name identifies the server.
• The path points to a file or folder on that server.
• The optional fragment (after #) jumps to a place inside the page.

When the path ends with a folder name, servers typically look for a file called index.html inside it. That is why the main page of a site is almost always named index.html. Remember this: we will use it in the next lessons.

The three languages of the web

The files the server sends are mostly written in three complementary languages. To remember what each does, think of a house.

Language	Role	In the house
HTML	Structure and content	Walls, rooms, doors
CSS	Appearance and layout	Paint, furniture, decoration
JavaScript	Behavior and interaction	Wiring and appliances

This course covers HTML and CSS, the essential foundation. JavaScript is a natural next step, which we will discuss in the last chapter. The reference documentation for HTML and CSS is maintained on MDN. Keep it in your bookmarks.

Static and dynamic sites

A static site is made of ready-to-send files: the server simply hands over what is stored. A dynamic site builds its pages on the fly, for instance by reading from a database. The portfolio you will build is static, which is perfect for learning: no server programming, easy to publish, quick to load.

Your turn

Pick a website you know well and trace its journey in your own words.

1. Write down the full URL of one of its pages and split it into protocol, domain and path.
2. List which files you think the browser had to download to show that page (the HTML, then probably styles, images and so on).
3. Try changing the end of the address to something that cannot exist, such as /this-page-does-not-exist. What do you see? Which status code do you think was sent?

See a solution

For https://www.example.org/projects/index.html, the protocol is https, the domain is www.example.org and the path is /projects/index.html.

The browser first downloads the HTML file. Reading it, it discovers the other files it needs: one or more CSS files, images, fonts and often scripts. Each one is a separate request.

A made-up address usually shows an error page saying the page was not found, which corresponds to status code 404. Some sites show a friendly custom 404 page, but the code is the same. In the next lesson you will learn how to see these requests and codes yourself.