Un site conçu avec Elementor charge presque toujours plus de code qu’un site habillé d’un thème classique bien écrit. Ce n’est pas une légende urbaine ni un procès d’intention : c’est la conséquence directe de la manière dont le page builder construit ses pages. Chaque section, chaque colonne, chaque widget ajoute sa couche de balises, ses classes utilitaires et parfois son propre style inline. Pris isolément, rien de dramatique. Multiplié par une page d’accueil composée de douze sections imbriquées, le poids grimpe vite.
La bonne nouvelle, c’est que cette lourdeur n’est pas une fatalité. Elle se corrige avec quelques réflexes simples, sans abandonner le confort d’édition visuelle qui fait le succès d’Elementor. Cet article détaille d’où vient le problème, comment le mesurer, puis comment l’atténuer concrètement, section après section et fichier après fichier.
Pourquoi Elementor génère un DOM plus dense
Un thème WordPress classique, codé à la main, produit en général une structure HTML plate : un conteneur, quelques divisions pour la mise en page, et le contenu. Elementor, lui, doit rester générique pour s’adapter à n’importe quel usage. Il empile donc systématiquement plusieurs niveaux : la section, sa colonne interne, un conteneur de marge intérieure, puis le wrapper du widget, avant même d’atteindre le contenu réel affiché à l’écran.
Cette imbrication a une raison d’être : elle permet au builder de gérer indépendamment les marges, les arrière-plans, les animations et la réactivité de chaque niveau sans casser les autres. Le prix à payer, c’est un nombre de nœuds DOM largement supérieur à celui d’un gabarit codé sur mesure. Sur une page riche en widgets (colonnes multiples, icônes, boîtes d’image, séparateurs), il n’est pas rare de dépasser plusieurs milliers de nœuds, quand un thème artisanal se contente de quelques centaines pour un rendu équivalent.
Le navigateur doit analyser, styler et peindre chacun de ces nœuds. Sur un poste puissant avec une bonne connexion, la différence passe inaperçue. Sur un mobile d’entrée de gamme ou une connexion 3G, elle se traduit par un temps de rendu perceptible, surtout si le thème charge en plus une quantité conséquente de CSS et de JavaScript pour interpréter cette structure.
Mesurer avant d’agir
Avant de se lancer dans l’optimisation, mieux vaut mesurer précisément où se situe le problème plutôt que de deviner. Trois outils suffisent dans la grande majorité des cas :
- L’inspecteur du navigateur, onglet Éléments, pour compter visuellement les niveaux d’imbrication d’une section suspecte.
- Le panneau Performance des outils de développement, qui révèle le temps passé en style et en mise en page (layout) lors du rendu initial.
- Un test Lighthouse ou PageSpeed Insights, qui chiffre le poids total des ressources et signale les feuilles de style ou scripts inutilisés sur la page testée.
Cette étape de diagnostic évite de corriger un problème qui n’existe pas. Une page d’atterrissage simple, avec deux ou trois sections, n’a souvent aucun problème de DOM : le vrai coût vient alors des assets chargés inutilement, pas de la structure elle-même. Distinguer les deux causes oriente directement vers la bonne solution.
Limiter l’imbrication dès la construction
La première marge de manœuvre se joue au moment même de la construction de la page, avant tout réglage technique. Quelques habitudes réduisent nettement le nombre de niveaux ajoutés :
- Éviter d’imbriquer une section interne dans une colonne quand une simple colonne supplémentaire suffirait.
- Préférer les marges et espacements natifs des widgets plutôt que d’ajouter une colonne vide « pour l’espacement ».
- Regrouper les éléments répétitifs (icônes, textes courts) dans un widget dédié plutôt que d’empiler colonne après colonne pour chaque élément.
- Réutiliser un modèle global (template Elementor) pour les blocs récurrents plutôt que de reconstruire la structure à chaque page.
Ces choix se prennent au moment de la conception, ce qui est le meilleur moment : corriger une structure après coup, une fois le contenu validé par le client, coûte toujours plus cher en temps qu’anticiper une architecture sobre dès le départ.
Avant de dupliquer une section pour créer une variante, demandez-vous si un simple changement de contenu dans une section existante ne suffirait pas. Chaque duplication inutile est un bloc de DOM et de CSS en plus à faire transiter jusqu’au navigateur.
Désactiver Font Awesome quand il n’est pas utilisé
Elementor embarque par défaut la bibliothèque d’icônes Font Awesome, chargée sur toutes les pages construites avec le builder, que la page affiche une icône ou non. Sur un site qui n’utilise pas d’icônes, ou seulement une poignée d’entre elles, ce chargement systématique représente un poids CSS et parfois JavaScript totalement superflu.
Dans les réglages avancés d’Elementor, il est possible de désactiver le chargement de Font Awesome pour ne conserver qu’un jeu réduit d’icônes SVG intégrées directement dans la page, ou de basculer vers un chargement à la demande. Sur un site vitrine sobre en pictogrammes, ce simple réglage retire une bibliothèque de police d’icônes complète du chargement de chaque page, ce qui allège aussi bien le CSS que le nombre de requêtes réseau.
Il vaut la peine de vérifier régulièrement, au fil des mises à jour du site, si de nouvelles icônes ont été ajoutées ailleurs dans le thème ou dans un plugin tiers : une bibliothèque désactivée par erreur casse silencieusement l’affichage d’une icône oubliée dans un coin de page.
Charger le CSS Elementor uniquement là où il sert
Par défaut, une partie des feuilles de style d’Elementor est mutualisée et peut se retrouver chargée même sur des pages qui n’utilisent pas le builder, notamment lorsque des widgets globaux ou des modèles sont réutilisés à plusieurs endroits du site. Sur un site hybride, où seules certaines pages sont construites avec Elementor et d’autres avec l’éditeur natif, ce chargement transversal gaspille de la bande passante sur les pages qui n’en ont pas besoin.
La piste la plus fiable consiste à générer un fichier CSS spécifique par page ou par modèle, une fonctionnalité proposée dans les réglages de performance d’Elementor, plutôt que de dépendre d’un unique fichier CSS global partagé par toutes les pages. Cela permet à chaque page de ne récupérer que les règles dont elle a réellement besoin.
Le lazy-load natif de WordPress, un allié gratuit
Depuis la version 5.5 de WordPress, sortie cet été, le cœur du logiciel ajoute automatiquement l’attribut loading="lazy" aux images insérées dans le contenu, y compris celles gérées par les widgets Elementor. Concrètement, les images situées hors du champ de vision initial ne se chargent qu’au moment où l’utilisateur s’en approche en faisant défiler la page, ce qui réduit le poids initial transféré et accélère l’affichage des premiers éléments visibles.
Ce comportement est actif par défaut, sans configuration particulière, ce qui en fait l’optimisation la plus simple à obtenir : il suffit de ne pas la désactiver. Sur une page longue, riche en visuels (portfolio, page d’accueil avec plusieurs sections illustrées), le gain sur le temps de chargement perçu est immédiat et ne demande aucun effort de configuration côté Elementor.
En résumé
Le DOM plus lourd d’Elementor n’est pas un défaut de conception à corriger, c’est la contrepartie d’un outil pensé pour être flexible et accessible à des utilisateurs non développeurs. Le rôle du développeur consiste alors à encadrer cette flexibilité : construire des structures sobres, désactiver les bibliothèques inutilisées comme Font Awesome, restreindre le chargement CSS aux pages concernées, et laisser le lazy-load natif de WordPress faire le reste. Aucune de ces actions ne demande de développement lourd, mais leur cumul change réellement la perception de vitesse d’un site, en particulier sur mobile.
