The journey of a URL

Une demi-seconde, une dizaine d'étapes

Tu tapes web-developpeur.com dans la barre d'adresse. Tu appuies sur Entrée. Une demi-seconde plus tard, la page est là.

Que s'est-il passé pendant cette demi-seconde ? Pose la question autour de toi. La plupart des devs répondent « euh... la page arrive ». C'est vrai, mais ça ne dit rien.

Cette demi-seconde contient une dizaine d'étapes bien distinctes. Ton navigateur cherche une adresse dans un annuaire, ouvre un canal sécurisé, envoie une demande polie, attend une réponse, puis dessine le résultat. Chaque étape a un nom, un rôle, et ses propres pièges.

Ce cours démonte ce voyage, morceau par morceau. À la fin, tu sauras lire ce que ton navigateur fait vraiment quand tu cliques. Et tu comprendras un seul grand principe qui explique presque toute la performance du web : sur le réseau, ce qui coûte, c'est l'aller-retour.

Pour suivre tout le cours, on garde une image simple : une page web, c'est du courrier. Une requête, c'est une lettre. Les en-têtes, c'est l'enveloppe. Et le facteur qui livre n'a aucune mémoire d'une lettre à l'autre. Garde cette métaphore en tête, on s'en sert à chaque leçon.

Première idée fausse : « une page, c'est une requête »

Quand on débute, on imagine que charger une page, c'est aller chercher UN fichier. Tu demandes la page, on te la donne, fini. C'est faux, et c'est l'erreur la plus répandue.

Prédis avant de lire

Pour afficher une page d'accueil ordinaire (un peu de texte, un logo, du style, quelques scripts), combien de requêtes ton navigateur envoie-t-il, à ton avis ? Une seule ? Cinq ? Cinquante ?

Voir la réponse

Des dizaines, presque toujours. Ton navigateur demande d'abord le HTML. Il le lit, et il y découvre des liens : une feuille de style, des scripts, des images, des polices. Chacun de ces fichiers déclenche sa propre requête. Le HTML n'est que le plan ; tout le reste est récupéré ensuite, un fichier à la fois. Une simple page d'accueil tourne souvent autour de 10 à 50 requêtes. C'est exactement pour ça que « ce qui coûte, c'est l'aller-retour » : multiplie le coût d'un aller-retour par 30, et tu tiens la moitié du temps de chargement.

Le meilleur moyen de le voir de tes yeux : appuie sur F12 dans ton navigateur, va dans l'onglet Network, et recharge la page. Tu vois défiler la liste de tout ce qui est demandé. En attendant que tu le fasses chez toi, voici une version simulée de cet onglet pour une page d'accueil typique.

Ouvre l'onglet Network simulé

Requête	Statut	Type	Taille
`GET /`	200	document	14 ko
`GET /css/style.css`	200	stylesheet	32 ko
`GET /css/bootstrap.min.css`	200	stylesheet	120 ko
`GET /js/app.js`	200	script	18 ko
`GET /js/jquery.min.js`	200	script	86 ko
`GET /img/logo.svg`	200	image	4 ko
`GET /img/hero.webp`	200	image	210 ko
`GET /img/avatar.webp`	200	image	22 ko
`GET /fonts/montserrat.woff2`	200	font	28 ko
`GET /fonts/montserrat-bold.woff2`	200	font	29 ko
`GET /favicon.ico`	200	image	5 ko
`GET /api/stats`	200	fetch	1 ko

12 requêtes pour une page « simple ». Chez toi, F12 → Network te montre la vraie liste, en direct.

Le HTML arrive toujours en premier. C'est lui qui dit au navigateur tout ce qu'il faut aller chercher ensuite. Le navigateur lit le HTML, découvre les liens vers le CSS, le JS, les images, et lance une requête pour chacun. C'est un effet domino : un fichier en révèle d'autres.

La carte du voyage

Concentrons-nous sur la toute première requête : celle du HTML, quand tu valides l'adresse. Même cette requête unique passe par plusieurs étapes avant que le moindre octet ne revienne. Voici la carte complète. Chaque étape est une leçon à venir de ce cours.

