What really happens when you open a web page

Tobi types ighnova.com into his phone's browser and taps Go. Two seconds later, the Inova home page is there: the logo, the course list, the pictures, the buttons that change colour when he touches them.

Two seconds. In that time, his phone asked a phonebook for a number, opened a conversation with a computer in a data centre, asked politely for a page, received dozens of separate files in thousands of packets, and assembled them — text, layout, pictures, behaviour — into what he sees. If any one step had failed, he would have seen an error instead.

You already know every piece of this: DNS (Lesson 7.5), packets and TCP (Lesson 7.2), data centres (Lesson 7.4), HTML and JavaScript (Lesson 5.1). This lesson puts them together into the most common thing anyone does on a computer — opening a web page — and then teaches you to read the two things on the screen that most people ignore: the address, and the padlock.

Words in this lesson

Reading an address: the parts of a URL

Every web page has an address called a URL. MDN — Mozilla's reference for web developers — breaks a URL into parts. Here is one example, built from MDN's pieces:

https://www.example.com/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

Sometimes a port number appears after the domain, such as :80 — what MDN calls the technical "gate" on the server. Usually it is left out and the browser uses the normal one.

You have seen most of this before. The domain is a name that DNS turns into an IP address (Lesson 7.5). The path looks like the folder paths of Lesson 6.3, with forward slashes. The parameters are how a search box or a filter tells the server what you want.

The conversation: request and response

MDN describes what happens when you type an address, in four steps:

1. DNS lookup. The browser asks DNS for the real address of the server the website lives on (Lesson 7.5).
2. Request. The browser sends an HTTP request to that server — in effect, "please send me this page" — carried across your connection as packets using TCP/IP (Lesson 7.2).
3. Response. If the server agrees, MDN explains, it sends a "200 OK" message and starts sending the website's files as a series of small chunks called packets.
4. Assembly. The browser puts the chunks back together into a complete page and shows it.

You may have met some of the other replies. "404 Not Found" means the server is there, but has no page at that path — often a mistyped address or a page that has moved. Each is just the server's side of the conversation.

What the server sends: HTML, CSS, JavaScript and the rest

A web page is not one file. MDN describes HTML, CSS and JavaScript as the languages websites are written in, which the browser interprets and assembles into the page:

• HTML describes the content and its structure: this is a heading, this is a paragraph, here is an image (Lesson 5.1 — a markup language).
• CSS describes the look: colours, fonts, spacing, layout.
• JavaScript describes the behaviour: what happens when you tap a button, open a menu or submit a form — step-by-step instructions, run by your browser (Lesson 5.1).

And then there are the pictures (Lesson 2.4), fonts, icons and sometimes videos (Lesson 2.5). A typical page asks the server for dozens of separate files. Every one of them is bytes, sent as packets, counted against your data.

To save time and data, your browser keeps copies of files it has downloaded recently — its cache — so that the next time you visit the same site, the logo and fonts may not need downloading again. That is why a site often opens faster the second time.

The padlock: what HTTPS does — and doesn't

Look to the left of the address in your browser. On most sites you will see a small symbol — on Chrome, a padlock-style icon.

When an address begins https, the conversation between your browser and the server is encrypted: scrambled so that only the two ends can read it. Google's Chrome help explains that with a secure connection, information you send or get through the site is private between you and the site. Without it, Chrome shows Not secure, and Google warns that someone may be able to view and change the information you send and receive.

That matters on shared Wi-Fi, in cybercafés and on any network you don't control. Never type a password or card number into a page marked Not secure.

But here is what the padlock does not mean. It does not mean the site is honest. A criminal's fake bank site can have a perfectly good padlock: the conversation is private — between you and the criminal. Google's own advice is that even when connected securely, you should always be careful when sharing sensitive or personal information, and check the site name in the address bar to make sure you are on the site you want. The padlock tells you how you are talking. Only the domain tells you who you are talking to.

Tabs, memory and data

Every tab you open is a page held in your computer's memory (Lesson 4.3) — its HTML, its pictures, its running JavaScript. That is why twenty open tabs slowed Blessing's laptop to a crawl. A tab you are not looking at may still be using memory, and some keep running scripts or playing video in the background, using data as well.

Two habits help: close tabs you have finished with, and be careful with sites that play videos automatically when you are on a small bundle (Lesson 2.5). Bookmark what you want to come back to instead of keeping it open for days.

Reading the address bar like a professional

Here is the most useful skill in this lesson. When you need to know whose site you are on, find the domain — the part between :// and the first single slash — and read it from the right.

The rightmost part is the top-level domain, like .com or .ng (Lesson 7.5). Just to its left is the name that was actually registered. That pair is who you are dealing with. Everything further left is just a label the owner chose.

(The last two use .example, a top-level domain reserved for examples like these, so they lead nowhere.) The third and fourth addresses are the kind of trick criminals use: they put a real name at the left, where people look first, and their own domain at the right, where it decides everything. Read from the right, and the trick fails. Module 9 will build on this habit to spot fake websites.

Common mistakes

The short version

• A URL has parts: scheme (https), domain (which server), path (which page), parameters (extra information) and anchor (a place in the page, never sent to the server).
• Opening a page, as MDN describes it: DNS lookup → HTTP request → "200 OK" and files sent as packets → browser assembles the page.
• Pages are built from HTML (content), CSS (look) and JavaScript (behaviour), plus images and fonts. The cache keeps copies to save time and data.
• HTTPS makes the conversation private, Google explains; Not secure means others may view or change it. The padlock does not prove the site is honest.
• To know whose site you are on, read the domain from the right.

Try it yourself

Read the web like a professional.

1. Copy the address of three pages you visited today. For each, label the scheme, domain, path, and any parameters or anchor.
2. Click the icon to the left of the address on a site you use, and read what your browser says about the connection. Find one site, if you can, that shows Not secure — and do not type anything into it.
3. Right-click a web page and choose View page source (Lesson 5.1). Find a link to a CSS file and a script. How many separate files can you count?
4. Read these from the right and say who each really belongs to: https://support.microsoft.com.help-centre.example/, https://accounts.google.com/, https://www.mybank.com.ng-secure.example/ (just read them — don't visit).
5. Count your open tabs right now. Close every one you don't need, and watch your memory use in Task Manager drop.

You'll know you've got it when you can explain what happens between typing an address and seeing a page, name every part of a URL, and tell at a glance whose website you are really on — padlock or no padlock.