il y a 1 an

Pages Web : HTML, CSS, JavaScript et voyage d’une requête

Vous saisissez une adresse dans votre navigateur, appuyez sur Entrée et, quelques centaines de millisecondes plus tard, une page apparaît.

Texte, images, menus, formulaires, vidéos, animations, boutons, commentaires, panier d’achat et parfois une bannière de consentement suffisamment grande pour masquer le site qu’elle prétend protéger.

Tout cela paraît presque instantané.

Derrière cette banalité quotidienne se trouvent pourtant plusieurs technologies qui doivent coopérer :

une URL ;
DNS ;
IP ;
TCP ou QUIC ;
TLS pour HTTPS ;
HTTP ;
un ou plusieurs serveurs ;
HTML ;
CSS ;
JavaScript ;
des images, polices et autres ressources ;
puis un navigateur chargé de transformer tout cela en pixels utilisables.

Une page Web n’est donc pas simplement un fichier que le navigateur « ouvre » : c’est le résultat d’un échange de ressources et d’un processus de rendu.

Et lorsque tout fonctionne, l’utilisateur ne voit rien de cette mécanique.

Ce qui est probablement mieux pour tout le monde.

Qu’est-ce qu’une page Web ?

Une page Web est un document ou une interface accessible à travers le Web et présentée par un navigateur.

Elle repose très souvent sur un document HTML initial, mais ce document peut provenir de nombreuses architectures différentes.

Il peut être :

un fichier .html stocké sur disque ;
généré à la demande par PHP, Python, Java, C#, Ruby ou JavaScript ;
pré-généré lors de la construction du site ;
servi depuis un cache ;
distribué par un CDN ;
complété ensuite avec des données récupérées par JavaScript ;
ou réduit à une enveloppe initiale dont une application JavaScript construit ensuite presque toute l’interface.

Il n’existe donc pas forcément quelque part sur le serveur un fichier nommé :

article-42.html

correspondant exactement à ce que vous voyez.

L’URL :

https://example.com/articles/42

peut déclencher du code qui récupère des données, applique un modèle HTML, vérifie vos permissions, consulte un cache et fabrique la réponse spécialement pour cette requête.

Le fichier innocent a déjà commencé à perdre son innocence.

Page Web, site Web et application Web

Ces termes sont proches mais ne désignent pas exactement la même chose.

Terme	Idée générale
Page Web	Document ou vue individuelle accessible par une URL
Site Web	Ensemble organisé de pages et ressources
Application Web	Interface Web proposant une logique applicative importante

Un article de documentation est clairement une page Web.

Un ensemble de milliers d’articles forme un site Web.

Une messagerie, un traitement de texte collaboratif ou un outil de gestion accessible dans le navigateur se rapproche davantage d’une application Web.

Les frontières ne sont pas parfaitement rigides.

Un site d’actualité possède aujourd’hui parfois plus de JavaScript qu’un logiciel de bureau des années 2000.

HTML : la structure et le sens du document

HTML — HyperText Markup Language est un langage de balisage.

Ce n’est pas, dans son rôle fondamental, un langage de programmation généraliste.

HTML sert à décrire la structure et la sémantique du contenu.

Par exemple :

<h2>Les sauvegardes</h2>

<p>Une sauvegarde non testée est une hypothèse.</p>

<a href="/sauvegardes">Lire la suite</a>

Le navigateur comprend que :

<h2> représente un titre de section ;
<p> représente un paragraphe ;
<a> représente un lien hypertexte.

HTML ne décrit pas seulement l’apparence

Un titre HTML n’est pas simplement :

« du texte gros et gras ».

L’élément :

<h2>

exprime le rôle sémantique :

« Ceci est un titre de niveau 2. »

Son apparence peut ensuite être totalement modifiée avec CSS.

De même :

<nav>

indique une zone de navigation.

<main>

identifie le contenu principal.

<article>

représente un contenu autonome.

<button>

désigne un contrôle interactif.

Cette sémantique aide notamment :

les navigateurs ;
les technologies d’assistance ;
les moteurs de recherche ;
les développeurs ;
les outils automatisés.

Une structure HTML minimale

Un document HTML complet peut commencer ainsi :

<!doctype html>
<html lang="fr">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Mon premier site</title>
</head>
<body>
    <h1>Bonjour Internet</h1>
    <p>Le serveur fonctionne. Pour l'instant.</p>
</body>
</html>

<head> contient principalement des métadonnées et références utilisées par le document.

<body> contient le contenu principal affiché ou utilisé dans la page.

Quelques éléments HTML essentiels

Élément	Rôle
`<h1>` à `<h6>`	Titres et sous-titres
`<p>`	Paragraphe
`<a>`	Lien
`<img>`	Image
`<ul>`, `<ol>`, `<li>`	Listes
`<table>`	Données tabulaires
`<form>`	Formulaire
`<button>`	Bouton interactif
`<header>`	En-tête d’une page ou section
`<nav>`	Navigation
`<main>`	Contenu principal
`<article>`	Contenu autonome
`<section>`	Section thématique
`<footer>`	Pied de page ou de section

HTML n’est pas totalement incapable d’interaction

On entend souvent :

« Sans JavaScript, une page HTML ne peut rien faire. »

C’est excessif.

HTML possède déjà de nombreux comportements natifs.

Un lien fonctionne :

<a href="/contact">Contact</a>

Un formulaire peut être envoyé :

<form method="post" action="/connexion">
    <input type="email" name="email" required>
    <button type="submit">Connexion</button>
</form>

Et un élément comme :

<details>
    <summary>Afficher les détails</summary>
    <p>Aucun JavaScript n'a été blessé pendant cette interaction.</p>
</details>

possède déjà un comportement interactif fourni par le navigateur.

JavaScript devient nécessaire lorsque la logique demandée dépasse ces fonctionnalités natives.

CSS : la présentation

CSS — Cascading Style Sheets est un langage de feuilles de style.

Il permet de décrire la présentation du document.

Par exemple :

body {
    font-family: sans-serif;
    line-height: 1.6;
}

article {
    max-width: 70rem;
    margin-inline: auto;
}

h2 {
    font-size: 2rem;
}

CSS contrôle notamment :

les couleurs ;
les polices ;
les espacements ;
les bordures ;
les dimensions ;
le positionnement ;
les grilles ;
les dispositions flexibles ;
les adaptations aux écrans ;
les transitions ;
les animations.

HTML sans CSS reste parfaitement affichable

Un navigateur possède sa propre feuille de styles par défaut.

Même sans CSS fourni par l’auteur, un :

<h1>

apparaîtra généralement comme un grand titre et un :

<a>

comme un lien identifiable.

Ce n’est pas HTML qui décide directement :

h1 = 32 pixels gras

Le navigateur applique ses styles par défaut.

CSS permet ensuite à l’auteur de les remplacer ou de les compléter.

