Du HTML aux pixels

Objectifs

À la fin de cette leçon, vous saurez :

• décrire la chaîne de rendu complète du navigateur, étape par étape ;
• distinguer DOM, CSSOM et render tree — trois arbres aux rôles distincts ;
• expliquer layout, paint, composite et leur coût relatif ;
• prédire quelles étapes se relancent pour chaque type de modification.

🔗 Pour vous rafraîchir la mémoire : la structure d'un document HTML · sélecteurs, cascade et spécificité

La question : que fait le navigateur entre votre fichier et l'écran ?

Vous écrivez du texte (HTML + CSS). L'écran affiche des pixels allumés. Entre les deux, un travail considérable s'exécute en quelques dizaines de millisecondes — la chaîne de rendu :

HTML  ──parsing──→  DOM          arbre des éléments
CSS   ──parsing──→  CSSOM        arbre des règles de style
                         ↓
              RENDER TREE (éléments visibles + leurs styles calculés)
                         ↓
              LAYOUT     (géométrie : positions, tailles exactes)
                         ↓
               PAINT      (remplissage des pixels, couche par couche)
                         ↓
             COMPOSITE   (assemblage final affiché)

Comprendre cette chaîne n'est pas académique : chaque modification de page relance UNE PARTIE de ces étapes, et savoir laquelle explique pourquoi certains changements sont gratuits et d'autres coûteux.

Le DOM : votre HTML devenu objets vivants

Le DOM (Document Object Model) est la représentation mémoire du document : un arbre d'OBJETS — pas du texte — que JavaScript peut lire et modifier :

document
└── html
    ├── head ── title
    └── body
        ├── h1 "Mon site"
        └── p "Bonjour"

Trois conséquences pratiques décisives :

1. Le parseur corrige : une balise mal fermée produit quand même un DOM propre (souvenez-vous de l'expérience du chapitre 13) — le navigateur devine et répare ;
2. C'est LUI la page, pas vos fichiers : dès le chapitre suivant, tout votre JavaScript manipulera cet arbre, jamais le code source ;
3. Toute modification du DOM relance la suite de la chaîne : changer le texte d'un titre = mettre à jour un objet → recalcul → redessin.

Vous verrez ce DOM de vos yeux dans la leçon suivante : l'onglet Elements des DevTools EST ce DOM-là, pas votre fichier.

Le CSSOM et le render tree : croiser les deux mondes

Le CSSOM est l'équivalent côté styles : toutes vos règles CSS parsées et rangées. Au moment du rendu, le navigateur croise les deux arbres pour construire le render tree — uniquement les éléments VISIBLES avec leurs styles calculés (cascade appliquée, héritage résolu).

Deux exclusions importantes qui surprennent souvent :

• <head> n'y figure jamais : rien à dessiner ;
• un élément en display: none disparaît du render tree — c'est précisément POUR ÇA qu'il ne prend aucune place (à distinguer de visibility: hidden, qui reste dans l'arbre mais invisible : il continue d'occuper sa place !).

Layout et paint : où ça coûte vraiment

Les deux dernières grandes étapes ont des coûts très différents :

Étape	Travail	Déclenché par
Layout (reflow)	calculer positions et tailles de TOUS les éléments concernés, puis de leurs descendants	toute changement de géométrie : width, padding, contenu textuel, ajout/suppression d'élément
Paint (repaint)	remplir les pixels des zones touchées	changement sans impact géométrique : couleur, ombre, visibilité
Composite	assembler les couches déjà rasterisées	transformations GPU : transform, opacity

L'ordre de coût est clair : layout ≫ paint > composite. D'où la règle de performance la plus citée du front-end :

/* animer la position via transform : composite seul → fluide */
.badge { transition: transform .2s; }
.badge:hover { transform: translateX(4px); }

/* animer via left/margin : layout + paint à CHAQUE image → saccadé */
.badge-mauvais { transition: left .2s; position: absolute; }
.badge-mauvais:hover { left: 4px; }

Même effet visuel, coûts radicalement différents. Vous retrouverez ce principe quand vous animerez des interfaces au chapitre 16.

Exercice

1. Récitez la chaîne complète dans l'ordre, sans regarder.
2. Pour chaque modification, nommez les étapes relancées : a. changer color d'un paragraphe ; b. ajouter du padding sur toutes les sections ; c. masquer un élément avec display: none ; d. idem avec visibility: hidden ; e. déplacer un badge avec transform.
3. Ouvrez DevTools → Performance, enregistrez pendant un rechargement de votre CV : repérez les blocs Layout/Paint dans la timeline.
4. Question de synthèse : reliez render tree et display: none — pourquoi ce dernier « sort »-il un élément de l'arbre ?

Résumé

• Parsing → DOM/CSSOM → render tree (visibles seuls) → layout → paint → composite.
• Le DOM est l'arbre vivant que JS modifiera dès demain ; Elements/DevTools l'affiche.
• Layout (géométrie) ≫ paint (pixels) > composite (assemblage) : animer transform, pas des dimensions.
• display: none sort du render tree ; visibility: hidden y reste invisible.

a. color            → repaint seul                    (peu coûteux)
b. padding partout  → layout + repaint                (cher : tout descend se recalcule)
c. display:none     → layout + repaint                (l'élément quitte le render tree,
                                                       les voisins se replacent)
d. visibility:hidden→ repaint seul                    (place conservée : pas de layout)
e. transform        → composite seul                  (le moins cher de tous)