Le cache. Le navigateur vérifie d'abord s'il a déjà la réponse en réserve. Si oui, il s'arrête là : pas d'aller-retour, c'est gratuit. (Leçon 7.)
Le DNS. web-developpeur.com n'est qu'un nom. Le réseau, lui, fonctionne avec des numéros (des adresses IP). Le navigateur consulte l'annuaire du web pour traduire le nom en numéro. (Leçon 3.)
La connexion. Une fois l'adresse connue, le navigateur ouvre un canal vers le serveur (TCP), puis le sécurise (TLS, le « S » de HTTPS). (Leçon 4.)
La requête HTTP. Le navigateur envoie sa demande : « donne-moi la page d'accueil ». C'est la lettre. (Leçon 5.)
La réponse. Le serveur renvoie un statut (200, tout va bien) et le contenu : le HTML.
Le rendu. Le navigateur lit le HTML, le dessine, et relance des requêtes pour le CSS, le JS, les images. On reboucle.

Le voyage d'une requête, du haut vers le bas. Chaque flèche est un coût ; le cache permet d'en sauter.

Deuxième idée fausse : « HTTP, c'est du HTML »

Les deux sigles se ressemblent, alors on les confond. Mais ils ne jouent pas dans la même cour.

Le HTML est un format de contenu : c'est la structure d'une page. HTTP est un protocole de transport : ce sont les règles de l'échange entre le navigateur et le serveur. HTTP est le camion ; le HTML est l'un des colis.

Et ce camion transporte bien plus que du HTML. Une image, une vidéo, un fichier CSS, un script, une réponse JSON d'une API : tout voyage par HTTP. Quand ton appli mobile parle à un serveur sans afficher la moindre page, elle parle quand même HTTP.

Dans l'onglet Network plus haut, regarde la colonne « Type ». Tu y vois document, stylesheet, script, image, font, fetch. Six natures de contenu différentes, un seul et même protocole pour les transporter toutes : HTTP.

Qui parle en premier ?

HTTP repose sur deux rôles. D'un côté le client (le plus souvent ton navigateur). De l'autre le serveur (la machine qui héberge le site).

La règle est simple et ne change jamais : c'est toujours le client qui parle en premier. Le client envoie une requête, le serveur renvoie une réponse. Une demande, une réponse. Jamais l'inverse.

Reprends la métaphore du courrier. Tu écris une lettre (la requête) et tu la postes. Le serveur la reçoit et te répond par retour de courrier (la réponse). Mais le serveur ne peut pas, de lui-même, glisser une lettre dans ta boîte sans que tu aies écrit avant. En HTTP classique, le serveur ne déclenche jamais l'échange. Il attend, il répond, point.

« le serveur ne parle jamais en premier » vaut pour HTTP classique. Des technologies plus récentes, comme les WebSockets, ouvrent un canal permanent où le serveur peut enfin pousser des messages tout seul. Mais elles commencent toujours par une requête HTTP normale du client pour ouvrir le canal. Le premier mot revient encore au client.

Half a second, about a dozen steps

You type web-developpeur.com in the address bar. You press Enter. Half a second later, the page is there.

What happened during that half second? Ask around. Most devs answer "uh... the page shows up". True, but that says nothing.

That half second holds about a dozen distinct steps. Your browser looks up an address in a directory, opens a secure channel, sends a polite request, waits for a reply, then draws the result. Each step has a name, a role, and its own traps.

This course takes that journey apart, piece by piece. By the end, you'll be able to read what your browser actually does when you click. And you'll understand one big principle that explains nearly all web performance: on the network, what costs is the round trip.

To follow the whole course, we keep one simple image: a web page is mail. A request is a letter. The headers are the envelope. And the postman who delivers it has no memory from one letter to the next. Keep that metaphor in mind; we use it in every lesson.

First wrong idea: "one page is one request"

When you start out, you imagine that loading a page means fetching ONE file. You ask for the page, they hand it over, done. That's wrong, and it's the most common mistake.

Predict before reading on

To display an ordinary homepage (some text, a logo, some style, a few scripts), how many requests does your browser send, in your view? Just one? Five? Fifty?

Show the answer

