Les page builders, ces constructeurs visuels comme Elementor, Divi, WPBakery ou Beaver Builder, ont permis à des millions de personnes de créer des pages soignées sans écrire de code. On glisse une section, on choisit les colonnes, on insère un titre, une image, un bouton, on règle les marges et les animations, et l’on voit le résultat en temps réel. Pour les agences, les indépendants et les entreprises, c’est un confort énorme, qui raccourcit les délais de développement et rend les clients autonomes.
Ce confort a toutefois un coût, qui n’est pas visible dans l’éditeur mais qui se paie à chaque visite : plus de HTML, plus de CSS, plus de JavaScript, et surtout un DOM, la structure de la page en mémoire, bien plus grand et plus profond que nécessaire. Dans cet article, nous voyons d’où vient ce coût, comment il pèse sur les Core Web Vitals et ce que l’on peut faire sans forcément reconstruire le site de zéro.
Pourquoi les builders produisent plus de code
Un constructeur visuel doit permettre de configurer chaque élément de façon indépendante : marges, arrière-plans, bordures, alignements, comportement sur tablette et mobile, animations d’entrée, visibilité conditionnelle. Pour offrir toutes ces possibilités de manière générique, chaque élément est enveloppé dans plusieurs conteneurs, chacun gérant un aspect : la section, le conteneur interne, la colonne, l’enveloppe du widget, le widget, le conteneur de contenu. Un simple titre peut ainsi se trouver six ou sept niveaux sous la section qui le contient.
Multiplié par tous les éléments d’une page, ce schéma produit facilement deux ou trois mille nœuds, parfois beaucoup plus sur les pages d’accueil riches en sections, carrousels et menus complexes. À cela s’ajoutent d’autres coûts typiques : des feuilles de style générées pour chaque page ou chaque élément, des bibliothèques JavaScript pour les animations, les sliders, les lightboxes et les onglets, des collections complètes d’icônes chargées pour n’en utiliser que quelques-unes, des polices ajoutées par des widgets individuels.
Ce que coûte un grand DOM
Le DOM n’est pas seulement du texte à télécharger. C’est une structure que le navigateur garde en mémoire et qu’il doit recalculer chaque fois que quelque chose change : quelles règles CSS s’appliquent à chaque élément, où il se trouve et quelle est sa taille, ce qu’il faut redessiner. Plus il y a de nœuds, et plus ils sont profondément imbriqués, plus ce travail est lourd. Lighthouse signale un DOM excessif au-delà d’environ 800 éléments et le juge critique au-delà de 1 400, non pas parce qu’il existerait une limite précise, mais parce qu’au-delà de ces tailles, les coûts deviennent mesurables sur les appareils de milieu de gamme.
Sur les Core Web Vitals, les effets se répartissent sur les trois métriques. L’INP est celle qui en souffre le plus : chaque interaction qui modifie la page, comme ouvrir un menu, changer d’onglet ou déplier une question fréquente, exige un recalcul des styles et de la mise en page dont le coût croît avec le DOM, et qui s’ajoute au JavaScript du gestionnaire d’événement. Une interaction banale peut dépasser 200 millisecondes sur un smartphone d’entrée de gamme simplement parce que la page est énorme.
Le LCP est affecté par un HTML et un CSS plus lourds à télécharger et à analyser, par le JavaScript qui occupe le thread principal pendant le chargement, et par des choix typiques des builders, comme l’image principale définie en arrière-plan CSS d’une section, que le navigateur découvre tard, ou placée dans un slider lancé par JavaScript. Le CLS, enfin, peut se dégrader à cause de sections qui changent de hauteur au démarrage des scripts, de menus qui se réorganisent et de polices chargées par plusieurs widgets.
Les réglages de performance des builders
Les principaux builders ont conscience du problème et ont introduit ces dernières années des fonctions spécifiques, souvent désactivées sur les sites créés avec des versions antérieures pour ne pas casser la compatibilité. C’est le premier endroit où regarder, car quelques clics peuvent apporter des améliorations concrètes.
Elementor, par exemple, a introduit une sortie DOM optimisée qui supprime certaines enveloppes, le chargement des scripts et des styles uniquement pour les widgets réellement utilisés dans la page, des icônes intégrées en SVG au lieu de la bibliothèque complète de polices d’icônes et, surtout, des conteneurs basés sur Flexbox, qui remplacent l’association de sections et de colonnes par une structure plus légère. Divi propose dans ses options de performance du CSS et du JavaScript dynamiques, qui ne chargent que ce dont la page a besoin, ainsi que la génération de CSS critique, et la nouvelle génération du builder a elle aussi été réécrite pour réduire le poids de sa sortie. D’autres builders offrent des options similaires.
Ces options doivent être activées avec précaution, dans un environnement de test, car certaines modifient la structure du HTML et peuvent casser le CSS personnalisé écrit pour la structure précédente. Mais presque toujours, le bénéfice justifie la vérification.
Les bonnes pratiques pour construire les pages
Beaucoup dépend aussi de la manière dont les pages sont construites. Deux sites réalisés avec le même builder peuvent avoir des tailles de DOM très différentes selon les habitudes de celui qui les a construits.
- Moins d’imbrication. Évitez les sections dans les sections et les colonnes dans les colonnes quand un seul conteneur bien réglé donne le même résultat. Avec des conteneurs Flexbox ou Grid, un seul niveau suffit souvent là où il en fallait trois.
- Un élément pour un contenu. Un titre et un paragraphe peuvent tenir dans un seul widget de texte au lieu de deux widgets séparés, chacun avec ses propres enveloppes.
- Pas de doublons par appareil. Une pratique répandue consiste à créer deux versions d’une section, l’une pour le desktop et l’autre pour le mobile, en masquant celle qui ne s’applique pas. Les deux restent dans le DOM : on paie le double de code pour afficher la moitié du contenu. Il vaut mieux une seule section avec des réglages responsives.
- Des styles globaux. Les couleurs, les polices et les espacements définis globalement produisent moins de CSS que des réglages répétés élément par élément, et rendent le site plus cohérent.
- De la retenue avec les effets et les widgets lourds. Sliders, animations d’entrée, compteurs animés, effets de parallaxe : chacun ajoute du JavaScript et du travail pour le navigateur. Utilisez-les là où ils apportent de la valeur, pas sur chaque section.
- L’image principale en tant qu’image. Pour la section d’ouverture, un vrai élément image à priorité élevée plutôt qu’un arrière-plan CSS, comme l’explique l’article sur le lazy loading.
En-tête, menus et pied de page
Une partie du DOM souvent négligée est celle qui se répète sur chaque page. Les en-têtes et les pieds de page construits avec le builder portent les mêmes enveloppes que le reste de la page, et les menus sont un cas particulier. Un méga-menu avec des dizaines de catégories, d’images et de descriptions peut à lui seul représenter plusieurs centaines de nœuds, présents dans le DOM même quand le menu est fermé. De nombreux thèmes ajoutent aussi un second menu pour le mobile, un panneau latéral qui duplique toute l’arborescence de navigation : le même contenu, deux fois dans la page.
Comme ces éléments sont présents sur chaque page du site, les alléger a un effet multiplié. Les solutions sont simples à décrire : un seul menu qui s’adapte aux différents écrans au lieu de deux versions séparées, des sous-menus moins profonds, le contenu riche du méga-menu chargé seulement quand l’utilisateur ouvre l’entrée, des pieds de page essentiels au lieu de pages complètes avec widgets, cartes et flux sociaux.
Un exemple typique
Prenons la page d’accueil d’un site d’entreprise construit il y a quelques années avec un builder : un grand slider en haut, des sections de services avec des icônes animées, des compteurs, des témoignages dans un carrousel, un formulaire de contact, un méga-menu et une version mobile de plusieurs sections. Le DOM dépasse quatre mille éléments, la page charge une douzaine de feuilles de style et autant de scripts, et l’INP mobile se situe dans la plage « à améliorer », avec des pics à l’ouverture du menu.
Une intervention ciblée, sans changer de builder, peut se dérouler ainsi : activer les options de performance et les conteneurs modernes, remplacer le slider par une image statique et un titre, supprimer les sections mobiles en double, utiliser un seul menu responsive, abandonner compteurs et animations là où ils n’apportent aucune information. Le DOM passe sous quinze cents éléments, le poids de la page est divisé par deux et les interactions redeviennent rapides. Dans la plupart des cas, le site reste visuellement très proche, et devient souvent plus clair.
Réduire ce qui est chargé
Outre le DOM, un site construit avec un page builder charge souvent des ressources dont une page donnée n’a pas besoin : feuilles de style de widgets inutilisés, bibliothèques pour des fonctions présentes seulement sur d’autres pages, polices d’icônes complètes. En plus des réglages du builder, des outils d’optimisation peuvent supprimer le CSS inutilisé, générer du CSS critique et différer le JavaScript non essentiel jusqu’à la première interaction. Ce sont des mesures efficaces, mais elles demandent un contrôle attentif précisément sur les sites construits avec des builders, où de nombreux éléments dépendent de classes et de scripts qui n’apparaissent que dans certains états : menus ouverts, onglets actifs, fenêtres modales.
Comment mesurer
Le nombre d’éléments d’une page se lit dans Lighthouse, dans l’avertissement sur la taille du DOM, qui indique aussi la profondeur maximale et l’élément ayant le plus d’enfants. À défaut, une seule ligne dans la console du navigateur suffit :
document.querySelectorAll( '*' ).length; // nombre total d’élémentsPour comprendre l’effet sur les interactions, le panneau Performance des DevTools, avec le CPU throttling activé, montre pour chaque clic le temps passé en recalcul des styles et de la mise en page, signalé en violet. Si ces phases prennent des dizaines de millisecondes pour ouvrir un simple menu, la taille du DOM fait très probablement partie du problème. La comparaison la plus utile se fait entre modèles de page : les pages d’accueil et les pages promotionnelles sont souvent bien plus lourdes que les articles et les fiches produit, et méritent la priorité.
Optimiser ou reconstruire ?
Il arrive souvent un moment où l’on se demande s’il vaut la peine de continuer à optimiser un site construit avec un page builder ou s’il vaut mieux le reconstruire avec un thème léger ou avec l’éditeur de blocs natif de WordPress, qui produit un balisage beaucoup plus sobre. Il n’y a pas de réponse unique. Si les réglages de performance et quelques interventions sur les pages principales ramènent les Core Web Vitals dans la plage « bon », la reconstruction est rarement justifiée par la seule performance. Si au contraire le site reste lent malgré les interventions, que le builder est dépassé ou que la maintenance est devenue complexe, une reconstruction peut être l’occasion de résoudre plusieurs problèmes d’un coup.
La décision doit se prendre avec des données : Core Web Vitals de terrain par modèle de page, poids des pages principales, coût estimé des interventions, fréquence des modifications de contenu par des personnes non techniques. Un page builder qui fait gagner des heures de travail chaque semaine a une valeur qu’il faut mettre dans la balance, tout comme les conversions perdues à cause d’un site lent.
En bref
Les page builders facilitent la création de pages soignées, mais ils produisent un DOM plus grand et plus profond, plus de CSS et plus de JavaScript que ce qu’exigerait une page. Le coût se voit surtout sur l’INP, parce que chaque mise à jour de la page devient plus lourde, mais aussi sur le LCP et le CLS. Lighthouse signale le problème au-delà d’environ 800 éléments, et beaucoup de pages construites avec un builder dépassent confortablement ce seuil.
Avant de penser à reconstruire, il vaut la peine d’activer les fonctions de performance du builder, de réduire l’imbrication, de supprimer les sections en double par appareil, de limiter les effets et les widgets lourds et de ne charger que les ressources nécessaires. Avec ces précautions, de nombreux sites atteignent la plage « bon » sans renoncer à l’outil avec lequel ils ont été construits ; pour les autres, les données diront s’il est temps de changer.