CSS sait aussi faire bouger des choses

Réduire CSS au « maquillage » est pratique pour débuter, mais incomplet.

CSS sait également gérer :

des animations ;
des transitions ;
des états comme :hover ou :focus ;
des adaptations à la taille de l’écran ;
des mises en page complexes ;
des comportements visuels conditionnels.

Par exemple :

button {
    transition: transform 150ms ease;
}

button:hover {
    transform: scale(1.05);
}

Aucun JavaScript n’est nécessaire pour cela.

Il est parfaitement possible de faire bouger un bouton sans convoquer 4 Mo de dépendances npm.

JavaScript : la logique programmable

JavaScript est un véritable langage de programmation.

Dans le navigateur, il peut notamment :

réagir aux actions de l’utilisateur ;
modifier le DOM ;
effectuer des calculs ;
envoyer de nouvelles requêtes réseau ;
mettre à jour une partie de la page ;
utiliser le stockage local ;
dessiner dans un canvas ;
manipuler audio et vidéo ;
interagir avec différentes API du navigateur.

Exemple :

const bouton = document.querySelector("#bonjour");

bouton.addEventListener("click", () => {
    document.querySelector("#message").textContent =
        "Le JavaScript fonctionne. Personne ne sait encore pour combien de temps.";
});

JavaScript et le navigateur ne sont pas la même chose

Il faut distinguer :

JavaScript
+
API fournies par l'environnement

Le langage JavaScript connaît des concepts comme :

variables ;
fonctions ;
objets ;
tableaux ;
boucles ;
promesses.

Le navigateur lui fournit ensuite des API comme :

document
fetch()
localStorage
navigator
setTimeout()

Le DOM n’est donc pas « une partie du langage JavaScript » au sens strict.

C’est une API de la plateforme Web que JavaScript peut manipuler.

Le trio classique

Pour retenir l’idée générale :

Technologie	Rôle principal
HTML	Contenu, structure et sémantique
CSS	Présentation et mise en page
JavaScript	Logique programmable et interactions avancées

La simplification est utile tant que l’on garde en mémoire que les frontières ne sont pas totalement hermétiques.

Une page statique n’est pas forcément une page immobile

Le mot :

statique

est souvent mal interprété.

Une page statique signifie généralement que son contenu initial peut être servi tel qu’il a été préparé, sans qu’un programme côté serveur ait besoin de le générer spécifiquement pour chaque visite.

Par exemple :

/var/www/site/index.html

peut être renvoyé directement lorsque le navigateur demande :

https://example.com/

Une page statique peut avoir du JavaScript

Ce document peut très bien contenir :

des menus interactifs ;
une galerie ;
un formulaire ;
des animations ;
un moteur de recherche exécuté localement ;
des appels vers une API ;
une application JavaScript entière.

Le serveur peut donc servir un ensemble totalement statique :

index.html
styles.css
app.js

alors que l’expérience utilisateur est extrêmement dynamique.

Statique côté serveur ne signifie pas immobile côté navigateur.

Les pages générées côté serveur

Dans une architecture dynamique classique, le serveur reçoit une requête puis exécute du code.

Conceptuellement :

Navigateur
    ↓
Requête HTTP
    ↓
Serveur Web
    ↓
Application
    ↓
Base de données
    ↓
Template
    ↓
HTML généré
    ↓
Réponse HTTP
    ↓
Navigateur

Le HTML envoyé peut dépendre :

de l’URL ;
de l’utilisateur ;
de ses permissions ;
des données en base ;
du panier ;
de la langue ;
de paramètres de recherche ;
de l’état de l’application.

PHP : le grand ancien qui refuse de mourir

PHP est un langage particulièrement associé au Web côté serveur.

Un exemple simplifié :

<?php
$nom = "Alice";
?>

<p>Bonjour <?= htmlspecialchars($nom) ?></p>

Le navigateur ne reçoit normalement pas le code PHP.

Le serveur l’exécute puis renvoie le résultat produit, par exemple :

<p>Bonjour Alice</p>

Si votre serveur commence à envoyer directement :

<?php

aux visiteurs, vous n’avez pas inventé une nouvelle architecture.

Vous avez probablement cassé PHP.

WordPress : un excellent exemple de génération dynamique

Un CMS comme WordPress illustre très bien cette architecture.

Lorsqu’un visiteur demande un article, une chaîne simplifiée peut ressembler à :

URL
 ↓
Serveur Web
 ↓
PHP / WordPress
 ↓
Base de données
 ↓
Thème + contenu + extensions
 ↓
HTML
 ↓
Navigateur

Mais un système de cache peut également avoir préparé la réponse auparavant.

Le visiteur suivant peut alors recevoir directement une version mise en cache sans obliger PHP et la base de données à refaire tout le travail.

Une page peut donc être :

dynamiquement administrée mais servie comme une réponse pré-calculée.

Le Web aime les catégories.

Puis il passe vingt ans à inventer des architectures qui traversent leurs frontières.

Python côté serveur

Python peut être utilisé avec des frameworks comme :

Django ;
Flask ;
FastAPI ;
et d’autres.

Le framework reçoit les requêtes, exécute la logique applicative et produit une réponse.

Cette réponse peut être :

du HTML ;
du JSON ;
une image ;
un fichier ;
une redirection ;
ou simplement un statut HTTP.

Node.js : JavaScript côté serveur, mais pas un nouveau langage

Node.js n’est pas un langage.

Le langage reste :

JavaScript

Node.js est un environnement d’exécution JavaScript utilisable hors du navigateur.

Il fournit notamment des API pour :

les fichiers ;
le réseau ;
les processus ;
les flux ;
la création de serveurs.

Un serveur HTTP minimal peut conceptuellement ressembler à :

import { createServer } from "node:http";

const server = createServer((request, response) => {
    response.writeHead(200, {
        "Content-Type": "text/plain; charset=utf-8"
    });

    response.end("Bonjour depuis Node.js");
});

server.listen(3000);

JavaScript peut donc fonctionner :

dans le navigateur
et
sur le serveur

mais l’environnement et les API disponibles sont différents.

Ruby, Java, C#, Go et les autres

Le serveur Web ne possède aucune obligation philosophique envers PHP.

Une application Web peut être développée avec :

Ruby et Rails ;
Java et Spring ;
C# et ASP.NET Core ;
Go ;
Rust ;
JavaScript ou TypeScript ;
Python ;
PHP ;
et quantité d’autres technologies.

Ce qui compte pour le navigateur est principalement la réponse obtenue.

Il n’a généralement aucune raison de savoir que :

<h1>Bonjour</h1>

a été généré par PHP, Java, Python ou par un stagiaire extrêmement motivé écrivant les réponses HTTP à la main.

Le serveur peut renvoyer autre chose que du HTML

Une application moderne peut demander :

GET /api/utilisateurs/42

et recevoir :

{
    "id": 42,
    "nom": "Alice"
}

