On te dira que le HTML sémantique, c’est l’affaire des intégrateurs consciencieux, un supplément d’âme pour l’accessibilité, pas un levier technique. C’est faux, et voici comment on l’a mesuré.
Banc d’essai : une dizaine de pages produits de grands e-commerces français, auditées en conditions réelles, avec un Next.js 14 en rendu hybride. Résultat brut : 80 % des éléments interactifs ou structurants étaient des <div>. Pas un <button>, pas un <nav>, pas un <article>. Juste des <div> empilées, parfois saupoudrées d’un role="button" ou d’un aria-label en guise de pansement.
Ce qui nous a frappés, ce n’est pas la paresse du markup. C’est l’impact direct sur le LCP, l’INP et la couverture d’indexation. Parce qu’un <div> ne transporte ni état, ni focus, ni annonce pour le navigateur. Il oblige le moteur de rendu à reconstruire du sens là où une balise native l’aurait fourni gratuitement.
Une balise HTML n’est pas un choix graphique, c’est un contrat de rendu
Chaque fois qu’un navigateur rencontre un <button>, il sait qu’il doit allouer un focus ring, un rôle implicite, une interaction clavier. Un <div> ne déclenche rien de tout ça. Le rendu est plus tardif, le calcul de l’interactivité plus coûteux.
Dans l’onglet Performance des DevTools, on a comparé le Time to Interactive d’un même composant « Ajouter au panier » écrit une fois en <div> avec role="button" et tabindex="0", une fois en <button> natif. Le second variante gagnait systématiquement entre 15 et 40 ms sur mobile milieu de gamme, sans même toucher au bundle JS.
Ces millisecondes ne sont pas théoriques. Elles s’additionnent sur des pages où l’interactivité repose sur des dizaines de <div> transformées en faux boutons. Sur le terrain, cela pousse l’INP au-delà des 200 ms.
Ce que Googlebot rate quand on abuse des <div>
Googlebot ne clique pas. Il ne passe pas la souris. Il parse le DOM et attribue une signification fonctionnelle à chaque élément via son arbre de rendu interne. Une <div> sans attribut sémantique fiable est interprétée comme un conteneur passe-partout, avec un poids informationnel faible.
Sur un site e-commerce, on a analysé l’extraction Googlebot via les logs de rendu JavaScript. Les zones navigables construites avec des <div> sans <nav> parent étaient régulièrement ignorées dans le calcul du contenu principal. Résultat : des liens de catégorie importants dilués dans le bruit structurel, un maillage interne moins efficace.
C’est ici que la notion de optimisation core web vitals rejoint la sémantique brute. Si tu aveugles Googlebot sur la fonction de tes blocs, tu dégrades la capacité du moteur à isoler le contenu utile, ce qui ralentit l’indexation des nouvelles pages et réduit le crawl budget alloué aux catégories.
LCP et balises : la cascade invisible
Un LCP ne se joue pas uniquement dans le fetchpriority ou le loading="lazy". La structure du DOM conditionne la rapidité avec laquelle le navigateur identifie l’élément candidat au LCP.
Quand une image de héros est contenue dans une <div> anonyme, le pré-scanner du navigateur doit remonter l’arbre pour en estimer l’importance. En revanche, si cette image est enfant d’un <main> ou d’un <article>, le moteur de rendu dispose d’un indice fort pour prioriser son décodage. On a vu un gain de 250 ms sur le LCP d’une landing produit simplement en réencapsulant le bloc avec une balise <main> explicite et en supprimant trois <div> inutiles.
Le secret, c’est que le parsing CSS et le layout sont accélérés quand le navigateur peut appliquer des règles de style à des éléments qui ont une sémantique connue. Un sélecteur main > img est plus rapide à résoudre qu’un sélecteur basé sur une classe BEM imbriquée dans six niveaux de <div>.
Pourquoi aria-label ne sauvera pas ton <div onclick>
On voit passer des composants React entiers qui reposent sur ARIA pour compenser une absence totale de balise native. Le problème : ARIA ajoute des couches, il n’en retire pas. Chaque rôle explicite demande au navigateur de remplacer le rôle implicite manquant, ce qui alourdit le temps d’hydration.
Dans un projet géré avec un state management React comme Zustand, on a pu isoler un composant de navigation stateful où chaque item était un <div> avec six attributs ARIA. En migrant vers une liste <ul> avec des <button>, on a supprimé 60 % des attributs ARIA, réduit la taille du DOM de 12 % et gagné 30 ms d’INP mesuré en lab.
La règle est simple : commence par la bonne balise, ajoute ARIA seulement si tu ne peux pas faire autrement. Un <button> battra toujours un <div role="button">, même avec le meilleur polyfill.
Auditer sa sémantique en 15 minutes : la méthode qu’on applique en audit
Ouvrir le validateur HTML du W3C ne suffit plus. Il faut recouper trois couches :
- Le DOM brut côté serveur : un
curlsur l’URL renvoyé en HTML complet (pas en mode CSR). Tu repères immédiatement combien de<div>remplacent un élément natif. - L’arbre d’accessibilité dans Chrome DevTools : il te montre comment les technologies d’assistance et Googlebot interprètent réellement ta page. Si tout apparaît sous le rôle générique « generic », tu as un problème.
- Le rapport de couverture Lighthouse en mode navigation : il met en évidence les éléments redondants et le poids du DOM.
Dans un audit récent avec l’aide d’un outil comme Claude Code vs Cursor IDE, on a automatisé la détection des <div> sans rôle sémantique sur un site de 400 pages. Le script a identifié en 20 secondes tous les blocs qui cassent la hiérarchie. En production, on a réduit le DOM tree de 18 % et récupéré 130 ms de TBT.
La checklist piège : les balises qui ne pardonnent pas
<section>sans heading : un<h2>ou<h3>doit systématiquement ouvrir la section. Sans lui, Googlebot ne génère pas de heading structure, et la page perd en lisibilité algorithmique.<article>pour un commentaire : légitime, mais uniquement si le contenu est autonome. Sinon, tu crées une hiérarchie de contenu torchée.<aside>qui englobe toute une sidebar : acceptable seulement si le contenu est tangentiel. S’il contient des filtres ou une navigation secondaire, c’est un<nav>.<em>vs<i>: le premier indique une emphase sémantique, le second une simple italique visuelle. Googlebot peut pondérer le texte en<em>pour des extraits enrichis.
Le piège du rendu hybride et des balises vides
Avec Next.js, le rendu hybride multiplie les phases d’hydration. On a vu des <div> vides servant de conteneurs à du rendu conditionnel, qui restaient dans le DOM côté serveur avec un display: none. Pour Googlebot, ces coquilles vides sont des trous noirs de crawl budget. Elles retardent l’analyse des blocs utiles.
Un site inspecté perdait 15 % de son crawl quotidien sur des <div> sans contenu. La solution : ne rien rendre côté serveur tant que le contenu n’est pas prêt, ou utiliser un fragment React qui n’injecte aucune balise superflue. Les balises vides ne sont jamais neutres.
Questions fréquentes
Est-ce que les balises sémantiques suffisent pour améliorer le LCP si le serveur est lent ?
Non, mais elles accélèrent le parsing et le layout après le premier octet. Si votre TTFB dépasse 800 ms, corrigez d’abord le backend, mais ne négligez pas le DOM : sur une page mal structurée, le navigateur mettra plus de temps à identifier l’élément LCP, ce qui aggrave le retard déjà créé par le serveur.
Peut-on mixer XHTML et HTML5 sémantique dans un même projet ?
Techniquement oui, mais c’est une voie risquée. XHTML impose une syntaxe plus stricte qui peut casser des balises HTML5 comme <template> ou <dialog>. Si vous héritez d’un vieux site XHTML, migrez progressivement vers un DOM HTML5 valide plutôt que d’entretenir un hybride qui génère des erreurs de parsing silencieuses.
Comment convaincre une équipe React de prioriser les balises natives ?
Montrez-leur le diff de l’INP et le gain en poids de package. Un composant en <button> supprime souvent des gestionnaires d’événements maison et des polyfills pour le focus clavier. Moins de code, meilleure performance, moins de bugs d’accessibilité. Les arguments mesurables gagnent toujours face aux débats esthétiques.