Dozens, almost always. Your browser first asks for the HTML. It reads it, and finds links inside: a stylesheet, scripts, images, fonts. Each of those files triggers its own request. The HTML is only the blueprint; everything else is fetched afterwards, one file at a time. A plain homepage often runs around 10 to 50 requests. That's exactly why "what costs is the round trip": multiply the cost of one round trip by 30, and you've got half the load time.

The best way to see it with your own eyes: press F12 in your browser, go to the Network tab, and reload the page. You'll see the list of everything being requested scroll by. While you go try it at home, here's a simulated version of that tab for a typical homepage.

Open the simulated Network tab

Request	Status	Type	Size
`GET /`	200	document	14 kB
`GET /css/style.css`	200	stylesheet	32 kB
`GET /css/bootstrap.min.css`	200	stylesheet	120 kB
`GET /js/app.js`	200	script	18 kB
`GET /js/jquery.min.js`	200	script	86 kB
`GET /img/logo.svg`	200	image	4 kB
`GET /img/hero.webp`	200	image	210 kB
`GET /img/avatar.webp`	200	image	22 kB
`GET /fonts/montserrat.woff2`	200	font	28 kB
`GET /fonts/montserrat-bold.woff2`	200	font	29 kB
`GET /favicon.ico`	200	image	5 kB
`GET /api/stats`	200	fetch	1 kB

12 requests for a "simple" page. At home, F12 → Network shows you the real list, live.

The HTML always arrives first. It's what tells the browser everything else to go fetch. The browser reads the HTML, finds the links to the CSS, the JS, the images, and fires a request for each one. It's a domino effect: one file reveals others.

The map of the journey

Let's focus on the very first request: the one for the HTML, when you confirm the address. Even that single request goes through several steps before a single byte comes back. Here's the full map. Each step is a lesson coming up in this course.

The cache. The browser first checks whether it already has the reply in store. If so, it stops there: no round trip, it's free. (Lesson 7.)
DNS. web-developpeur.com is just a name. The network itself works with numbers (IP addresses). The browser consults the web's address book to translate the name into a number. (Lesson 3.)
The connection. Once the address is known, the browser opens a channel to the server (TCP), then secures it (TLS, the "S" in HTTPS). (Lesson 4.)
The HTTP request. The browser sends its demand: "give me the homepage". That's the letter. (Lesson 5.)
The response. The server returns a status (200, all good) and the content: the HTML.
The render. The browser reads the HTML, draws it, and fires off new requests for the CSS, the JS, the images. We loop back.

A request's journey, top to bottom. Each arrow is a cost; the cache lets you skip some.

Second wrong idea: "HTTP is HTML"

The two acronyms look alike, so people mix them up. But they don't play in the same league.

HTML is a content format: it's the structure of a page. HTTP is a transport protocol: the rules of the exchange between browser and server. HTTP is the truck; HTML is one of the parcels.

And that truck carries far more than HTML. An image, a video, a CSS file, a script, a JSON response from an API: it all travels over HTTP. When your mobile app talks to a server without showing a single page, it still speaks HTTP.

In the Network tab above, look at the "Type" column. You see document, stylesheet, script, image, font, fetch. Six different kinds of content, one single protocol to carry them all: HTTP.

Who speaks first?

HTTP rests on two roles. On one side the client (most often your browser). On the other the server (the machine that hosts the site).

The rule is simple and never changes: the client always speaks first. The client sends a request, the server sends back a response. One demand, one reply. Never the other way around.

Back to the mail metaphor. You write a letter (the request) and post it. The server receives it and replies by return of post (the response). But the server cannot, on its own, slip a letter into your mailbox unless you wrote first. In classic HTTP, the server never starts the exchange. It waits, it replies, full stop.

"the server never speaks first" holds for classic HTTP. Newer technologies, like WebSockets, open a permanent channel where the server can finally push messages on its own. But they always begin with a normal HTTP request from the client to open the channel. The first word still belongs to the client.

Next step

You've got the map of the journey. First concrete step: knowing how to read an address. In lesson 2, you take a URL apart piece by piece, and you discover that one part of the address is NEVER sent to the server.

Lesson 2: The anatomy of a URL →