avec un type :

application/json

JavaScript utilise alors ces données pour mettre à jour la page.

Le serveur n’a généré aucun HTML.

Il a simplement envoyé des données structurées.

Le Content-Type : dire au navigateur ce qu’il reçoit

HTTP possède l’en-tête :

Content-Type

qui indique le type de média de la ressource.

Exemples :

Content-Type: text/html; charset=utf-8
Content-Type: text/css
Content-Type: application/javascript
Content-Type: application/json
Content-Type: image/png

Le navigateur s’appuie fortement sur cette information pour savoir comment traiter la réponse.

L’extension dans l’URL ne suffit pas à définir le type HTTP d’une ressource.

Une URL comme :

https://example.com/image

peut parfaitement renvoyer :

Content-Type: image/jpeg

sans posséder :

.jpg

à la fin.

Client et serveur : les deux rôles fondamentaux

HTTP repose essentiellement sur un modèle :

client → requête
serveur → réponse

Dans le cas classique, le client est le :

navigateur

mais un client HTTP peut aussi être :

curl ;
une application mobile ;
un robot d’indexation ;
une API ;
un autre serveur ;
un outil de supervision.

Le client n’est donc pas exactement :

« l’utilisateur ».

C’est le programme qui agit comme client du protocole.

Le serveur n’est pas nécessairement une seule machine

Une URL semble souvent pointer vers :

un serveur

mais derrière, on peut trouver :

Internet
   ↓
CDN
   ↓
Load balancer
   ↓
Reverse proxy
   ↓
Serveur Web
   ↓
Application
   ↓
Cache
   ↓
Base de données
   ↓
Stockage objet

Plusieurs machines peuvent répondre au même nom.

Le trafic peut être réparti entre plusieurs régions.

Un CDN peut même répondre sans que la requête atteigne votre infrastructure principale.

L’idée :

« www.example.com correspond à l’ordinateur www.example.com. »

est donc parfaitement plausible sur un réseau simple et délicieusement naïve à grande échelle.

HTTP : le langage des échanges du Web

HTTP — HyperText Transfer Protocol définit notamment la manière dont clients et serveurs échangent des requêtes et réponses.

Un exemple pédagogique de requête HTTP/1.1 :

GET /articles/linux HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Navigateur-Magique/1.0

Le serveur peut répondre :

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

<!doctype html>
...

En HTTP/2 et HTTP/3, la représentation réellement transportée n’est plus simplement ce joli texte ligne par ligne, mais les sémantiques restent comparables :

méthode ;
ressource ;
en-têtes ;
code de statut ;
corps éventuel.

Les principales méthodes HTTP

Méthode	Usage général
`GET`	Récupérer une représentation d’une ressource
`HEAD`	Obtenir les en-têtes sans le corps correspondant
`POST`	Soumettre des données / déclencher un traitement
`PUT`	Créer ou remplacer une ressource selon l’API
`PATCH`	Modifier partiellement une ressource
`DELETE`	Demander la suppression d’une ressource
`OPTIONS`	Obtenir certaines informations sur les options de communication

Le navigateur utilise naturellement GET lorsqu’il récupère beaucoup de ressources.

Un formulaire peut utiliser :

GET

ou :

POST

selon son objectif.

Les codes de statut HTTP

La réponse contient un code indiquant ce qui s’est passé.

Code	Signification courante
`200 OK`	Succès
`201 Created`	Ressource créée
`301 Moved Permanently`	Redirection permanente
`302 Found`	Redirection temporaire selon l’usage courant
`304 Not Modified`	La représentation mise en cache peut être réutilisée
`400 Bad Request`	Requête invalide
`401 Unauthorized`	Authentification nécessaire ou invalide
`403 Forbidden`	Accès refusé
`404 Not Found`	Ressource non trouvée
`500 Internal Server Error`	Erreur interne côté serveur
`502 Bad Gateway`	Un intermédiaire a reçu une mauvaise réponse de l’amont
`503 Service Unavailable`	Service momentanément indisponible

404 et 500 ne racontent pas la même tragédie

Une erreur :

404 Not Found

signifie essentiellement :

« Je suis bien là, mais je ne trouve pas ce que tu demandes. »

Une :

500 Internal Server Error

signifie plutôt :

« J’ai reçu ta demande, puis quelque chose est mort à l’intérieur. »

Redémarrer Apache peut parfois masquer le problème.

Cela n’en fait pas pour autant une procédure universelle de débogage.

HTTP est sans état, mais le Web ne l’est pas vraiment

HTTP est conçu comme un protocole stateless : chaque requête peut être comprise indépendamment.

Pourtant, les applications veulent savoir :

si vous êtes connecté ;
ce qu’il y a dans votre panier ;
votre langue ;
vos préférences ;
quelle étape d’un processus vous avez atteinte.

On utilise donc des mécanismes supplémentaires comme :

cookies ;
sessions côté serveur ;
tokens ;
stockage côté navigateur.

Les cookies

Un serveur peut envoyer un en-tête :

Set-Cookie: session=abc123; Secure; HttpOnly

Le navigateur pourra ensuite renvoyer ce cookie dans les requêtes appropriées :

Cookie: session=abc123

Le serveur peut ainsi retrouver une session associée.

Le cookie ne contient pas nécessairement toutes les données de session.

Il peut simplement contenir un identifiant renvoyant vers des informations stockées côté serveur.

HTTP et HTTPS

HTTPS n’est pas un protocole Web totalement différent de HTTP.

Il s’agit essentiellement d’HTTP transporté à travers une connexion protégée par TLS.

TLS apporte notamment :

confidentialité ;
intégrité ;
authentification cryptographique du serveur à l’aide de certificats ;
et éventuellement authentification du client dans certaines architectures.

Sans TLS, un intermédiaire capable d’observer ou modifier le trafic pourrait potentiellement lire ou altérer les échanges HTTP.

HTTPS ne signifie pas que le site est honnête

Le petit cadenas répond surtout à une question :

« La communication avec ce serveur est-elle protégée et l’identité présentée par le serveur correspond-elle au certificat accepté ? »

Il ne répond pas :

« Le propriétaire de ce site est-il moralement irréprochable ? »

Un site de phishing peut parfaitement utiliser HTTPS.

Le chiffrement protège également les criminels de l’écoute réseau.

Les mathématiques ont toujours eu cette inquiétante impartialité.

L’URL : l’adresse de la ressource

Prenons :

https://www.example.com:443/articles/web?page=2#html

On peut identifier plusieurs parties :

Partie	Valeur
Schéma	`https`
Hôte	`www.example.com`
Port	`443`
Chemin	`/articles/web`
Query string	`?page=2`
Fragment	`#html`

Le fragment # n’est normalement pas envoyé au serveur

Pour :

https://example.com/article#conclusion

la partie :

#conclusion

est normalement interprétée côté client.

