Un DOM trop volumineux, c’est un arbre HTML avec trop de nœuds. Chaque nœud coûte en mémoire, en correspondance de sélecteurs CSS et en calcul de mise en page. Sur une catégorie qui imprime 200 produits avec leurs variantes déjà dans le HTML, le navigateur travaille avant même le premier clic.
Mesurer, pas deviner
Deux lectures suffisent.
Dans la console de la page chargée :
document.querySelectorAll("*").length
Ce nombre inclut tout le document. L’audit Lighthouse « Évitez une taille de DOM excessive », lui, s’intéresse surtout au body. Les repères publiés par Chrome : avertissement vers 800 nœuds, erreur vers 1 400. L’audit liste aussi l’élément le plus profond et celui qui a le plus d’enfants. Ces deux lignes disent où couper : une liste, pas « le header ».
Depuis 2025, Lighthouse fait évoluer cet audit vers un diagnostic qui échoue seulement si le coût est réel : un recalcul de style ou une mise en page au-delà de 40 ms, avec un grand nombre d’éléments concernés. Un DOM large qui ne provoque pas ce coût n’est pas, à lui seul, une panne. En revanche, s’il coïncide avec un INP médiocre au moment d’ouvrir un filtre, le lien est à creuser. Les seuils d’INP sont rappelés dans Core Web Vitals en 2026.
Dans l’onglet Éléments, le fil d’Ariane des balises montre les empilements div > div > div qui n’apportent ni sémantique ni mise en page. C’est souvent un constructeur de pages ou un composant qui enveloppe chaque texte trois fois.
D’où viennent les nœuds en trop
- Liste non fenêtrée. Tous les produits, avis ou messages sont dans le HTML initial alors que l’écran en montre dix. La fenêtre d’affichage (ne rendre que les lignes visibles, en conservant le HTML utile au référencement pour les pages qui doivent être indexées) coupe le coût navigateur. Ne videz pas le HTML d’une fiche que Google doit lire : distinguez la page indexable et le widget.
- Contenu masqué. Menus, modales et onglets déjà complets dans la page, cachés en CSS. Construisez-les au moment de l’ouverture, ou gardez un HTML court.
- Constructeur. Chaque bloc ajoute des enveloppes. Un modèle plus plat (flexbox ou grille sur un seul parent) retire des niveaux sans changer le rendu.
- Scripts tiers qui injectent des iframes et des conteneurs (avis, chat, remarketing). Chaque outil ajouté dans la page a un coût d’arbre, pas seulement de réseau. Le réseau se compte à part : trop de requêtes HTTP.
Compresser le HTML en Brotli réduit les octets, pas le nombre de nœuds une fois le document parsé. Les deux réglages sont compatibles : Brotli et Gzip.
Alléger sans casser le référencement ni l’accès
- Comptez les nœuds sur une page représentative (accueil, catégorie, fiche).
- Identifiez le parent qui a le plus d’enfants. C’est la liste à fenêtrer ou à paginer côté HTML.
- Supprimez les enveloppes qui n’ont pas de rôle (pas de style propre, pas de point d’accroche pour un script).
- Ne mettez pas dans le HTML initial les blocs sous la ligne de flottaison qui ne sont pas du contenu indexable (pop-in, chat).
- Recomptez, puis rejouez un profil de performance : le recalcul de style au clic sur le filtre doit baisser, pas seulement le compteur de nœuds.
Une catégorie e-commerce qui duplique chaque produit en version mobile et en version ordinateur dans le même HTML double l’arbre pour rien. Une seule structure, mise en page au CSS, suffit. Le cas des filtres qui multiplient les URL est un sujet d’indexation, distinct : filtres et contenu dupliqué.
Vérifiez enfin qu’une technologie d’assistance voit encore les titres et les boutons. Retirer des div ne doit pas retirer le libellé du bouton ni l’ordre de tabulation.