Le serveur reçoit la demande pour :

/article

Le navigateur utilise ensuite le fragment, par exemple pour se déplacer jusqu’à :

id="conclusion"

dans le document.

Le serveur n’a donc pas nécessairement la moindre idée que vous avez sauté directement à la conclusion.

Votre impatience reste entre vous et le navigateur.

Que se passe-t-il lorsque vous tapez une URL ?

La version simple est :

le navigateur interprète l’URL ;
il détermine où joindre le serveur ;
une connexion est établie si nécessaire ;
une requête HTTP est envoyée ;
une réponse revient ;
le navigateur traite les ressources ;
la page est rendue.

La réalité contient quelques étapes supplémentaires.

Étape 1 : analyser l’URL

Le navigateur commence par comprendre :

https://www.example.com/article?id=42

Il identifie notamment :

le schéma https ;
le nom d’hôte www.example.com ;
le chemin /article ;
la query ?id=42.

Étape 2 : trouver une adresse réseau

Si aucune information suffisamment fraîche n’est déjà disponible dans un cache, le nom :

www.example.com

doit généralement être résolu en une ou plusieurs adresses IP.

DNS peut retourner par exemple :

IPv4 : 203.0.113.20
IPv6 : 2001:db8::20

Le navigateur ou le système choisira ensuite une destination appropriée.

Le navigateur ne fait pas forcément « une requête DNS » à chaque page

Des caches peuvent exister à plusieurs niveaux :

navigateur ;
système d’exploitation ;
résolveur local ;
résolveur récursif.

La résolution peut également passer par DNS over HTTPS ou d’autres mécanismes selon la configuration.

Dire :

« Chaque fois que vous cliquez, le navigateur demande immédiatement au DNS. »

est donc une simplification.

Les caches existent précisément pour éviter que tout Internet ne répète éternellement les mêmes questions.

Étape 3 : établir le transport

Pour HTTP/1.1 et HTTP/2, on rencontre traditionnellement :

IP
↓
TCP
↓
TLS si HTTPS
↓
HTTP

Pour HTTP/3 :

IP
↓
UDP
↓
QUIC avec TLS intégré au protocole
↓
HTTP/3

Le navigateur et le serveur négocient les mécanismes compatibles.

HTTP/1.1, HTTP/2 et HTTP/3

Version	Caractéristique simplifiée
HTTP/1.1	Connexions persistantes mais modèle historique relativement séquentiel par connexion
HTTP/2	Multiplexage de plusieurs flux sur une connexion TCP
HTTP/3	HTTP sur QUIC, lui-même construit au-dessus d’UDP

Pour le développeur applicatif, les concepts :

GET
POST
headers
200
404
Content-Type

continuent d’exister.

Ce qui change fortement est la manière dont ces informations sont transportées.

Étape 4 : TLS pour HTTPS

Avec HTTPS, client et serveur doivent établir une communication protégée.

Le navigateur vérifie notamment le certificat présenté selon sa chaîne de confiance et le nom demandé.

Une fois le canal sécurisé établi, les échanges HTTP peuvent circuler à l’intérieur.

Étape 5 : envoyer la requête

Le navigateur demande par exemple :

GET /article?id=42

avec différents en-têtes décrivant le contexte.

Le serveur reçoit cette demande.

Étape 6 : le serveur décide quoi répondre

Il peut :

lire directement un fichier ;
répondre depuis un cache ;
exécuter une application ;
interroger une base de données ;
demander la ressource à un autre serveur ;
effectuer une redirection ;
refuser l’accès ;
ou constater qu’il n’a absolument aucune idée de ce que vous voulez.

Dans ce dernier cas :

reste une option parfaitement respectable.

Étape 7 : recevoir le HTML

Une réponse peut commencer avec :

200 OK
Content-Type: text/html; charset=utf-8

puis contenir le document HTML.

Le navigateur n’attend pas nécessairement que l’intégralité du fichier soit arrivée avant de commencer à le traiter.

Le parsing peut progresser pendant la réception.

Étape 8 : construire le DOM

Le navigateur analyse le HTML et construit une représentation en arbre appelée :

DOM
Document Object Model

Pour :

<body>
    <article>
        <h2>Bonjour</h2>
        <p>Bienvenue.</p>
    </article>
</body>

on peut imaginer :

Document
└── html
    └── body
        └── article
            ├── h2
            └── p

JavaScript peut ensuite interroger et modifier cet arbre.

Le DOM n’est pas simplement le fichier HTML

C’est une distinction importante.

Le HTML est une source.

Le DOM est la représentation construite et maintenue par le navigateur.

JavaScript peut par exemple ajouter :

<p>Ajouté dynamiquement</p>

sans que cette ligne ait jamais existé dans le HTML reçu depuis le serveur.

Le DOM final peut donc différer considérablement de la source initiale.

Étape 9 : récupérer les sous-ressources

En analysant le document, le navigateur découvre par exemple :

<link rel="stylesheet" href="/styles.css">

<script src="/app.js"></script>

<img src="/images/chat.jpg" alt="Un chat">

Il effectue alors d’autres requêtes pour récupérer ces ressources.

Une page Web ne correspond donc généralement pas à :

1 URL = 1 requête

mais plutôt à :

1 navigation
+
de nombreuses requêtes de ressources

Ces ressources peuvent venir d’autres serveurs

Le HTML peut provenir de :

www.example.com

tandis que :

les images viennent d’un CDN ;
les polices d’un autre domaine ;
une API d’un troisième ;
une vidéo d’une plateforme externe.

Une seule page peut donc impliquer plusieurs infrastructures indépendantes.

Ce qui explique pourquoi une page « hébergée sur notre serveur » peut parfois attendre désespérément un script situé à l’autre bout du monde.

CSSOM, styles et rendu

Le navigateur traite également CSS et construit les informations nécessaires pour déterminer les styles applicables.

On rencontre le concept de :

CSSOM
CSS Object Model

Le navigateur combine les informations de structure et de styles pour déterminer ce qui doit être dessiné.

Le chemin de rendu simplifié

On peut résumer :

HTML
 ↓
DOM

CSS
 ↓
CSSOM

DOM + styles
 ↓
arbre de rendu
 ↓
layout
 ↓
paint
 ↓
composition
 ↓
pixels

Layout : où placer les choses ?

Le navigateur calcule les dimensions et positions.

Par exemple :

largeur de l’article ;
hauteur du paragraphe ;
position de l’image ;
taille de la police ;
marges ;
grilles ;
éléments flexibles.

Cette étape est généralement appelée :

layout

ou parfois :

reflow

selon le contexte.

Paint : dessiner

Après avoir déterminé les positions, le navigateur doit peindre les éléments :

texte ;
fonds ;
bordures ;
ombres ;
images.

Puis différentes couches peuvent être composées pour former le résultat affiché.

Votre simple :

<p>Bonjour</p>

a donc traversé davantage d’étapes qu’un dossier administratif.

JavaScript peut modifier la page après son affichage

Une fois chargé, JavaScript peut faire :

document.querySelector("h2").textContent =
    "Le titre vient de changer";

Le navigateur met alors à jour ce qui est nécessaire.

Selon les modifications, cela peut entraîner :

recalcul de styles ;
nouveau layout ;
repaint ;
recomposition.

Les performances Web ne concernent donc pas uniquement la vitesse du serveur.

Un navigateur peut parfaitement recevoir la page très vite puis passer un temps respectable à exécuter 7 Mo de JavaScript destiné à afficher un menu hamburger.

Client-side rendering : construire l’interface dans le navigateur

Une application peut recevoir un HTML initial très léger :

<div id="app"></div>
<script src="/app.js"></script>

Puis JavaScript :

s’exécute ;
interroge une API ;
récupère les données ;
construit l’interface ;
modifie le DOM.

C’est une forme de :

Client-Side Rendering
CSR

Server-side rendering

Avec le :

Server-Side Rendering
SSR

le serveur génère déjà le HTML correspondant au contenu.

Le navigateur reçoit quelque chose comme :

<article>
    <h2>Mon article</h2>
    <p>Voici déjà le contenu.</p>
</article>

JavaScript peut ensuite enrichir cette page.

Hydratation

Certaines architectures envoient du HTML généré côté serveur puis chargent JavaScript afin de rendre cette interface pleinement interactive.

On parle souvent :

d'hydratation

Conceptuellement :

HTML généré sur le serveur
        ↓
page déjà visible
        ↓
JavaScript chargé
        ↓
comportements interactifs attachés

Le terme est étrange.

Mais « ressusciter l’application côté client en lui injectant trois mégaoctets de JavaScript » était probablement moins vendeur.

Static Site Generation

Autre possibilité :

SSG
Static Site Generation

Le site est généré avant les visites.

Par exemple :

Markdown
+
templates
+
données
↓
phase de build
↓
HTML statique
↓
CDN

Lorsque le visiteur arrive, le HTML existe déjà.

On déplace donc le coût de génération :

de chaque requête

vers :

la phase de construction du site

SSR, CSR et SSG ne sont pas des religions

Les architectures modernes peuvent combiner :

rendu statique ;
rendu serveur ;
rendu client ;
cache ;
hydratation ;
mise à jour partielle ;
fonctions exécutées à la périphérie du réseau.

Une même application peut employer plusieurs approches selon les pages.

Il est donc rarement utile d’organiser une guerre civile entre :

SSR
CSR
SSG

Chacun résout des problèmes différents.

Les bases de données

Les pages dynamiques s’appuient souvent sur une base de données.

On peut y stocker :

utilisateurs ;
articles ;
produits ;
commentaires ;
commandes ;
permissions ;
configurations applicatives.

Par exemple :

GET /article/42
        ↓
application
        ↓
SELECT article WHERE id = 42
        ↓
template
        ↓
HTML

Le navigateur n’accède généralement pas directement à MySQL ou PostgreSQL.

L’application serveur sert d’intermédiaire.

Une base de données n’est pas obligatoire

Un site dynamique peut utiliser :

des fichiers ;
des API ;
des services distants ;
du stockage objet ;
des caches ;
des bases relationnelles ;
des bases documentaires ;
ou plusieurs de ces mécanismes simultanément.

« Page dynamique » ne signifie donc pas automatiquement :

PHP + MySQL

même si cette combinaison possède une longue et honorable carrière.

Le serveur Web

Le serveur HTTP est le logiciel chargé de recevoir et traiter des requêtes Web.

On rencontre notamment :

Apache HTTP Server ;
Nginx ;
Caddy ;
Lighttpd ;
Microsoft IIS ;
des serveurs intégrés à différents frameworks ou runtimes.

Le serveur Web ne génère pas nécessairement lui-même l’application

Une architecture classique peut être :

Navigateur
    ↓
Nginx
    ↓
PHP-FPM
    ↓
WordPress
    ↓
MariaDB

ou :

Navigateur
    ↓
Nginx
    ↓
Application Python
    ↓
PostgreSQL

Nginx peut notamment :

terminer TLS ;
servir des fichiers statiques ;
faire office de reverse proxy ;
transmettre certaines requêtes à l’application.

Reverse proxy

Un reverse proxy reçoit les requêtes publiques puis les transmet vers les services internes appropriés.

Par exemple :

Internet
   ↓
Nginx
   ├── /api → application API
   ├── /images → stockage statique
   └── / → application principale

Le navigateur ne voit pas nécessairement toute cette architecture.

Pour lui :

https://example.com

reste simplement le site.

L’hébergement mutualisé

Avec un hébergement mutualisé, plusieurs clients partagent une infrastructure administrée par l’hébergeur.

Avantages :

coût réduit ;
administration simplifiée ;
mise en service facile.

Limites possibles :

moins de contrôle ;
ressources partagées ;
choix techniques plus limités.

Ce n’est pas forcément « peu performant ».

Un bon hébergement mutualisé peut parfaitement être très rapide pour la charge qu’il cible.

Il devient surtout limitant lorsque vous avez besoin de contrôler davantage l’environnement.

Le VPS

Un :

Virtual Private Server
VPS

fournit un environnement virtuel relativement autonome.

Vous pouvez souvent contrôler :

le système ;
les paquets ;
le serveur Web ;
le pare-feu ;
les versions des runtimes ;
les services.

En échange, lorsque le serveur cesse de répondre à 3 h 12, l’hébergeur peut également vous offrir cette liberté précieuse :

« La VM fonctionne. Bonne chance. »

Le serveur dédié

Un serveur dédié correspond à une machine physique réservée à votre usage.

Il offre notamment :

contrôle important ;
ressources physiques dédiées ;
grande liberté d’architecture.

Mais il implique aussi davantage :

d’administration ;
de supervision ;
de sauvegardes ;
de sécurité ;
de responsabilité.

Le cloud a quelque peu compliqué la liste

Le choix moderne ne se limite plus à :

mutualisé
VPS
dédié

On rencontre aussi :

machines virtuelles à la demande ;
conteneurs ;
Kubernetes ;
plateformes PaaS ;
hébergement statique ;
fonctions serverless ;
edge computing ;
CDN capables d’exécuter du code.

Le terme « héberger une page » couvre désormais une quantité respectable de façons de ne plus savoir exactement sur quelle machine elle tourne.

Le CDN

Un :

Content Delivery Network
CDN

dispose de points de présence distribués géographiquement.

Une ressource peut être copiée ou mise en cache près des utilisateurs.

Au lieu de :

Utilisateur à Paris
↓
Serveur unique à Sydney

on peut obtenir :

Utilisateur à Paris
↓
Point de présence européen
↓
réponse en cache

Cela peut réduire :

la latence ;
la charge sur l’origine ;
les temps de transfert.

Le cache : ne pas refaire ce qui est déjà fait

Le Web utilise intensivement les caches.

On peut en trouver dans :

le navigateur ;
un proxy ;
un CDN ;
le serveur Web ;
l’application ;
la base de données.

HTTP possède des en-têtes dédiés comme :

Cache-Control
ETag
Last-Modified

Le but est simple :

éviter de transférer ou recalculer inutilement une ressource qui n’a pas changé.

304 Not Modified

Un navigateur peut demander conditionnellement :

« J’ai déjà cette ressource dans cet état. A-t-elle changé ? »

Le serveur peut répondre :

304 Not Modified

Le navigateur réutilise alors sa copie.

Le meilleur téléchargement est parfois celui qui n’a pas lieu.

Compression HTTP

Les ressources textuelles peuvent être compressées pendant le transport.

On rencontre notamment :

gzip
br

selon la négociation entre client et serveur.

Un fichier JavaScript de :

500 Ko sur disque

peut donc être sensiblement plus petit sur le réseau.

La taille transférée et la taille décompressée sont deux mesures différentes.

Les images comptent énormément

Sur beaucoup de sites, les images représentent une part importante des données transférées.

Les choix portent notamment sur :

dimensions ;
compression ;
format ;
résolution adaptée à l’écran ;
chargement différé ;
CDN d’images.

Envoyer une photo de :

8000 × 6000 pixels

pour l’afficher dans une vignette de :

320 × 240

est techniquement possible.

Tout comme transporter une baguette de pain avec un camion de 38 tonnes.

Responsive Web Design

Une page doit généralement s’adapter à différentes tailles d’écran.

CSS permet notamment :

des unités flexibles ;
Flexbox ;
Grid ;
les media queries ;
les container queries ;
des images adaptatives.

Par exemple :

@media (max-width: 700px) {
    .navigation {
        display: none;
    }
}

Le même HTML peut donc être présenté différemment selon le contexte.

L’accessibilité ne vient pas après le design

Une page Web doit pouvoir être utilisée par des personnes ayant des besoins variés.

Un bon HTML sémantique contribue directement à l’accessibilité.

Préférez :

<button>Enregistrer</button>

à :

<div onclick="enregistrer()">Enregistrer</div>

Le véritable bouton possède déjà :

une sémantique ;
un comportement clavier ;
une intégration avec les technologies d’assistance ;
des états de focus appropriés.

Réinventer un bouton avec douze lignes de JavaScript est parfois une façon très élaborée de supprimer gratuitement des fonctionnalités.

Les images ont besoin d’un texte alternatif lorsque c’est pertinent

Par exemple :

<img src="schema-reseau.png"
     alt="Schéma reliant le navigateur au serveur Web">

L’attribut :

alt

permet de fournir une alternative textuelle appropriée.

Le bon texte dépend du rôle de l’image dans le contexte.

JavaScript peut aussi casser l’accessibilité

Un site peut être techniquement magnifique et pourtant impossible à utiliser au clavier.

Lorsqu’on construit des composants personnalisés, il faut considérer :

focus ;
navigation clavier ;
états ;
libellés ;
sémantique ;
technologies d’assistance.

L’interface ne doit pas fonctionner uniquement pour la personne qui l’a développée avec une souris de gaming et trois écrans.

Les navigateurs exécutent le code dans un environnement limité

JavaScript téléchargé depuis un site ne possède normalement pas un accès arbitraire à :

C:\Users\Alice\Documents

ou :

/home/alice/.ssh/id_ed25519

Le navigateur fournit un environnement fortement contrôlé.

Sans cette isolation, ouvrir :

www.recettes-de-cookies.example

pourrait réellement voler autre chose que vos cookies.

Same-Origin Policy

Les navigateurs appliquent notamment une politique de sécurité fondée sur l’origine.

Une origine dépend principalement du :

schéma
+
hôte
+
port

Ainsi :

https://example.com

et :

https://api.example.com

ne constituent pas automatiquement la même origine.

Cette séparation empêche du code provenant d’un site de lire librement les données d’un autre.

CORS : autoriser certaines lectures entre origines

CORS — Cross-Origin Resource Sharing fournit un mécanisme permettant à un serveur d’indiquer quelles origines peuvent accéder à certaines réponses depuis du code navigateur.

On rencontre par exemple :

Access-Control-Allow-Origin: https://www.example.com

CORS n’est pas :

un pare-feu ;
une authentification ;
un mécanisme cachant une API à Internet.

Il s’agit principalement d’un mécanisme de contrôle appliqué par les navigateurs dans le contexte des requêtes cross-origin.

CSP : limiter ce qu’une page peut charger ou exécuter

Une :

Content-Security-Policy

peut réduire certaines possibilités d’exécution ou chargement de ressources.

Elle participe notamment à la défense contre certaines attaques comme les injections de scripts.

Mais une CSP ne rend pas magiquement sûr un code applicatif vulnérable.

La sécurité Web est malheureusement un domaine où :

une seule ligne magique

reste un produit largement indisponible.

Le JavaScript téléchargé est du code exécuté sur votre machine

Lorsque votre navigateur récupère :

app.js

le code est exécuté localement dans l’environnement du navigateur.

Cela implique notamment :

consommation CPU côté utilisateur ;
consommation mémoire ;
temps de parsing ;
temps de compilation ;
temps d’exécution.

Un serveur très rapide ne peut donc pas entièrement sauver une application qui envoie une bibliothèque municipale de JavaScript à un smartphone vieillissant.

Les outils de développement du navigateur

Les navigateurs modernes intègrent des outils permettant d’observer cette mécanique.

Vous pouvez notamment examiner :

le DOM ;
les styles CSS ;
les requêtes réseau ;
les codes HTTP ;
les en-têtes ;
les cookies ;
le stockage local ;
les erreurs JavaScript ;
les performances.

L’onglet Réseau est particulièrement instructif

Rechargez une page avec les outils de développement ouverts.

Vous verrez potentiellement :

document
stylesheet
script
font
image
fetch
xhr

avec pour chaque requête :

URL ;
méthode ;
statut ;
taille ;
temps ;
protocole ;
en-têtes.

Une page qui semblait être « un fichier » révèle alors son véritable visage :

une petite réunion distribuée de plusieurs dizaines de ressources essayant de se coordonner avant que l’utilisateur ne parte.

curl : regarder le Web sans navigateur

Depuis un terminal :

curl https://example.com/

affiche le corps de la réponse.

Pour inclure les en-têtes :

curl -i https://example.com/

Pour examiner davantage le dialogue :

curl -v https://example.com/

Pour ne demander que les en-têtes dans un scénario approprié :

curl -I https://example.com/

Afficher uniquement le HTML source ne montre pas toujours la page finale

Sur une application rendue côté client, le serveur peut envoyer :

<div id="app"></div>

alors que l’inspecteur DOM affiche ensuite :

<div id="app">
    <h1>Tableau de bord</h1>
    <table>...</table>
</div>

La différence a été produite par JavaScript.

Il faut donc distinguer :

la réponse HTML originale ;
le DOM actuel.

Les formulaires relient HTML au serveur

Un formulaire simple :

<form action="/recherche" method="get">
    <input name="q" type="search">
    <button>Rechercher</button>
</form>

peut produire une navigation vers :

/recherche?q=linux

Sans JavaScript.

Le serveur traite alors la requête et peut renvoyer une nouvelle page.

JavaScript permet de soumettre sans recharger toute la page

Avec :

fetch("/api/recherche?q=linux")

le navigateur peut récupérer des données en arrière-plan puis modifier uniquement une partie de l’interface.

Le Web moderne passe énormément de temps à éviter de recharger des documents entiers.

Puis il utilise parfois tellement de JavaScript pour le faire qu’une navigation traditionnelle aurait probablement déjà terminé.

Une API Web

Une API HTTP peut exposer des ressources comme :

GET    /api/articles
GET    /api/articles/42
POST   /api/articles
PATCH  /api/articles/42
DELETE /api/articles/42

Le client peut être :

une page Web ;
une application mobile ;
un script ;
un autre serveur.

Le Web dépasse donc largement la simple transmission de documents HTML.

Le navigateur peut stocker des données localement

Différents mécanismes existent notamment :

cookies ;
localStorage ;
sessionStorage ;
IndexedDB ;
Cache API.

Ils ne sont pas interchangeables.

Par exemple, un cookie peut être automatiquement envoyé au serveur selon ses attributs.

localStorage ne l’est pas.

Service Workers et fonctionnement hors ligne

Un Service Worker peut intercepter certaines requêtes du site et utiliser des stratégies de cache.

Une application peut ainsi proposer :

contenu hors ligne ;
cache avancé ;
mise à jour en arrière-plan ;
comportements de type application installable.

À ce stade, expliquer qu’une page Web est simplement :

« un fichier HTML téléchargé depuis le serveur »

commence à montrer quelques signes de fatigue.

Le navigateur cache parfois énormément de choses

Lorsque vous rechargez une page, certaines ressources peuvent provenir :

du disque local ;
de la mémoire ;
d’un Service Worker ;
d’un CDN ;
du véritable serveur d’origine.

Le fait qu’un fichier « s’affiche » ne signifie donc pas nécessairement qu’il vient d’être téléchargé.

Pourquoi Ctrl+F5 semble parfois pratiquer l’exorcisme

Une recharge forcée peut contourner certaines utilisations normales du cache.

C’est pourquoi :

« Vide ton cache. »

est devenu au support Web ce que :

« Redémarre. »

est à l’administration système.

Une réponse parfois justifiée.

Et suffisamment efficace pour survivre à des décennies de sarcasmes.

Les performances ne dépendent pas seulement du débit Internet

Le temps d’affichage dépend potentiellement de :

DNS ;
latence réseau ;
établissement de connexion ;
TLS ;
temps de réponse serveur ;
base de données ;
cache ;
taille des ressources ;
nombre de requêtes ;
JavaScript ;
CSS ;
images ;
polices ;
puissance du terminal.

Un utilisateur connecté à 5 Gbit/s peut donc parfaitement attendre une page pendant trois secondes si le serveur passe 2,8 secondes à méditer une requête SQL.

Le Time To First Byte

Le :

TTFB
Time To First Byte

mesure le temps avant la réception du premier octet de la réponse, selon le contexte de mesure.

Il peut notamment être influencé par :

latence ;
connexion ;
TLS ;
traitement serveur ;
cache.

Un mauvais TTFB n’indique donc pas automatiquement :

« PHP est lent. »

Il indique qu’il faut mesurer davantage.

Afficher la page rapidement ne suffit pas

Une page peut apparaître très vite tout en restant inutilisable plusieurs secondes parce que JavaScript monopolise le thread principal.

Les performances modernes s’intéressent donc aussi à :

la rapidité d’apparition du contenu ;
la stabilité visuelle ;
la réactivité aux interactions.

Le bouton visible mais incapable de répondre pendant quatre secondes possède une présence esthétique indéniable.

Son utilité opérationnelle reste plus discutable.

SEO : permettre aussi aux machines de comprendre

Les moteurs de recherche analysent le contenu des pages.

Un HTML structuré correctement facilite cette compréhension.

Des éléments comme :

titres cohérents ;
liens descriptifs ;
contenu sémantique ;
métadonnées appropriées ;
structure logique ;

servent d’abord aux utilisateurs et à l’accessibilité, mais peuvent également aider les systèmes d’indexation.

JavaScript et indexation

Les principaux moteurs modernes savent exécuter une partie importante de JavaScript.

Mais cela ne signifie pas que toutes les applications purement client seront interprétées parfaitement par :

tous les robots ;
les réseaux sociaux ;
les aperçus de messagerie ;
les outils d’archivage ;
les lecteurs spécialisés.

Fournir un HTML significatif dès la réponse reste donc souvent avantageux lorsqu’il est raisonnable de le faire.

Une page moderne, vue comme une pile

On peut maintenant représenter la situation ainsi :

UTILISATEUR
    ↓
NAVIGATEUR
    ↓
HTML + CSS + JavaScript
    ↓
HTTP / HTTPS
    ↓
TLS
    ↓
TCP ou QUIC
    ↓
IP
    ↓
RÉSEAU
    ↓
CDN / PROXY / LOAD BALANCER
    ↓
SERVEUR WEB
    ↓
APPLICATION
    ↓
CACHE / BASE DE DONNÉES / API
    ↓
DONNÉES

Chaque couche peut fonctionner parfaitement pendant que celle du dessous organise discrètement un incendie.

Exemple complet : consulter un article

Vous ouvrez :

https://www.example.com/articles/debian

1. Le navigateur interprète l’URL

Schéma : https
Hôte   : www.example.com
Chemin : /articles/debian

2. Le nom est résolu

Une adresse IP correspondant au service est obtenue si nécessaire.

3. Une connexion est établie

Selon le protocole négocié :

TCP + TLS
ou
QUIC

4. Le navigateur envoie une requête

GET /articles/debian

5. L’infrastructure reçoit la requête

Elle peut passer par :

CDN
→ reverse proxy
→ serveur Web

6. Le cache est interrogé

Si une réponse fraîche existe, elle peut être renvoyée immédiatement.

7. Sinon, l’application travaille

Par exemple :

PHP
→ CMS
→ base de données
→ thème
→ HTML

8. Le serveur répond

200 OK
Content-Type: text/html; charset=utf-8

9. Le navigateur parse le HTML

Le DOM commence à apparaître.

10. Les sous-ressources sont découvertes

style.css
app.js
photo.webp
font.woff2

11. CSS est appliqué

Les tailles, couleurs et dispositions sont déterminées.

12. JavaScript s’exécute

Il peut :

activer un menu ;
charger les commentaires ;
gérer une recherche ;
mettre à jour une interface.

13. Le navigateur effectue layout et paint

Les pixels sont enfin affichés.

Pour vous :

clic
↓
article

Pour la machine :

une cérémonie distribuée impliquant une demi-douzaine de protocoles et suffisamment de logiciels pour administrer un petit pays.

Quand quelque chose casse : raisonner par couches

Supposons que :

« Le site ne marche pas. »

Cette phrase est approximativement aussi précise que :

« La voiture fait un bruit. »

Il faut déterminer où le problème apparaît.

Le nom ne se résout pas

Examiner :

DNS

La connexion échoue

Examiner :

routage
pare-feu
port
service
TLS

Le serveur répond 404

Examiner :

URL
routes applicatives
configuration du serveur Web
fichier ou ressource demandée

Le serveur répond 500

Examiner :

journaux applicatifs
serveur Web
PHP / runtime
base de données
permissions
code

Le HTML arrive mais la page est cassée

Examiner :

CSS
JavaScript
ressources manquantes
console du navigateur
onglet Network

La page fonctionne mais elle est lente

Mesurer :

TTFB
taille des ressources
cache
requêtes
JavaScript
images
base de données

Une méthode par couches est généralement plus efficace que :

« Redémarrons tout et voyons si l’univers nous pardonne. »

Les erreurs classiques à éviter

« Une page Web est un fichier HTML »

Parfois.

Elle peut aussi être générée, assemblée ou rendue dynamiquement.

« Une page statique n’a pas de JavaScript »

Faux.

Statique décrit principalement le mode de génération ou de distribution du contenu, pas son niveau d’interactivité dans le navigateur.

« HTML ne sait rien faire »

HTML fournit déjà énormément de comportements natifs et surtout la sémantique fondamentale du document.

« CSS sert seulement aux couleurs »

CSS gère aujourd’hui des mises en page, animations, adaptations responsives et comportements visuels très avancés.

« Node.js est un langage »

Non.

JavaScript est le langage.

Node.js est un environnement d’exécution.

« Le serveur envoie toujours du HTML »

Non.

Il peut renvoyer JSON, images, vidéos, PDF, fichiers ou pratiquement toute représentation correctement décrite.

« HTTPS veut dire que le site est sûr »

HTTPS protège la communication.

Il ne certifie pas les intentions du propriétaire du site.

« Une URL correspond à un fichier sur disque »

Pas nécessairement.

Une URL identifie une ressource selon les règles de l’application et du serveur.

« Une page correspond à une seule requête »

Elle peut déclencher des dizaines ou centaines de requêtes supplémentaires.

« 500 ? Redémarre Apache »

Cela peut parfois rétablir un service.

Mais les logs ont généralement davantage de choses intéressantes à raconter.

Les trois technologies fondamentales côté navigateur

Technologie	Nature	Fonction principale
HTML	Langage de balisage	Structure et sémantique
CSS	Langage de feuilles de style	Présentation et mise en page
JavaScript	Langage de programmation	Logique et interactions avancées

Quelques technologies côté serveur

Technologie	Type
PHP	Langage de programmation
Python	Langage de programmation
Ruby	Langage de programmation
Java	Langage / plateforme selon le contexte
C#	Langage, souvent avec ASP.NET Core
JavaScript	Langage également utilisable côté serveur
Node.js	Environnement d’exécution JavaScript

Les grandes architectures de rendu

Approche	Lieu principal de génération initiale
Fichier statique	Préexiste avant la requête
SSG	Généré lors du build
SSR	Généré sur le serveur au moment approprié
CSR	Interface principalement construite dans le navigateur
Hybride	Combinaison de plusieurs approches

Les concepts à retenir

Concept	Rôle
URL	Identifie une ressource et son mode d’accès
DNS	Aide notamment à retrouver les adresses correspondant aux noms
HTTP	Protocole de requêtes et réponses du Web
HTTPS	HTTP protégé par TLS
HTML	Structure et sémantique du document
CSS	Présentation
JavaScript	Programmation et interactions
DOM	Représentation du document manipulable par les API
Serveur Web	Traite et distribue les ressources HTTP
Application	Exécute la logique métier
Base de données	Stocke des données structurées lorsque l’architecture en utilise une
Cache	Évite certains calculs ou transferts répétés
CDN	Distribue les ressources depuis une infrastructure géographiquement répartie

Une page Web vue depuis chaque acteur

Pour l’utilisateur

Je clique.
Ça s'affiche.

Pour le navigateur

URL
DNS
connexion
TLS
HTTP
HTML
CSS
JavaScript
DOM
layout
paint

Pour le serveur

requête
cache
route
authentification
application
base de données
template
réponse

Pour l’administrateur

Pourquoi le load average est à 47 ?

Pour le développeur

Ça marchait sur ma machine.

Chacun possède finalement sa propre représentation du même système.

Conclusion : une page Web est un miracle, mais surtout une pile de technologies bien normalisées

Une page Web peut commencer par quelques lignes très simples :

<!doctype html>
<html lang="fr">
<body>
    <h1>Bonjour</h1>
</body>
</html>

et finir derrière :

DNS
CDN
HTTP/3
TLS
reverse proxy
conteneurs
application
cache
base de données
API
JavaScript
Service Worker

sans que l’utilisateur voie la moindre différence conceptuelle.

Il demande une page.

Le système lui répond.

Entre les deux, chaque couche accomplit son travail :

DNS aide à trouver le service ;
le réseau transporte les données ;
TLS protège la communication HTTPS ;
HTTP structure les requêtes et réponses ;
le serveur fournit ou génère les ressources ;
HTML décrit la structure et le sens ;
CSS organise la présentation ;
JavaScript apporte de la logique programmable ;
le navigateur assemble finalement le tout en une interface visible.

Une page Web n’est donc pas seulement :

« un fichier HTML avec un peu de CSS et de JavaScript ».

C’est une ressource distribuée dans une architecture client-serveur, potentiellement composée de dizaines d’autres ressources, pouvant être générée à plusieurs endroits et transformée après son arrivée dans le navigateur.

Le fait que tout cela fonctionne plusieurs milliards de fois par jour avec des navigateurs, systèmes, réseaux et serveurs différents reste assez remarquable.

Et lorsque cela ne fonctionne pas, le code de statut apporte parfois cette précision rassurante :

500 Internal Server Error

Ce qui signifie approximativement :

« La requête est arrivée à destination.
Quelque chose derrière la porte a cependant cessé de croire en l’avenir. »

À ce moment-là, ne redémarrez pas immédiatement tout le datacenter.

Commencez par regarder les logs.

Le Web est complexe, mais il laisse généralement des traces de sa souffrance.

Post Views: 9